DRC floating point semantics

[cuavas]

First of all, yes, I know the UML SETFMOD instruction is currently only partially implemented for AArch64 (right now it only applies to float-to-integer conversion). I’ll fix it eventually. It affects PowerPC and MIPS III, but not other recompiling CPU cores.

Currently on x86-64 and i686, the rounding mode set using SETFMOD is exposed to functions called from DRC code (memory access handlers, functions called using CALLC, the debugger instruction hook, etc.). Is this desirable, or should it set up the original rounding mode when calling out to non-generated functions? Calling the debugger instruction hook with a possibly different rounding mode strikes me as a bit sus at the very least.

There’s currently a difference in semantics for unordered floating point compare:

• x86-64 and i686 set unordered (U), zero (Z) and carry (C), leaving sign (S) unchanged (inherited from the way x87 set C2/C3/C0) – this does not match the documentation which states Z is set for equal or cleared otherwise and C is set for less than or cleared otherwise
• AArch64 and C set unordered (U) and clear zero (Z), carry (C) and sign (S) – this matches the documentation (a somewhat unusual case where the C back-end is actually “correct”)

IEEE 754 states that precisely one of less than, equal to, greater than and unordered is to be true after a comparison. To achieve this, you have to check unordered (UML U condition) before checking equal to (UML E/Z condition) or less than (UML C/B condition) to get the right result on x86-64 or i686 (you always need to check U before checking A to get the correct result for greater than).

This could be “fixed” by making the documentation say Z and C are undefined for an unordered result, but would it be better to make x86-64 produce the currently documented behaviour at the cost of making the UML FCMP instruction more expensive?

And finally (for now), FCMP is slightly more expensive than it needs to be on AArch64 because AArch64 overloads the overflow flag for the unordered condition while UML has separate flags for these, so a CPU core could in theory use SETFLGS to set the overflow and unordered flags to different values. Of course, addressing this probably isn’t worth the effort.

[cuavas]

First of all, yes, I know the UML SETFMOD instruction is currently only partially implemented for AArch64 (right now it only applies to float-to-integer conversion). I’ll fix it eventually. It affects PowerPC and MIPS III, but not other recompiling CPU cores.

Well, that’s done for the AArch64 and C back-ends. It wasn’t really too hard in the end. The rest of the stuff still applies, though.