Sender: bill AT taniwha DOT tssc DOT co DOT nz
Message-ID: <3545AC81.34B3F740@taniwha.tssc.co.nz>
Date: Tue, 28 Apr 1998 22:16:33 +1200
From: Bill Currie <bill AT taniwha DOT tssc DOT co DOT nz>
MIME-Version: 1.0
To: Vik Heyndrickx <Vik DOT Heyndrickx AT rug DOT ac DOT be>
CC: Nate Eldredge <nate AT cartsys DOT com>, djgpp-workers AT delorie DOT com
Subject: Re: Far string/mem functions
References: <19980427032245 DOT AAD5484 AT ppp100 DOT cartsys DOT com> <354439F1 DOT 7CC2 AT rug DOT ac DOT be> <354586DF DOT 44A78F00 AT taniwha DOT tssc DOT co DOT nz> <35459F49 DOT 6AA0 AT rug DOT ac DOT be>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk

Vik Heyndrickx wrote:
> 
> Bill Currie wrote:
> > Although not exactly accurate, why not use `long long'? Or has that been
> > suggested already?
> 
> You mean "long long unsigned", don't you ;-)

Of course:) But the number of bits was more important than the
signedness

> Not suggested until now. I thought of it a little, but there is nearly
> no use for having a single variable instead of (sel, ofs).
> 'long long' as a return value is nearly as bad as the situation
> experienced with functions like lseek that return -1 on failure: it will
> eventually turn in some problem.

True, that's why I suggested the structure hack below.

> > What about a __far_pointer structure? ie
> >
> > typedef struct {
> >     unsigned long offs __attribute__((packed));
> >     unsigned short sel __attribute__((packed));
> > } __far_pointer;
> 
> The disadvantage may be that users will have to declare a struct,

Why?  __far_pointer would be declared by the `far' function header file.

> however no objections on my part.

:)

> Returning the position within the string, however, seems still more
> useful.

But you can return a __far_pointer with the selector and offset (?
irrelevant, really, but I feel both is best) set to 0.

> Compiler support for far pointers would be useful, since the compiler's
> awareness of the segment register could mean that some of their reloads
> could be optimized out. Even when there would be no language support for
> far pointers, compiler support would be interesting.

Yeah, language support could get tricky (especially trying to declare a
far pointer to a far pointer and other nasty combinations).  But it
would certainly be nice if gcc at least knew about the segment registers
and could thus optimise their useage, (ie it would be nice to be able to
specifiy them in the parameter and clobbered parts of extended asm (gcc
automaticly saving/restoring ds & es)).

However, any efforts in this direction will have to wait till I get gcc
working on big-endian i860s.  It's become a bit of an obsession because
there's a comment in config/i860/i860.h saying that the big-endian i860
is too much trouble to support (gcc assumes mem endianness == reg
endianness, which breaks on the i860), and I want to prove it wrong. 
Unfortunatly, gcc keeps dying one way or another whenever it does an
integer multiply, but I'm learning a lot about the internals of gcc in
the process.  Cool fun, actully.

Bill
-- 
Leave others their otherness.