Date: Wed, 24 Sep 1997 12:29:56 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: firewind <firewind AT metroid DOT dyn DOT ml DOT org>
cc: djgpp AT delorie DOT com
Subject: Re: (pas d'objet)
In-Reply-To: <609oql$8ag@dfw-ixnews10.ix.netcom.com>
Message-ID: <Pine.SUN.3.91.970924122932.18049O-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk


On 24 Sep 1997, firewind wrote:

> There is no such thing as 'near' and 'far' in DJGPP.

Not entirely true.  Near and far pointers are with us as long as we
use Intel x86 segmented architecture.

In the x86 architecture, near pointers hold an offset into some
segment, and far pointers hold both a segment and an offset.
(Protected-mode far pointers actually use a selector, which is an
entry into a table of segment descriptorss, instead of a segment
itself, but that distinction is not important for the purpose of this
discussion.)

It is true that DJGPP features 4GB flat address space, but that's only
because 32-bit protected-mode addressing allows each segment to be up
to 4GB large.  So you can use a single segment and pretend there are
no other segments.  However, the facts of life are such that segments
are still present: the DJGPP startup code still loads the segment
selectors into CS, DS and other registers; they are just kept constant
(well, almost) throughout the entire program's life.

In real-mode programming, far pointers are used to overcome the
problems with too small size of a single segment (64K).  When you need
to address more than 64KB, you *must* change the value loaded into the
segment register from time to time.

In contrast, in protected mode, you use far pointers to access
locations that aren't mapped into your program's address space.  In
essence, protected-mode far pointers are a means for a controlled
breach of memory protection.  (How much breach is it, and how good is
it controlled, depends on how the far pointer access is implemented.)
The selector part of the far pointer points to a segment descriptor
that specifies a portion of memory which are outside the limits of
your data segment whose selector is loaded into DS register while your
program executes.

But it is important to understand that, from the processor's point of
view, in both real- and protected-mode program, using far pointers
means just that the instruction includes a segment override, like so:

		mov es:[di], eax

This instruction will look the same in both modes.  The differences
between the generation of the physical address (seg*16+off in real
mode as opposed to several levels of indirection and protection in PM)
are entirely transparent on this level.

> When one says 'using near pointers' in the context of DJGPP, what is meant
> is that memory protection is essentially disabled; you can access any
> (absolute) address with impunity. The logic of using 'near' in this case,
> I suppose, is that turning off memory protection makes all addresses 'near'
> your program.

DJGPP's ``near pointers'' are IMHO a misnomer; ``Fat DS'' is actually
a much more accurate description.  Near pointers is what you are using
all the time when you dereference a pointer in a C program.  When you
call `__djgpp_nearptr_enable' library function, it just makes the
upper limit of your DS segment be -1, so that using normal C pointers
you can assess any address on your machine.

> (BTW: Eli: is that a short I see in the prototype? ;)

Yes; but I didn't write that code ;-).