Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: Bill Currie <bill AT taniwha DOT tssc DOT co DOT nz>,
        Vik Heyndrickx <Vik DOT Heyndrickx AT rug DOT ac DOT be>
From: Nate Eldredge <nate AT cartsys DOT com>
Subject: Re: Far string/mem functions
Cc: djgpp-workers AT delorie DOT com
Date: Tue, 28 Apr 1998 20:37:47 -0700
Message-ID: <19980429033703.AAK3301@ppp104.cartsys.com>
Precedence: bulk

At 07:35  4/28/1998 +1200, 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?

That's pretty ugly as far as type-checking goes. I personally am more
inclined to use the pass-by-reference scheme.

>What about a __far_pointer structure? ie
>
>typedef struct {
>    unsigned long offs __attribute__((packed));
>    unsigned short sel __attribute__((packed));
>} __far_pointer;
>
>This will even give type checking on parameters.  Does gcc return 6 byte
>values in regs?  I'm not sure which section to check.

As my tests indicate, it does not. :(
>
>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).
>
>Bill
>-- 
>Leave others their otherness.
>

Nate Eldredge
nate AT cartsys DOT com