From: Fokkema DOT DBRA AT delorie DOT com, 1043730 <dfokkema AT cs DOT vu DOT nl>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: far pointers again
Date: Tue, 5 Oct 1999 12:58:24 GMT
Organization: Fac. Wiskunde & Informatica, VU, Amsterdam
Lines: 39
Message-ID: <7tcslg$ffj@cs.vu.nl>
References: <7tcdq7$7ug AT cs DOT vu DOT nl>
NNTP-Posting-Host: galjas.cs.vu.nl
X-Newsreader: TIN [version 1.2 PL2]
X-Poster-Key: sha1:wab9FJt0VgI5zkryexlImIpvmiY=
Cancel-Lock: sha1:y7dzH2p6+k3DgBQx+M14eaSvJDQ=
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com


: generates a lot more inefficient code than any compiler which does support
: far pointers.
Eli Zaretski (I hope I spell it correct) asked me how I knew this. Well, IMHO
I think that code like:

	i = FARPEEKW(SEL, OFFSET);           <= or something like that
	printf("%d", i);

which results in:

	mov	ebx,SEL			     <= I believe this is what the
	mov	es,ebx			     <= far pointer functions do.
	mov	ebx,OFFSET		     <= At least some suggested macros
	mov	[ebp-x],word ptr es:[ebx]    <= do.

	push	word ptr [ebp-x]	     <= this is what i remember from
	push	dword ptr [y]		     <= what i checked already. but i
	call	_printf			     <= could be incorrect.

is somewhat less efficient than:

	printf("%d", *this_is_a_far_pointer);

which results in:

	push	dword ptr [ebp-z]
	push	dword ptr [y]
	call	_printf

At least it is programmersfriendlier to code. Why didn't someone take the
time to implement far pointers for ease of all those apparantly not totally
sane people like me who just want to use another segment without having to
use frustrating macros.

: Maybe I'm wrong on some points, so please correct me or post other comments.
Also goes for this one.

David