Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 12 Dec 1997 03:59:07 +1100
From:      Bruce Evans <bde@zeta.org.au>
To:        bde@zeta.org.au, rcarter@consys.com
Cc:        freebsd-current@FreeBSD.ORG
Subject:   Re: xlock: caught signal 8 while running galaxy mode.
Message-ID:  <199712111659.DAA16579@godzilla.zeta.org.au>

next in thread | raw e-mail | index | archive | help
Long ago (2 months :-), Russell wrote:
>}>to control the internal precision of arithmetic operations,
>}>silly me.  A lot of the debate on "Pure" java fp focuses on
>}>the (unmodifiable) 80 bit internal representation of x87 operands
>}>stored on the fp stack, but this flag apparently renders that 
>}>problem moot.  Oddly, Sun has been
>}>insisting that the only way to make x87 fp "Pure" is to store
>}>the result of EVERY fp operation to main memory and read it
>}>back in again.  That way of course every arithmetic operation
>}>gets performed with 53b precision operands.
>}>Surely they know about this flag... no no I won't be cynical ;-)
>}

The C9x draft specifies pure behaviour.  Values must be independent
of whether they are represented in a (wide) register or in memory or
calculated at compile time.  In particular, implicit spills must not
change the value.  Explicit stores and loads must round to the precision
of the storage type.  In particular, casts and assignments must perform
their specified conversion.

I wrote:
>}Neither way is completely pure - there are some problems with
>}double rounding that could not possibly be fixed by running with
>}64-bit precision and reducing to 53-bit precision by storing.
>}I believe they aren't fixed by running with 53-bit precision
>}either, at least for division - the FPU apparently first rounds
>}to 64 bits.  For transcendental functions, storing is the only
>}way.

A good referennce for the double rounding problem:

  David Goldberg
  Differences Among IEEE 754 Implementations
  http://www.validgh.com/goldberg/addendum.html
  1997-10-26

>[lots deleted]

>My original statement said there are "counterexamples"
>to the general rule that more accuracy is better for
>application codes.  After a lot of thought and rereading
>of papers in my archive I can think of only two,
>very tiny, classes of codes that 53 bit precision
>benefits more than 64bit precision (given identical
>compuation costs).  Those are test programs with bugs,
>like paranoia, and iterative algorithms that require
>a bit of noise to be coaxed to converge.  Are there
>more?  At any rate, "counterexamples" was much too 
>charitable.

These are probably the main examples.  Goldberg gives some
interesting ones.

Bruce



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199712111659.DAA16579>