Date: Wed, 30 Oct 2002 16:22:39 -0700 (MST) From: "M. Warner Losh" <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 Message-ID: <20021030.162239.52163953.imp@bsdimp.com> In-Reply-To: <20021030215500.E5692-100000@gamplex.bde.org> References: <20021030.012222.123041962.imp@bsdimp.com> <20021030215500.E5692-100000@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20021030215500.E5692-100000@gamplex.bde.org>
Bruce Evans <bde@zeta.org.au> 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. <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.
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021030.162239.52163953.imp>