Mail Archives: djgpp/1995/05/25/21:34:58
> Quite wrong, why dont you try it? sbrk() and brk() modify the size
> of DS. So the remapped VRAM address *doesnt* need to be recomputed, but
> the fat-DS must be reloaded. As to any system call modifying the
> physical base address of DS, how can this be so? All global variable
> accesses will fail to work, unless the memory image is 'magically'
> patched. Along the same lines, dj mentioned that he cannot guarentee
> that an the selector in the go32 conventional memory selector field
> will be constant for the life of the process. This surely must be
> dubious statement.
The physical base of DS can be modified without changing the logical
base. In affect, the whole segment may be moved to a new location in
memory. This happens when memory is fragmented, and the existing
chunk can't be grown any more, but there is a space somewhere else in
the system that is big enough.
When this happens, the program doesn't need to know because it uses
the selector number (unchanged) and an offset relative to the segment
(unchanged) and never stores the physical address of the segment
anywhere (well, the CPU does, but the program doesn't).
> If we assume that the OS magically modifies (ie remaps) the location
> of conventional memory in the processes virtual address space, how can
> the process ever modify conv mem? Surely if the process can have no
> coherent understanding of where conv mem is, then only an OS call can
> accomplish access. There is no such DPMI call (even in v1.0) hence this
> behaviour is impossible.
Conventional memory is accessed through a different selector, which
has a constant physical base address. Different selector, different
segment, different parameters. You are forgetting that, even though
djgpp gives you a 32Gb linear address space, you are STILL USING
SEGMENTS. You just don't have to *worry* about them any more.
> Hypothetically one would need a callback structure to communicate
> with the OS about these 'asyncronous events' and disable remapping for
> the duration of conv mem access. Bissare...and not part of DPMI (or any
This would be the job of sbrk(), which could inform other parts of the
program if it "discovers" that the system had to relocate the program
in order to grow it. We thought of this for V2, but haven't
implemented it. It's easier to just not call malloc() while you're
updating conventional memory.
> sensible OS including Linux, Win OS/2 etc). Any why bother? If a process
> has privaledges to access conv mem, then those right should be maintained
> for the life of the process, or until the process relinquishes. Neither
> is there any reason to 'recycle' virtual address space...4Gbyte is
> plenty. I dont think any OS's use the 4Tbyte model, which might mean that
The 32Tb is virtual space. This means that you can *represent* 32Tb
of space through 8K selectors of 4Gb each. However, the program can
only *run* when its virtual segment resides in physical memory. Thus,
the OS must find a chunk of physical address space (4Gb) in which to
map the virtual segment, so that it becomes a real segment, and then
find physical memory pages from the system memory (32Mb on my PC) and
map those into the same linear address space as the segment so that
there is something to put the bits in so that it can execute them.
> unmapped memory is free to float around. Maybe in 50 years when we all
> have 4GigaBytes of RAM and 4TeraBytes of disk. But then you and i will be
> no more, and DOS.....well who's hear of DOS or 80xx86?
Hmmm... I think we've got about 2-3 Tb of disk space at Cabletron.
Our biggest servers have 0.4 Tb each. My *PC* has 10Gb (0.01Tb) of
disk. We have machines with 128Mb of RAM, and I know they can hit 0.5
Gb. It's not as far away as you might think.
- Raw text -