Mail Archives: djgpp/1999/10/26/00:01:57
On Mon, 25 Oct 1999 12:57:24 -0400, DJ Delorie <dj AT delorie DOT com> wrote:
>Intel's documentation doesn't agree with you. "Flat" has a very
>specific meaning - it means that you've set all segments to start at
>physical address zero and span the entire 4Gb memory space. If your
>segments aren't set up this way, it's not flat. DJGPP doesn't set up
>its segments this way.
Then I am proved wrong.
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):
>With the flat memory model (see Figure 3-2), memory appears to a program as a single, contin-uous
>address space, called a linear address space. Code (a program’s instructions), data, and
>the procedure stack are all contained in this address space. The linear address space is byte
>addressable, with addresses running contiguously from 0 to 2 32 - 1. An address for any byte in
>the linear address space is called a linear address.
I also found:
>With either the flat or segmented model, the Intel Architecture provides facilities for dividing
>the linear address space into pages and mapping the pages into virtual memory. If an operating
>system/executive uses the Intel Architecture’s paging mechanism, the existence of the pages is
>transparent to an application program.
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.
This is from volume 3:
>3.2.1. Basic Flat Model
>The simplest memory model for a system is the basic “flat model,” in which the operating
>system and application programs have access to a continuous, unsegmented address space. To
>the greatest extent possible, this basic flat model hides the segmentation mechanism of the archi-tecture
>from both the system designer and the application programmer.
>To implement a basic flat memory model with the Intel Architecture, at least two segment
>descriptors must be created, one for referencing a code segment and one for referencing a data
>segment (see Figure 3-2). Both of these segments, however, are mapped to the entire linear
>address space: that is, both segment descriptors have the same base address value of 0 and the
>same segment limit of 4 GBytes. By setting the segment limit to 4 GBytes, the segmentation
>mechanism is kept from generating exceptions for out of limit memory references, even if no
>physical memory resides at a particular address. ROM (EPROM) is generally located at the top
>of the physical address space, because the processor begins execution at FFFF_FFF0H. RAM
>(DRAM) is placed at the bottom of the address space because the initial base address for the DS
>data segment after reset initialization is 0.
It mentions a "Basic flat model" which sounds like what you described,
but seems to imply to me that there are alternatives.
There are other references to flat model, including a variation called
"Protected flat model", but I won't quote them unless someone is
really interested.
In general, it is implied that a flat model entails that segment bases
are set to a linear (but not necessarily physical) address of 0 (One
paragraph mentioned that this was "usually" the case).
In any case, I won't argue further: I don't think I have any real
evidence, and I'm prepared to accept the different viewpoints on this.
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, but I can't
immediately find anything to confirm this. In any case I am quite sure
(again, without a reference) that "flat" has been used often to
describe a memory model such as the one supported by DJGPP.
Even the DJGPP FAQ makes reference to the flat memory model, in
particular with reference to .OBJ files and how they can be linked
with DJGPP programs. Of course this isn't conclusive in any way.
Davin.
__________________________________________________________
*** davmac - sharkin'!! davmac AT iname DOT com ***
my programming page: http://yoyo.cc.monash.edu.au/~davmac/
- Raw text -