Based on the IBM documentation for the differences from IEEE 754 on the SPU, it could be any number of things:
- Zero results from arithmetic operations are always +0, never -0.
- Denormal inputs from 2-149 to 2-126 to arithmetic operations are treated
as zero with the same sign. Arithmetic
operations never produce denormal
results, but produce +0 instead.
- Arithmetic operations do not support IEEE Inf or NaN. These bit patterns
represent valid numbers. Overflow
results produce the maximum magnitude
value of appropriate sign.
- Arithmetic operations use only the round-to-zero (chop, truncate)
rounding mode, regardless of the
setting of the rounding mode in the
Floating-Point Status and Control
Register (FPSCR), which affects only
double-precision arithmetic
operations.
Of course, on a related page, you can also compile SPU code for strict IEEE conformance:
By default, XL C/C++ follows most, but
not all of the rules in the IEEE
standard. If you compile with the
-qnostrict option, which is enabled by default at optimization level -O3 or
higher, some IEEE floating-point rules
are violated in ways that can improve
performance but might affect program
correctness. To avoid this issue, and
to compile for strict compliance with
the IEEE standard, do the following:
- Use the -qfloat=nomaf compiler option.
- If the program changes the rounding mode at runtime, use the -qfloat=rrm
option.
- If the data or program code contains signaling NaN values (NaNS), use the
-qfloat=nans option. (A signaling NaN is different from a quiet NaN; you
must explicitly code it into the
program or data or create it by using
the -qinitauto compiler option.)
- If you compile with -O3, -O4, or -O5, include the option -qstrict after it.