This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: IEEE extended real formats
Ian Lance Taylor <ian@wasabisystems.com> writes:
> Zack Weinberg <zack@codesourcery.com> writes:
>
>> (Motorola) SEEE 0000 MMMM MMMM MMMM MMMM (big-endian)
>> MMMM MMMM MMMM MMMM 0000 EEES (little-endian)
>
> Note that there is no little endian case for m68k.
Right, I was being exhaustive.
...
> The code at the end of encode_ieee_extended() is this:
>
> if (FLOAT_WORDS_BIG_ENDIAN)
> buf[0] = image_hi << 16, buf[1] = sig_hi, buf[2] = sig_lo;
> else
> buf[0] = sig_lo, buf[1] = sig_hi, buf[2] = image_hi;
>
> Big endian is the m68k case, with the gap between the mantissa and the
> exponent (caused by the << 16). In the little endian case, which is
> the x86, there is no such gap. I think the bit pattern comes out like
> this:
>
> (Intel 96) MMMM MMMM MMMM MMMM EEES 0000 (little)
>
> There is no big endian case for the x86. I don't know about the ia64.
Oh, ugh, so it's using FLOAT_WORDS_BIG_ENDIAN to decide whether it's
in the Motorola or the Intel mode.
This comes up because (unlike the x86) the ia64 *does* have a
big-endian mode, and HPUX runs it in that mode, but it still wants the
Intel format. So the assumption that FLOAT_WORDS_BIG_ENDIAN implies
Motorola format is untrue for ia64-hpux.
I'm still not sure where the padding goes for
ieee_extended_intel_128_format. Currently it's put at the beginning
for big-endian mode, which is wrong for ia64. But since the only
other user is x86 which only ever uses it in little-endian mode, it's
probably safe to make it the ia64 format. Thoughts?
zw