Re: Bytes order and words order

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

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.

-- Gaby