This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: IEEE extended real formats

Ian Lance Taylor <> writes:

> Zack Weinberg <> 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:
>     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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]