"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.
Read the standard: the initial state of the mask is undefined
by it.
> > 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.
> ^^^^
Yes; or more correctly, "incorrect Linux apps fail", since
Mathematica is a Linux app, yet does not fail.
> 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.
Not to mention what it does to the trap handler for your
initial FPU trap.
> > 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)
"ate" != "eat". See my previous post. I don't need to be
corrected: I know how Linux currently operates, and how it
has operated historically.
IMO, permitting a program using FP to assume that the mask
is a specific value before it sets it is as bad as Linux
allowing people to use stack crap for the contents of the
sockaddr_in struct (a common practice in networking programs
written to assume Linux, including the Sun Microsystems
SLPv1 reference implementation), or assuming that you can
pass a NULL pointer to strcmp()/strcat()/etc., and have the
C library treat it as "".
> > 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".
Works great... I did mention that I set my FP mask before
using FP, because I'm not assuming the state of the mask
before my program is marked as an FP-using program, right?
> > 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.
Bull. It's infinitely worse. It promotes bad coding
practices, a lack of rigor in problem solving, and the
assumption that "all the word's Linux" -- which is no
better an assumption than "All the world's a VAX".
> >> 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.
Yeah: a mask setting function.
> 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.
Uninitialized behaviour of x86 hardware sucks: what can I say?
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message