Mail Archives: djgpp/1995/05/31/11:01:26
> But just perusing the dpmi v1.0 spec last night
> revealed that each dpmi client has their own private LDT and IDT. But seems
> that there is no need for 'the-hack' as v1.0 supports memory mapping.
> Will cwsdpmi provide v1.0 services in the future? Its intreguing to see
> dpmi v1.0 as a bigger and better VCPI...
With DPMI V1.0, you also get separate page tables for each client, too.
All of this is shared in DPMI V0.9 between clients :-(
The plan is to rewrite CWSDPMI in djasm and GCC, move most of it's footprint
to extended memory, and implement the entire V1.0 DPMI spec at that time.
But that probably won't get finished before 1996.
> But there is no reason to need the hack, because in raw mode,
> cwsdpmi can do its own memory mapping aka the 0xE0000000 window as go32 does.
Yes, I had that code in there at one time, but it was a BAD IDEA. The
DJGPP program had to figure out if it was CWSDPMI it was running under and
then do special things. This smells of the old GO32/DPMI problems in V1.x
so I wanted an algorithm that would work most places (cwsdpmi, qdpmi, 386max,
win, os/2) for V2.0.
> > I have plans that (eventually) using this accesss will be as simple as
> > setting a compile time flag and checking to see if it is supported. In
> > V2 the modifications are limited to a single file (crt0.S). This might
> > be used in a widely distributed app to gain some speed when the hack is
> > available, or fall back to the farptr functions if it is not available.
> >
> Good idea. But dont fall into the trap of providing a vectored
> movedata() fn like in go32 now. The whole point of the hack is that we
> can rapidly access sparse (or small) areas of conventional memory
> without function call overhead, and indeed, without segment overides
> (irelevant if writing to slow memory). Instead provide a global variable
> that indicates what enviornment we are running under, wheather the hack
> works or not, and possibly a fn to activate the hack when needed.
> crt0.s is definately the place to do it (we can easily recompile to
> handle new dpmi enviornments to implement the hack). Again once a
> 0xE0000000 segment in cwsdpmi is created, the hack is unnecessary, so we
> dont need to do evil things in the extender itself.
V2.0 is a DPMI-only environment. I planned to have a global variable
__djgpp_convmem_offset which would be maintained by sbrk() *IF THIS
FEATURE WAS AVAILABLE* which could be added to a pointer to access physical
memory. If the feature was not available (due to -1 limit not supported
or a compile time flag not set) the value would be some ODD value
(probably large to generate a GPF if you tried to use it). So code would
look something like
if(__djgpp_convmem_offset == __DJGPP_CONVMEM_NOTAVAIL)
use farptr functions, dosmem functions, etc
else
pointer = __djgpp_convmem_offset + 0xa0000;
*pointer = 0x720;
endif
This feature would be turned on by a static, compile time bit in the
flags field supported in V2 (for many other functions like globbing type,
etc) or by linking in a different module. The pointer would need to
be reloaded after any potential sbrk() call.
If the first section or the test was not coded, I would
expect it to work on most clients and GPF on others.
This feature would not be on by default, since it would make debugging
difficult in some environments where you could trash all sorts of memory
with a stray pointer.
The bad news is I don't have time to finish this work in the near future
since my house was flooded and the computer will get dismantled for storage
very soon. I expect it to be in a V2.0 maint release (assuming V2
will be released by the time my house is rebuilt ;-)
- Raw text -