Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 30 Oct 2002 01:22:22 -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.012222.123041962.imp@bsdimp.com>
In-Reply-To: <20021029222447.L1273-100000@gamplex.bde.org>
References:  <20021028.214057.108404482.imp@bsdimp.com> <20021029222447.L1273-100000@gamplex.bde.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

: > : 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.  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.

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.012222.123041962.imp>