cvs commit: src/sys/i386/include _types.h

[David Schultz]

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.