<bryce <at> kampjes.demon.co.uk> writes:

> 
> nicolas cellier writes:
>  > I don't even know which hardware supports or not these traps...
>  > I even wonder if such features were mandatory...
>  > That should not stop us: as suggested, Smalltalk is already sufficiently 
>  > slow to afford a sticky flag test at each Float primitive in case no 
>  > hardware trap is available.
> 
> Hopefully Smalltalk will not always be that slow.
> 
> All we'd need to do was remove the boxing and unboxing around
> floating point operations. Inside single statements, that is
> equivalent to the Boolean optimisations that Exupery already
> does. Across statements will require a proper optimiser.
> 
> Bryce
> 
> 

Great, but if FPU registers are using extra precision (extended double),
then the result of operations might depend on register/memory exchange.

Let's compute (a*b*c) where a,b,c are double precision (Float in squeak).
Let selectors:
- d2e mean (convert double to extended)
- e2d mean (convert extended to double)

For a double d, (d d2e e2d = d) is always true
For an extended e, (e e2d d2e = e) might be false because some bits are lost.

Unoptimized Smalltalk does:
((a d2e * b d2e) e2d d2e * c d2e) e2d.
which should - thanks to IEEE 754 - be strictly equivalent to:
(a * b) * c.

But optimized Smalltalk might evaluate:
((a d2e * b d2e) * c d2e) e2d.
Which is no more equivalent in case (a*b) is inexact...
Of course, result will be more accurate.
But impossible to have bit-identical results depending on optimization level...

Do you plan forcing e2d conversions in generated code?
If not, you will trade bit-identical property for speed
(as most i86 C compilers already do).
Smalltalk vm will fail being hardware independent...
(I suspect this is already the case for libm sin, log etc...)

IMO user should keep control over precision, and not let uncontrolled tools take
fancy decisions.
The right way if we eventually want to profit from this extra precision is to
introduce an ExtendedDouble class (like gst did).

Nicolas