Mail Archives: djgpp/1999/10/06/15:38:27
On Tue, 5 Oct 1999 Fokkema DOT DBRA AT delorie DOT com wrote:
> : 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.
Instruction counts is not the whole story. You need to measure the
effect of this is a real-life program. Experience shows that the
effect is negligible to non-existent.
Also, as Shawn mentioned, the optimal use of _far* functions is to use
_farsetsel once, then use _farnspeekw in a loop; this removes the
instructions that load FS from the loop, and leaves you with a single
instruction inside the loop.
> 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.
Apparently, because nobody needed it badly enough. Those who did,
usually settle for the nearptr hack, which gets you exactly what you
want, albeit at a price of memory protection. And in many cases the
code needs to be rewritten anyway, so the far pointers is a non-issue.
This is free software we are talking about. With free software, there
are two ways of getting things done *your* way:
(a) Do it yourself. After all, since you are annoyed by the
absence of the feature, who's better than you to make it happen?
(b) Pay someone to do it. Since the compiler sources are freely
available, you need only to find a programmer willing to do the
job. For a sufficient amount of money, I bet that all the GCC
development team will be lining up ;-).
- Raw text -