Mail Archives: djgpp-workers/1998/04/28/05:20:39
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
- Raw text -