Date: Tue, 17 Jul 2001 14:02:24 -0400 (EDT) From: "Albert D. Cahalan" <acahalan@cs.uml.edu> To: tlambert2@mindspring.com Cc: acahalan@cs.uml.edu (Albert D. Cahalan), freebsd-hackers@FreeBSD.ORG, Jim.Pirzyk@disney.com Subject: Re: math library difference between linux emulation and native freebsd Message-ID: <200107171802.f6HI2OV422095@saturn.cs.uml.edu> In-Reply-To: <3B546BA9.37E9F437@mindspring.com> from "Terry Lambert" at Jul 17, 2001 09:45:29 AM
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert writes:
> "Albert D. Cahalan" wrote:
>>> The defaults for the Linux emulator are different than
>>> the defaults for Linux. Linux sets some stuff up wrong,
>>
>> FreeBSD sets stuff up wrong. This is a choice between bad
>> and worse, since the CPU does not support what you want.
>
> FreeBSD complies strictly with the IEEE FP standard.
As long as you don't ever use "float" or "long double", yes.
The "float" type isn't seriously broken, while "long double" is.
> Linux fails to set 0x37f into the mask before doing
> its calculations, and assumes that the OS has done this
> for it. In Linux it's true, in the emulator, it's not;
You mean "Linux apps fail to..." I think.
^^^^
Certainly. The initial FPU control word is part of the ABI.
Explicitly setting this would mark a process as being an
FPU user, which would then be shown in "ps" output.
Setting cast-in-stone defaults is also a waste of CPU time.
> One obvious reason that the Linux approach is wrong is
> that it ends up requiring the save and restore of FP
> registers on context switches, which is overhead they
> ate anyway, by doing TSS based context switching.
No and no. (that was true at one time)
>> An x86 CPU has a rounding precision that may be set for
>> float, double, or long double. FreeBSD sets the CPU to
>> make double work, giving extra fraction bits for float
>> and truncating long double. Linux sets the CPU to make
>> long double work, giving extra fraction bits for both
>> float and long double. Now what is worse, getting some
>> extra bits in an intermediate calculation or truncation?
>> Note that the FreeBSD setting causes _both_ problems.
>
> FreeBSD's settings do not cause problems for FreeBSD; as
> has been observed in this thread, FreeBSD gets the right
> answer when you run the code native, just as Linux does;
Try again with "long double".
> the emulator gets the wrong answer, but the problem is
> really the programs assuming that the mask will be set
> by the OS to the "magic" correct value.
It's no worse than assuming /dev/null will exist.
>> See float_t, double_t, FLT_EVAL_METHOD and FLT_ROUNDS in
>> the 1999 C standard for ways to deal with x86 hardware.
>
> The standards are not x86 specific; the fp*() functions
> are.
The standards have what you need to deal with x86 hardware.
They give software a way to handle evaluation with excess
fraction bits in intermediate calculations.
Most fp*() functions work great on a SPARC with Solaris.
The precision control isn't quite x86-specific. The i860
has this problem too AFAIK.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200107171802.f6HI2OV422095>