Re: Floating-point Consistency, -ffloat-store, and x86 (mostly)

[hjstein at bfr dot co dot il (Harvey J. Stein)]

Unfortunately, I read your original post after I sent my other msg.
Here are some comments & questions.

I see your point about how doing 80 bit spills would help to reduce
numerical uncertainty.

However, I don't understand why you claim that leaving the CPU in 64
bit mode would be problematic.

It would seem to me that the only code that would appropriately rely
on the registers being extended precision would have to be either hand
written assembler or *extremely* carefully written code in a higher
level language.  I'd think that anyone capable of doing this would
also be cognizant of the issues involved & quite capable of saving,
setting & restoring the FPU control word appropriately.

So, I don't see why you're claiming that the FPU control word would
have to be fiddled on the fly according to embedded object code
notations.

Also, you said that leaving the FPU in 64 bit mode isn't a full
solution because of double rounding.  It seems to me that the double
rounding is only an issue near the edges of the range of a double, and
as such is also a small problem.  After all, one thing that people
expect from floating point math is trailing garbage, and this would
just be another example - another check on the paranoia tests.

I think the biggest problem is the places where the underlying
extended precision registers are exposed to programmer.

There's no way for a programmer in a higher level language to
currently get at the values in the extended precision registers, nor
is there a way to explicitely use them.  However, their existence is
exposed by comparison operations.  This is what leads to all sorts of
insanities such as 1.0/3.0 != 1.0/3.0 (when done appropriately with
variables).

This is why I think the best thing would be to just default the FPU to
double precision (not extended precision) mode, or at least make it
easily settable.  It removes the difference between comparing
registers & memory, and makes numerics as register vs memory usage
independent as they can be on an ix86 in a higher level language.

Although spilling in extended precision would make things somewhat
more consistent, I don't think it'd be consistent enough to really
help - it'd still mostly leave the comparison problems.  It'd also
still leave the uncertainties of when extended precision gets used
because the compiler is still free to decide when and how things move
into registers.

I guess the only problem with:

   __setfpucw ((_FPU_DEFAULT & ~_FPU_EXTENDED) | _FPU_DOUBLE);

really is a portablility issue.  Maybe I'll try it on my code where
I've had to resort to -ffloat-store and see if it helps.

-- 
Harvey J. Stein
BFM Financial Research
hjstein@bfr.co.il