Re: Byteswapping floating point types

[Andrew Haley <aph at redhat dot com>]

Andrew Troschinetz wrote:
> On Jul 15, 2009, at 3:44 AM, Andrew Haley wrote:
> 
>> On 07/14/2009 10:44 PM, Andrew Troschinetz wrote:

>>> But for floating point types doesn't this signature run the risk of the
>>> compiler putting a byteswapped floating point value into an FPU
>>> register, thus causing the data to be modified?
>>
>> Why would it?  Perhaps you're concerned that loading into a FPU
>> register would convert a signaling NaN into a quiet NaN, or
>> somesuch?
> 
> It is not an area in which I am well versed so I probably can't give you
> as good an answer as others on this list, but I'll give it a go. "Why
> would it?" isn't actually a valid question, you should be asking "why
> does it?" because all the tests I've done show that it does.

OK.  I'd be very interested to know what values cause problems.

> I believe the problem is that not all values of the sign, exponent, and
> mantissa of a floating point number are valid under IEEE 754.

There isn't really any redundancy in IEEE 754.  Even when a value is
NaN, the payload is supposed to be preserved through loads and stores.
It is quite possible, though, that on some machines sNaNs get turned
into qNaNs by the act of loading into registers.  I'm interested to
know if that happens, hence my question.  I don't think it should
happen, but I'm quite prepared to believe that sometimes it does.

> When you byteswap a valid floating point value you are very likely
> to get an invalid IEEE 754 floating point value, especially with
> single precision types.

You may well get a NaN, but a NaN is not an invalid IEEE 754 floating
point value.  I don't think there is any such thing.

Andrew.