Mail Archives: djgpp/1999/10/26/09:34:02
Davin McCall writes:
> However, I did have a look through the docs and couldn't find any
> reference. I did find (from Intel Architecture Software Developer's
> Manual, vol 1: Basic Architecture):
I'm not sure that the Intel manuals are necessarily the best source
for this kind of terminology, though, since they are quite old, and
IMHO it is more important to look at what the terms mean in general
use, and what a typical person is likely to understand by them...
> Neither of these suggest that a flat model has segments starting at
> physical address 0, and this latter suggests (though not strongly)
> that they need not span the entire address space.
To me, a flat model means that all memory addresses are directly
accessible, without any magical remapping, so that for example
(char *)0xA0000 would be pointing at the VGA video memory. It would
still be possible to do some virtual memory using the page tables,
because that is totally transparent to the program being virtualised,
as long as you never try to swap out any memory that is mapped
directly to a hardware device.
The djgpp addressing scheme isn't flat because physical memory
addresses are not directly accessible as pointers, so the program
needs to understand how to work with the memory mapping system.
I would call the djgpp system linear, because all normal memory
is directly accessible with a single 32 bit address, but not
flat, because there are still some important addresses that lie
outside this linear space.
> My main reason for stating that DJGPP was not based on the "tiny"
> memory model was because of my belief that the tiny model (along with
> "small", "compact", "large" etc) was reserved mainly for real mode
> applications and certainly only for 16-bit applications
I don't think there is any reason why those terms have to be
restricted to 16 bits: it is just that there is very little
reason for a 32 bit program ever to use anything other than
the tiny model, so people tend to just assume that and never
need to mention the other possible models.
A tiny model program just means that the selectors are always
loaded with a fixed value, and all memory addresses are stored
as a single offset. Likewise a small model uses single offsets
for all address, but different selectors for code and data,
while a large model uses multiple selectors for everything, so
that addresses must be stored as a selector:offset pair.
The only difference between a 16 and 32 bit program is how
large your offsets are. Since a tiny model 32 bit program
already has 4 gig of addressable memory, there is very little
reason ever to bother changing the selector values, but
there is nothing stopping you from doing that if you wanted
to write a large model program which used 48 bit sel:offset
pointers (of course you'd have to write your own compiler,
libc, etc, to support that :-)
Shawn Hargreaves.
- Raw text -