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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
