Sender: bill AT taniwha DOT tssc DOT co DOT nz
Message-ID: <354586DF.44A78F00@taniwha.tssc.co.nz>
Date: Tue, 28 Apr 1998 19:35:59 +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>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk

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?

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.  BTW, I have a C++
class that (sort of) provides far pointers.

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.