From owner-freebsd-current Thu Oct 31 0:48:21 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 EB44537B401 for ; Thu, 31 Oct 2002 00:48:17 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D50343E6E for ; Thu, 31 Oct 2002 00:48:16 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id TAA18100; Thu, 31 Oct 2002 19:48:01 +1100 Date: Thu, 31 Oct 2002 19:59:21 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: "M. Warner Losh" Cc: rittle@labs.mot.com, , , Subject: Re: Lack of real long double support In-Reply-To: <20021030.162239.52163953.imp@bsdimp.com> Message-ID: <20021031192610.W8632-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 On Wed, 30 Oct 2002, M. Warner Losh wrote: > 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. Er, it does the same very imperfect job that it did in when it first implemented long doubles. > : 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? Yes. It doesn't attempt to implement C99 stuff and depends on a fuzzy reading of C90 to conform to C90. Example of gcc-3.2's schizophrenia with precision: %%% $ cat z.c double x = 1.0F / 3.0F; float y = 1.0F; float z = 3.0F; double u; int main() { u = y / z; printf("x = %.17g\n", x); printf("u = %.17g\n", u); return (x == u ? 0 : 1); } $ cc -o z z.c $ ./z x = 0.3333333432674408 u = 0.33333333333333331 %%% Evaluation at compile time is different that at runtime because gcc thinks that float operations are performed in float precision and performs them at that precision at compile time. But float operations at runtime are actually performed in the ambient precision due to white lies like the following in i386.md: %%% (define_expand "divsf3" [(set (match_operand:SF 0 "register_operand" "") (div:SF (match_operand:SF 1 "register_operand" "") (match_operand:SF 2 "nonimmediate_operand" "")))] "TARGET_80387 || TARGET_SSE_MATH" "") %%% (This says that the result of dividing a single-precision float by a single precision float is a single-precision float, but the result is actually an ambient-precision float.) The above example is for float precision. The FreeBSD default basically insulates users from surprises due to precision when everything is a long double. > BTW, NetBSD is kinda schizophrenic about this: It just supports a lot of cases. > /* > * 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 This is the FreeBSD[1-3] default. > /* iBCS2 goes a bit further and leaves the underflow exception unmasked. */ > #define __iBCS2_NPXCW__ 0x0262 FreeBSD and NetBSD are both derived from 386BSD which had this. I added the 0x1000 bit in case 386BSD ever got run with a 287. > /* 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 Linux binaries are just differently incorrect :-). > 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. Indeed it is mostly a language issue, so this is not a very good place to decide the setting. You would not be wrong to set it in crt0 if you removed it in the kernel (just set the hardware default in the kernel). But the library can still override any unwanted defaults. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message