Sender: vheyndri AT rug DOT ac DOT be
Message-Id: <35459F49.6AA0@rug.ac.be>
Date: Tue, 28 Apr 1998 11:20:09 +0200
From: Vik Heyndrickx <Vik DOT Heyndrickx AT rug DOT ac DOT be>
Mime-Version: 1.0
To: Bill Currie <bill AT taniwha DOT tssc DOT co DOT nz>
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>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk

Bill Currie wrote:
> 
> Vik Heyndrickx wrote:
> >         int _far_memchr (size_t *ret_ofs,
> >                          short unsigned sel,
> >                          long unsigned ofs,
> >                          long unsigned count,
> >                          char c);
> 
> Although not exactly accurate, why not use `long long'? Or has that been
> suggested already?

You mean "long long unsigned", don't you ;-)
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.

> 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,
however no objections on my part. 
Returning the position within the string, however, seems still more
useful.

> Also, as I have recently been fighting gcc to get it to work on the i860
> in big-endian mode (mostly with `multsi', what a bugger of an
> instruction to implement on the i860), with some pretty good success
> today, I'm beginning to feel confident about tackling giving gcc a `far
> pointer' class, though the RTL may prove interesting, and I will have to
> re-learn trees (did some work on GNU Pascal last year).

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.

-- 
 \ Vik /-_-_-_-_-_-_/
  \___/ Heyndrickx /
   \ /-_-_-_-_-_-_/  Knight in the Order of the Unsigned Types