[endian] Floating point reversal return by value concerns
On Mon, Jan 26, 2015 at 11:25 PM, Cliff Green <cliffg@codewrangler.net> wrote:
..., I do have concern about one aspect of the new functionality (or maybe I didn't read deep enough in the docs) - floating point endian reversal functions which return by value.
Unless something has significantly changed in the last few years, swapping and returning floating point values is likely to silently change bits for certain bit patterns / values. In particular, returning by value will normalize some values (I assume as part of loading or accessing the value into floating point CPU registers). There may be other floating point characteristics that silently change the bits dealing with NaN and infinity values (but I'm far from an expert on floating point computations).
Could you please provide code for one or more return-by-value test cases that fail because the value gets normalized? I'm really hesitant to change anything without having test cases to work with. That would also help with documenting the specifics of the problem. Thanks, --Beman
On 18/03/2015 11:36, Beman Dawes wrote:
On Mon, Jan 26, 2015 at 11:25 PM, Cliff Green <cliffg@codewrangler.net> wrote:
..., I do have concern about one aspect of the new functionality (or maybe I didn't read deep enough in the docs) - floating point endian reversal functions which return by value.
Unless something has significantly changed in the last few years, swapping and returning floating point values is likely to silently change bits for certain bit patterns / values. In particular, returning by value will normalize some values (I assume as part of loading or accessing the value into floating point CPU registers). There may be other floating point characteristics that silently change the bits dealing with NaN and infinity values (but I'm far from an expert on floating point computations). Could you please provide code for one or more return-by-value test cases that fail because the value gets normalized?
I'm really hesitant to change anything without having test cases to work with. That would also help with documenting the specifics of the problem.
I don't think this should *ever* happen - well with one possible exception - on Intel x87 hardware an 80-bit register value may get rounded to a 64-bit value at unpredictable times (ie only when it's written to memory). I can't see that would be an issue here since Beman is already doing bit-fiddling on the value, it must by it's very nature be in memory and not a register. I don't remember the specifics but return by value may actually be a return-by-register for some ABI's.... ah wait.... Beman are you returning by value a non-native representation? If so I imagine that may be an issue as the value gets moved to and from a register: some bit values are not permitted I believe - it's anybodies guess what the hardware would do to those? You could actually test all possible bit-patterns in a float and see if this is a real issue? John.
On Wed, Mar 18, 2015 at 1:12 PM, John Maddock <jz.maddock@googlemail.com> wrote:
On 18/03/2015 11:36, Beman Dawes wrote:
On Mon, Jan 26, 2015 at 11:25 PM, Cliff Green <cliffg@codewrangler.net> wrote:
..., I do have concern about one aspect of the new functionality (or maybe I didn't read deep enough in the docs) - floating point endian reversal functions which return by value.
Unless something has significantly changed in the last few years, swapping and returning floating point values is likely to silently change bits for certain bit patterns / values. In particular, returning by value will normalize some values (I assume as part of loading or accessing the value into floating point CPU registers). There may be other floating point characteristics that silently change the bits dealing with NaN and infinity values (but I'm far from an expert on floating point computations).
Could you please provide code for one or more return-by-value test cases that fail because the value gets normalized?
I'm really hesitant to change anything without having test cases to work with. That would also help with documenting the specifics of the problem.
I don't think this should *ever* happen - well with one possible exception - on Intel x87 hardware an 80-bit register value may get rounded to a 64-bit value at unpredictable times (ie only when it's written to memory). I can't see that would be an issue here since Beman is already doing bit-fiddling on the value, it must by it's very nature be in memory and not a register. I don't remember the specifics but return by value may actually be a return-by-register for some ABI's....
ah wait.... Beman are you returning by value a non-native representation?
Yes.
If so I imagine that may be an issue as the value gets moved to and from a register: some bit values are not permitted I believe - it's anybodies guess what the hardware would do to those?
Ouch!
You could actually test all possible bit-patterns in a float and see if this is a real issue?
That's doable. I'll give it a try. --Beman
ah wait.... Beman are you returning by value a non-native representation? Yes.
If so I imagine that may be an issue as the value gets moved to and from a register: some bit values are not permitted I believe - it's anybodies guess what the hardware would do to those? Ouch!
On reflection there's another more serious concern: depending on the FPU flags set, NaN's, whether signalling or otherwise, may raise a hardware exception when loaded to a register. The end result is your program aborts (unless you have some special handling in effect). My "favorite" example, was Borland's compiler/runtime, which set up the flags so that even calling numeric_limits<>::quiet_NaN() would abort your program :( John.
participants (2)
-
Beman Dawes -
John Maddock