From owner-freebsd-current Wed Oct 30 0:23:52 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 6EF1E37B401 for ; Wed, 30 Oct 2002 00:23:51 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id C7EBD43E42 for ; Wed, 30 Oct 2002 00:23:50 -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 g9U8Nfpk043678; Wed, 30 Oct 2002 01:23:47 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 30 Oct 2002 01:22:22 -0700 (MST) Message-Id: <20021030.012222.123041962.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: <20021029222447.L1273-100000@gamplex.bde.org> References: <20021028.214057.108404482.imp@bsdimp.com> <20021029222447.L1273-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: <20021029222447.L1273-100000@gamplex.bde.org> Bruce Evans writes: : On Mon, 28 Oct 2002, M. Warner Losh wrote: : : > In message: <200210290211.g9T2BBcP010112@latour.rsch.comm.mot.com> : > Loren James Rittle 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. : : 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