This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Bytes order and words order
On Fri, Aug 23, 2002 at 06:49:39PM +0200, Gabriel Dos Reis wrote:
> Matt Austern <austern@apple.com> writes:
>
> | On Friday, August 23, 2002, at 05:04 AM, Gabriel Dos Reis wrote:
> |
> | > OK, thanks. I was actually thinking of the word-order of
> | > floating-point numbers not that of integral types. I think I should
> | > name it __TARGET_FLOAT_WORDS_ORDER__ ?
> | > Is it reasonable to assume that the byte order of integral and
> | > floating point coincide?
> |
> |
> | For floating-point numbers, don't you need a lot more than
> | just "word order"?
>
> Yes, you're right, I would need more than just that.
> But for the kind of issues I have to sort out in the short term, those
> will be sufficient along with knowledge rippled out of real.[ch].
>
> | The last time I checked this out (about
> | a year ago), I thought I'd convinced myself that, even if I
> | knew endianness and knew that float and double were IEEE
> | format, I didn't know quite enough to find the individual
> | bits.
>
> How so?
>
> | And don't forget that on many systems you *don't*
> | know that floating-point types are IEEE: long double
> | tends not to be.
>
> Right. That is why the missing bits will be filled in by
> port-maintainers (much in the same way we did for integers limits)
> :-)
>
> For example, while on a big or little-endian (for both bytes and words)
> machine implementing IEEE-754 and using a 64-bit wide double, I could
> plugin a generic definition for infinities, QNaN, SNaN, a
> port-maintainer for VAX or ARM, for example, would have to give the
> appropriate bytes.
>
> | I started working on a system to parameterize extraction
> | of the various parts of an fp number (sign bit, mantissa,
> | most-significant-mantissa-bit if the format has one,
> | exponent, exponent bias). I used a table lookup system,
> | and set a flag in the header to identify the architecture.
> | But your idea of getting this from the compiler is better.
>
> Well, what mostly is annoying me in my proposed scheme is that it
> would somehow duplicate some information mostly with real.[ch]. That
> really makes me uneasy. On a previous attempt, I tried to have
> real.[ch] act like part of the C++ library, that was way too invasive
> and too tighly coupled with GCC's internals. I'm open to suggestions.
Libiberty has a file in it called floatformat.c. You'd need to play
some licensing games to use it but it should have everything you need;
that's how GDB understands target floats.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer