On 09.01.2009, at 05:31, Tim Olson wrote:

On Jan 8, 2009, at 9:30 AM, Hans-Martin Mosner wrote:

...

AFAIK, the Croquet project needs to have exactly reproducible float arithmetics on all platforms. Would these rounding effects on the x86 affect that goal (perhaps with denormal intermediate results)?

Yes.

...

Maybe it would be nice to write a unit test which would uncover different rounding behaviors between purely-double-precision FP hardware and extended-precision hardware.

I'd have to play around a bit to get this into a Squeak unit test, but here's a test vector which shows the effect:

3ff3208a25e04e87 * 000316dd1d02d1ae

x86 result: 0003b16ef930a76e powerPC result: 0003b16ef930a76f

These are IEEE double-precision floating-point numbers, specified in hex (big-endian) so that they are bit exact (no conversion error from a decimal representation). The first number is between 1.0 and 2.0, while the second number is a denormal value. The product shows an lsb difference between an x86 platform (extended-precision FPU) and a PPC platform (double-precision FPU), even when the x86 floating-point control word is set to use double-precision rounding for all results.

On my Intel Mac with VM 3.8.17b6 I get ...a76f too, so this is not an x86 issue.

a := Float newFrom: #(16r3FF3208A 16r25E04E87). b := Float newFrom: #(16r000316DD 16r1D02D1AE). {a hex. b hex. (a*b) hex}

#('3FF3208A25E04E87' '000316DD1D02D1AE' '0003B16EF930A76F')

I do get ...a76e under Linux (x86 VMWare emulation).

- Bert -