Date: Wed, 30 Oct 2002 22:33:22 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: "M. Warner Losh" <imp@bsdimp.com> 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 Message-ID: <20021030215500.E5692-100000@gamplex.bde.org> In-Reply-To: <20021030.012222.123041962.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 30 Oct 2002, M. Warner Losh wrote: > In message: <20021029222447.L1273-100000@gamplex.bde.org> > Bruce Evans <bde@zeta.org.au> writes: > : On Mon, 28 Oct 2002, M. Warner Losh wrote: > : > : > In message: <200210290211.g9T2BBcP010112@latour.rsch.comm.mot.com> > : > Loren James Rittle <rittle@latour.rsch.comm.mot.com> writes: > : > : > This works. I'm not sure why this isn't the default. It looks like > : > we have hacks in the local tree to do this, which is why I thought > : > that it worked great by default.... > : > : Better change FreeBSD to match the unhacked version :-). > > Better to change FreeBSD to do the right thing and give long doubles > their full precision, unless there's some compelling reason not to do > so. 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. > : > : 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. <float.h> > : > : 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. > What is the issue? If the > issue is that doubles then start to be computed at 64 bit precision of > intermediate value, then isn't it a compiler issue of scheduling the > precision of the floating point unit? It then would be the only > entity to know what the proper precision is at any given time. Of > course, that sounds like a hard problem to me, especially since the > compiler might not know the state of the fp unit on entry to a given > function call. 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. 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. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021030215500.E5692-100000>