Date: Thu, 6 Mar 2008 21:24:16 -0500 From: David Schultz <das@FreeBSD.ORG> To: Colin Percival <cperciva@FreeBSD.ORG> Cc: cvs-src@FreeBSD.ORG, src-committers@FreeBSD.ORG, Bruce Evans <bde@FreeBSD.ORG>, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/i386/include _types.h Message-ID: <20080307022416.GA53988@zim.MIT.EDU> In-Reply-To: <47D089A4.4060208@freebsd.org> References: <200803051121.m25BLE03035426@repoman.freebsd.org> <20080305182531.GS68971@server.vk2pj.dyndns.org> <20080306021222.GA46783@zim.MIT.EDU> <47CF5D19.3090100@freebsd.org> <20080306033246.GA47280@zim.MIT.EDU> <47CF7EBF.6000009@freebsd.org> <20080306063452.GB48339@zim.MIT.EDU> <47CF9586.70707@freebsd.org> <20080307085031.P10724@delplex.bde.org> <47D089A4.4060208@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Mar 06, 2008, Colin Percival wrote: > explicit or implicit final destination. When a variable with a declared format > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > is a final destination, as in format conversion to a variable, that declared > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > format of that variable governs its rounding. The format of an implicit > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > destination, or of an explicit destination without a declared format, is > defined by language standard expression evaluation rules. I think you missed the point about implicit destinations. See the part I quoted in the last email I sent you. The point is that in an expression like 'z = x * y', there are two operations: register <-- x * y z <-- register The register is an implicit destination. IEEE 754R explains this in more detail. All that is guaranteed in this case is that the wider register value is never substituted for z in subsequent operations. (This is part of what gcc gets wrong.) > > In C, with FLT_EVAL_METHOD = 2 (evaluate all FP expressions in the range > > and precision of the long double type) [...] > > As someone wrote earlier, the authors of C99 were a bit confused. I can only > assume that they intended to be IEEE754-compliant and the rules concerning > FLT_EVAL_METHOD apply to *implicit* destinations only. No, they got that part right. They got some of the stuff with function arguments and return values wrong in some pretty special and bizarre ways. Part of this is trying to cope with existing calling conventions, and part of it is just mistakes. > > We require error bounds of < 1 ulp and aim for < 0.5[0]1 ulps. > > What standard states that those bounds are required (or can be relied upon > when proving that code is correct)? Intel FPUs over the years have been > variously documented to compute transcendental functions to within 1.0, 2.5, > or 3.5 ulp -- are you saying that the 8087 doesn't comply with the standard > which it inspired? There's no standard requirements, but a max error < 0.50x ulps implies correct rounding nearly all of the time, and that's what libm attempts to provide. This is about the best you can do without resorting to multiprecision arithmetic in the hard cases, so it seems like a good tradeoff between accuracy and ease of implementation. When substantially faster and slightly less accurate MD implementations are available, that changes the tradeoff.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080307022416.GA53988>