From owner-freebsd-hackers Wed Jul 18 9:11:37 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from harrier.mail.pas.earthlink.net (harrier.mail.pas.earthlink.net [207.217.121.12]) by hub.freebsd.org (Postfix) with ESMTP id 10B2437B403 for ; Wed, 18 Jul 2001 09:11:33 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (dialup-209.247.138.210.Dial1.SanJose1.Level3.net [209.247.138.210]) by harrier.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id JAA04921; Wed, 18 Jul 2001 09:11:30 -0700 (PDT) Message-ID: <3B55B557.DADB3107@mindspring.com> Date: Wed, 18 Jul 2001 09:12:07 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Albert D. Cahalan" Cc: freebsd-hackers@FreeBSD.ORG, Jim.Pirzyk@disney.com Subject: Re: math library difference between linux emulation and native freebsd References: <200107171802.f6HI2OV422095@saturn.cs.uml.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "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