Date: Wed, 18 Jul 2001 09:12:07 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: "Albert D. Cahalan" <acahalan@cs.uml.edu> Cc: freebsd-hackers@FreeBSD.ORG, Jim.Pirzyk@disney.com Subject: Re: math library difference between linux emulation and native freebsd Message-ID: <3B55B557.DADB3107@mindspring.com> References: <200107171802.f6HI2OV422095@saturn.cs.uml.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
"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 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?3B55B557.DADB3107>