🚀 go-pugleaf

In article <43004@bbn.COM> slackey@BBN.COM (Stan Lackey) writes:

>Sure.  As I understand it, the major basis of RISC is:
>
>Simplify the hardware.  Include only those features that:
>  Provably improve performance;
>    Their presence speeds up certain operation(s)
>    Their presence does not slow down other operation(s)
>  Are straightforward to implement;
>  Are usable by straightforward compiler design;
>  Anything else emulate in software.

Getting the _right_ answer should be on the list.

>
>IEEE floating point goes contrary to each of those issues.
>
>1. Gradual underflow is not straightforward to implement. 
>
>Gradual underflow does not improve performance.  It [inaccurately]
>extends the low end of the range a little.  It adds significantly to
>design and verification time.  The only case I ever heard of it
>mattering is a drummed-up case Kahan wrote.

GU is one of the MOST useful parts of the standard. It, in fact,
allows many algorithms to run in 32-bits that would have required
64-bits (or more) with, say, IBMath. Kahan is one of the most skillful
folk at finding SIMPLE examples ... real codes are much too hard to
fully analyze ... and that is exactly why GU _should_ be employed for
all 32-bit machines. 

While purists will deep fry me in oil (or should), I can see the
great utility of a 64-bit non-compliant mode ... there are many codes
which are run in 64-bits for hysterical reasons (broke on a 360
therefore it must always be DP ...) which get along just fine with
abrupt underflow. AU is sometimes desired in the 32-bit realm, but
there one really should analyze the whole program (or run just
selected parts in AU). This can be accomplished on SunOS 4.x with a
runtime call.
>
>In the case of an i860 software supplier, if he wants stuff like
>transcendentals to run fast, he must tune them so that they don't
>cause underflow traps.  Rather that just use 0 which is what he wants
>anyway.

Depends on the algorithm. If 0 is what they want, one can toggle back
and forth.

>
>2. Rounding modes.  No compiler on Earth uses them, other than to get
>around instruction set deficiencies (rounding when converting from
>FP to integer).  This particular problem is more efficiently solved by
>adding a second version of the convert-to-integer instruction.

The folks who do interval arithmetic would strongly disagree here. For
better or worse, most of those folks seem to live in Europe. I have
seen versions of Pascal and Fortran extended to use 'em.
>
>--
>My belief is that if IEEE FP had been done a few years after it
>actually was, after RISC became the trend, it would have come out much
>different.  In fact, I think the suppliers should get an official

Getting the right answer is important. When dealing with FP problems
one has at LEAST the following issues to sweat:

1)	is the algorithm stable ?
2)	is it robust ?               

Requires a very hard backwards analysis to prove.

3)	is the implementation stable
4)	robust ?

This requires massive testing

5)	is the problem ill conditioned ?

The symptoms are EXACTLY those of 1-4 being broken. 

6)	is my computer arithmetic doing something funny

The symptoms are EXACTLY those of 1-5 being broken.

Using ieee math removes 6 from those things which one must sweat
bullets over when your 100+K line application is acting wonky. The
cost to implementors is non-trivial, but the savings to application
specialists is huge ... and they need not even understand that this is
happening in their behalf ... they just get fewer strange edge conditions.

>subset recognized by the IEEE that just uses 0 for underflowed
>operands/results, and just implements round-to-nearest.  I would be
>very surprised if it ever came up in a sales situation anyway; in fact
>all I care about is how fast it runs SPICE.

You should also care that the circuit is analyzed correctly. The sad
fact is that this is exceedingly hard to benchmark. That is why we
need the standard.

Kahan has a paper or two on Presubstitution a technique which allows
one to avoid a lot of the expensive precise exception stuff for a huge
number of applications.


Keith H. Bierman      |*My thoughts are my own. Only my work belongs to Sun*
It's Not My Fault     |	Marketing Technical Specialist    ! kbierman@sun.com
I Voted for Bill &    |   Languages and Performance Tools. 
Opus  (* strange as it may seem, I do more engineering now     *)