This is the mail archive of the gcc-help@gcc.gnu.org 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: Byteswapping floating point types


On Jul 15, 2009, at 10:13 AM, Andrew Haley wrote:

Andrew Troschinetz wrote:

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'm fairly sure you know more about this than I do. I did some further testing and it appears some assumptions I've made are clearly wrong. One value that can be used to demonstrate the problem I'm seeing is 50.125484.


This test: http://codepad.org/OZhEz0az shows that before being swapped the bit layout is:

01000010010010001000000001111111

However after being swapped the value isn't what we would expect:

01111111110000000100100001000010

I would expect a 0 in the location of the first fraction bit, but instead we have a 1.

Then after being swapped again the layout isn't back to what it was before, but instead it is:

01000010010010001100000001111111

And so 50.125484 becomes 50.187984.

Now I'm not sure what causes this exactly. Do you have any ideas?

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.

I misspoke. I meant to say that if an invalid floating point value were loaded into a FPU register, bits in the *exponent*, not mantissa, would be set to 1 to make the number NaN. However with the test value 50.125484, all bits in the exponent of the swapped value are 1. So my claim that the data corruption comes from bits in the exponent being flipped to make the number NaN is clearly false. Somehow a bit in the mantissa is getting flipped though.


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.

I didn't mean to imply that NaN was invalid, but that an invalid value would be transmogrified into NaN by virtue of it being put into a FPU register. But if no IEEE 754 float is invalid, then what is causing the issue?


--
Andrew Troschinetz
Applied Research Laboratories


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