Re: RFC: changing precision control setting in initial FPU context

[Kevin Buhr]

"Albert D. Cahalan" <[e-mail]> writes:
> 
> So you change it to 2... but what about the "float" type? It gets
> a mixture of 64-bit and 32-bit IEEE arithmetic depending rather
> unpredictably on compiler register allocations and optimizations???

Well, yes, but I'll try not to cry myself to sleep over it.  I'm
tempted to say that someone who chooses to use "float"s has given up
all pretense of caring about the answers they get.  And, if they
really want to do predictable math with floats they can change the FPU
control word from whatever its default is to PC==0.

I guess if I had to choose between two default control word settings
so that either (A) "float" arithmetic is unpredictable but "double"
arithmetic is predictable, corresponds to 64-bit IEEE arithmetic, is
invariant under different compiler optimization settings, matches the
compiler's handling of constant folding, and mimics the behavior on
i386 FreeBSD and NetBSD and most modern, non-i386 architectures; or
(B) "float" and "double" arithmetic are both unpredictable and
non-IEEE; I'd choose (A).

> If a "float" will have excess precision, then a "double" might
> as well have it too. Usually it helps, but sometimes it hurts.
> This is life with C on x86.

That's the way I initially felt, and it looks silly when it's written
down, so I'm glad I changed my mind.

I don't think extra precision that is unpredictable is ever helpful.
Extra precision that might be gained or lost depending on, say, which
branch of an if-statement is taken, is of no use to anyone.  It just
causes confusion.  The excess precision on "float" is a nuisance.  The
excess precision on "double" is another nuisance.  It would be nice to
eliminate one of those nuisances, at least by default.

> Ugh, more start-up crud.

The startup crud is already there.  It's used to allow linking with
"-lieee" to set a new control word value, for example, and it's
inelegant and ugly.  Because we don't want to set the control word on
a non-FPU program and defeat the lazy FPU context initialization, we
compare the value of the control word we want with a value hard-coded
into the library that's supposed to match the value hard-coded into
the kernel.  If the two values differ, we set the control word to the
new value (whether the program actually ends up ever executing an FPU
instruction or not).

To me, a system call (not necessarily a *new* system call, but some
way to get the desired FPU control word to the kernel) seems like a
more elegant solution.

On the other hand, I'm not married to the idea.  I'd rather just get
the default control word changed in the kernel.

Kevin <[e-mail]>