Message-ID: From: Shawn Hargreaves To: djgpp AT delorie DOT com Subject: Re: Just a few questions Date: Tue, 26 Oct 1999 11:45:16 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Reply-To: djgpp AT delorie DOT com 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.