Bytes order and words order

[Daniel Jacobowitz]

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