Date:	Tue, 5 Oct 1999 13:36:50 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	1043730 <dfokkema AT cs DOT vu DOT nl>
cc:	djgpp AT delorie DOT com
Subject:	Re: far pointers again
In-Reply-To:	<7tcdq7$7ug@cs.vu.nl>
Message-ID:	<Pine.SUN.3.91.991005132648.4115E-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Tue, 5 Oct 1999 Fokkema DOT DBRA AT delorie DOT com wrote:

> I wonder why djgpp doesn't have support for far pointers.

Because GCC, the compiler we use, doesn't know about memory 
segmentation.  It thinks that memory is a single flat address
space.

> As I understand,
> gcc is ported from unix and it will work under various unix variants like
> linux. I was told that under linux, one can create other descriptors in the
> ldt and reference to them by using far pointers (of course).

The same can be done in DJGPP.  Take a look at Chapter 18 of the DJGPP 
FAQ list, it is full of explanations of the several available ways of 
creating desriptors in the LDT and referencing them with the so-called 
``_farptr'' functions.

> If this is all
> true, I would say that gcc should support far pointers to easily reference
> to these segments.

I'd guess that you'd need to do the same on Linux.  In other words, you
cannot have a true 48-bit far pointer in Linux, unless you do it in 
assembly.

Can someone who has easy access to Linux check that?

> Right now, I have to use temporary variables to store the
> information when I decide to, say, use printf to display a number which is
> stored in another segment. When I want to print a string part stored in
> another segment I should design a printf which handles far pointers or copy
> the string to the ds segment? I don't know exactly what to do

Use movedata to fetch the string into a normal buffer, then print it as 
usual.

> but it sure
> generates a lot more inefficient code than any compiler which does support
> far pointers.

Did you measure the performance hit with the DJGPP _far* functions?  If 
not, how do you know that it ``generates a lot more inefficient code''?

You might look at the sources of _far* functions and movedata: they all 
are written in fast assembly that works exactly as optimal code emitted 
by a compiler would.  Measurements generally confirm that there's no 
visible performance penalty, even if you compare with the nearptr hack.  
The only inconvenience is that you need to call a function instead of a 
pointer dereference, or call special functions instead of ANSI-standard 
ones.  Not a big deal, IMHO, when you are dealing with highly platform
dependent stuff that requires multiple segments.

- Raw text -