On 27 September 2011 05:29, Andi Kleen <a...@firstfloor.org> wrote: > Peter Maydell <peter.mayd...@linaro.org> writes: >> The answer is that the edge cases basically never match. No CPU >> architecture does handling of NaNs and input denormals and output >> denormals and underflow checks and all the rest of it in exactly >> the same way as anybody else. (In particular x86 is pretty crazy, > > Can you clarify this? > > IEEE754 is pretty strict on how all these things are handled > and to my knowledge all serious x86 are fully IEEE compliant. > Or are you refering to the x87 80bits expansion? While useful > that's not used anymore with SSE.
IEEE leaves some leeway for implementations. Just off the top of my head: * if two NaNs are passed to an op then which one is propagated is implementation defined * value of the 'default NaN' is imp-def * whether the msbit of the significand is 1 or 0 to indicate an SNaN is imp-def * how an SNaN is converted to a QNaN is imp-def * tininess can be detected either before or after rounding which different architectures vary on (and some are better at documenting their choices than others). Also implementations often have extra non-IEEE modes (which may even be the default, for speed): * squashing denormal outputs to zero * squashing denormal inputs to zero and there's even less agreement here. Common-but-not-officially-ieee ops like 'max' and 'min' can also vary: for instance Intel's SSE MAXSD/MINSD etc have very weird behaviour for the special cases: if both operands are 0.0s of any sign you always get the second operand, so max(-0,+0) != max(+0,-0), and if only one operand is a NaN then the second operand is returned whether it is the NaN or not (so max(NaN, 3) != max(3, NaN). > On the other hand qemu is not very good at it, e.g. with x87 > it doesn't even pass paranoia. This is only because nobody cares much about x86 TCG. ARM floating point emulation is (now) bit-for-bit correct apart from a handful of operations which don't set the right set of exception flags. -- PMM