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
