Date: Tue, 5 Oct 1999 13:36:50 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: 1043730 cc: djgpp AT delorie DOT com Subject: Re: far pointers again In-Reply-To: <7tcdq7$7ug@cs.vu.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk 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.