Mail Archives: djgpp/1997/12/29/07:09:50
On 29 Dec 97, Eli Zaretskii was found to have commented thusly:
>
> On Mon, 29 Dec 1997, S. M. Halloran wrote:
>
> > FAR and NEAR and other "fundamental classes of data types" like this
> > are inventions necessary for the "real mode" segment-offset
> > addressing architecture of the Intel x86 chips. Intel eliminates
> > this craziness with the 80386 chips and those that follow. Intel
> > must retain this crazy way of memory addressing, of course, so that
> > older programs compiled can run, but with the 386 and beyond, Intel
> > goes to the "flat model" (and common sense) way of memory addressing.
>
> This is a very common misconception. NEAR and FAR are here because of
> the segmented architecture of the Intel chips, more precisely, of their
> way to access memory. This segmentation does NOT go away in 386 and
> better processors, nor is it eliminated in protected-mode programs. What
> does happen is that you get a huge (2GB-long) data segment, so using only
> NEAR pointers you have a very large address space. Think of it as if you
> were programming in the real-mode small memory model: would you say that
> the segments are ``gone'' for small model also?
I agree that segments are used in the flat-memory addressing scheme,
but the segment registers are used (or should only be used) by the OS
for compartmentalizing the applications and taking advantage of the
cpu's hardware protection mechanism. Application programmers would
never, to my knowledge, ever need to directly manipulate the segment
registers (play with the selectors even if the OS permitted). I
admit to the possibility that the definitions of NEAR and FAR may
have been expanded to include the concept of NEAR being a 32
bit-offset, and FAR being a 48-bit address (i.e., 16-bit selector in
combination with 32-bit offset). I believe you are referrring to
that in your statements.
I am not sure what you mean when you mention "small" model. I
believe that Intel though it was being generous when it provided
applications the potential to address 4 GB (2^32) of memory, and
therefore the notion of small, medium, large, huge, etc. becomes
irrelevant. It is up to the systems programmer, not the applications
programmer, to worry about how to deal with VM, paging, setting up
the code, data, and stack regions, and so on. Finally the
applications programmer is liberated from most of these details; for
the application programmer, segments are gone for all intents and
purposes.
Mitch Halloran
Research (Bio)chemist
Duzen Laboratories Group
Ankara TURKEY
mitch AT duzen DOT com DOT tr
other job title: Sequoia's (dob 12-20-95) daddy
- Raw text -