And Kevin Buhr writes:
-
- > What Linux does presently on x86 is as right as right can be on
- > this platform.
-
- I'm not so sure.
Let me rephrase: According to a designer of the x87 and one
of the IEEE 754 authors, the behavior currently in Linux and
glibc is reasonable on x86. Reaso
[EMAIL PROTECTED] (Kevin Buhr) writes:
> > You want peoples existing applications to suddenely and magically change
> > their results. Umm problem.
>
> So, how would you feel about a mechanism whereby the kernel could be
> passed a default FPU control word by the binary (with old binaries, by
>
Alan Cox <[EMAIL PROTECTED]> writes:
>
> You want peoples existing applications to suddenely and magically change
> their results. Umm problem.
So, how would you feel about a mechanism whereby the kernel could be
passed a default FPU control word by the binary (with old binaries, by
default, usi
> with GCC's 64-bit doubles (and its 64-bit clean but 80-bit dirty
> floating point optimizations), so I'm proposing adding an instruction
> to "init_fpu()" to change the default hardware control word.
You want peoples existing applications to suddenely and magically change
their results. Umm pro
"Adam J. Richter" <[EMAIL PROTECTED]> writes:
>
> IEEE-754 floating point is available under glibc-based systems,
> including most current GNU/Linux distributions, by linking with -lieee.
> Your example program produces the "9 10" result you wanted when linked
> this way, even when compiled
Jason Riedy <[EMAIL PROTECTED]> writes:
>
> Note that getting what some people want to call `true' IEEE 754
> arithmetic on an x86 is frightfully tricky. Changing the precision
> does not shorten the exponent field, and that can have, um, fun
> effects on and around under/overflow.
Whoops. Th
"Albert D. Cahalan" <[EMAIL PROTECTED]> writes:
> >
> > 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 m
And "Albert D. Cahalan" writes:
-
- 2. Extra precision when it comes free. The precision control is set
-to 80-bit and the compiler tries to keep values in registers.
-This is usually the more useful behavior, and it performs better.
Even better is for gcc to spill intermediate resul
Kevin Buhr writes:
> "Albert D. Cahalan" <[EMAIL PROTECTED]> 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'
IEEE-754 floating point is available under glibc-based systems,
including most current GNU/Linux distributions, by linking with -lieee.
Your example program produces the "9 10" result you wanted when linked
this way, even when compiled with -O2
When not linked with "-lieee", Lin
"Albert D. Cahalan" <[EMAIL PROTECTED]> 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
Kevin Buhr writes:
> It boils down to the fact that, under i386 Linux, the FPU control word
> has its precision control (PC) set to 3 (for 80-bit extended
> precision) while under i386 FreeBSD, NetBSD, and others, it's set to 2
> (for 64-bit double precision). On other architectures, I assume
>
12 matches
Mail list logo
