From owner-freebsd-current Wed Oct 30 15:23:46 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7376C37B401 for ; Wed, 30 Oct 2002 15:23:43 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7BC8943E7B for ; Wed, 30 Oct 2002 15:23:42 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.3/8.12.3) with ESMTP id g9UNNTpk049160; Wed, 30 Oct 2002 16:23:35 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 30 Oct 2002 16:22:39 -0700 (MST) Message-Id: <20021030.162239.52163953.imp@bsdimp.com> To: bde@zeta.org.au Cc: rittle@labs.mot.com, rittle@latour.rsch.comm.mot.com, current@FreeBSD.ORG, dschultz@uclink.Berkeley.EDU Subject: Re: Lack of real long double support From: "M. Warner Losh" In-Reply-To: <20021030215500.E5692-100000@gamplex.bde.org> References: <20021030.012222.123041962.imp@bsdimp.com> <20021030215500.E5692-100000@gamplex.bde.org> X-Mailer: Mew version 2.1 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <20021030215500.E5692-100000@gamplex.bde.org> Bruce Evans writes: : The reasons are the same as they used to be: incomplete language support : and incomplete library support. Language support is being completed but : is far from here yet. See the paper referenced in Loren's reply for more : details than anyone should want to know. OK. I'll have to go back and find that reference. I'd really like to change the __INITIAL_NPXCW__ from 0x127f to 0x137f in npx.h. I think that we can get the library support in place over time, as this already is a bullet item in the standards todo list web page. The gcc 3.2 compiler does a decent, but not perfect, job of dealing with the floating point stuff. I'll have to dive into the archive to find said paper. : > : > : gcc 3.3 will support a framework in which such changes would be easy : > : > : to convey at compile-time but, to my knowledge, there is no support : > : > : yet to obtain e.g. the precision setting at run-time. I.e. : > : : > : FreeBSD (on i386's) has fpgetprec() to get it and fpsetprec() to set it, : > : but these are nonstandard and won't become standard. They don't exist : > : on most or all non-i386's now, unlike fpget/setround() which will become : > : the standard feget/setround(). : > : > Is there some reason we can't just put them into the machine specific : > startup code like I've done with the tree. : : Putting them there would just blow away the kernel default. There are : arguments for putting the in both places, but not at the same time. : Linux seems to have gone the other way and move the initialization : from crt to the kernel. I'm not sure what happened to moves to set the : Linux default for Linux applications in the kernel. Yea, putting it in crt is bogus. Forget I suggested it. : C99 encourages having a behaviour that is known at compile time and : telling applications about it in FLT_EVAL_METHOD (this can be set to : -1 == indeterminable, but that would not be very useful although it : is the only correct setting now). The compiler should implement the : system implementor's choice or enforce its own choice. gcc doesn't : really understand this this. gcc-3.2 thinks that it implementing : method 0 (no extension of precision) but the npx hardware is nothing : like that. I don't understand this completely. ARe you saying that gcc is doing something worng? : The compiler doesn't have any special problems knowing the state of : the precision control on entry to functions. It just needs the initial : value to be set correctly and the state to not change underneath it : like it already requires for other aspects of the state. Changing the : state using fpset*() counts as changing the state underneath it here. I do understand this, which is why changing the defaults seems reasonable to me. BTW, NetBSD is kinda schizophrenic about this: /* * The i387 defaults to Intel extended precision mode and round to nearest, * with all exceptions masked. */ #define __INITIAL_NPXCW__ 0x037f /* NetBSD uses IEEE double precision. */ #define __NetBSD_NPXCW__ 0x127f /* FreeBSD leaves some exceptions unmasked as well. */ #define __FreeBSD_NPXCW__ 0x1272 /* iBCS2 goes a bit further and leaves the underflow exception unmasked. */ #define __iBCS2_NPXCW__ 0x0262 /* Linux just uses the default control word. */ #define __Linux_NPXCW__ 0x037f /* SVR4 uses the same control word as iBCS2. */ #define __SVR4_NPXCW__ 0x0262 So their float.h values are correct only for Linux binaries and emulation. Also, it looks like FreeBSD_NPXCW is incorrect, since we have: #define __INITIAL_NPXCW__ 0x127F And there's a comment: * 64-bit precision often gives bad results with high level languages * because it makes the results of calculations depend on whether * intermediate values are stored in memory or in FPU registers. which seems like a compiler issue, not an OS issue to me. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message