Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!hsdndev!bbn.com!drilex!dricejb
From: dricejb@drilex.UUCP (Craig Jackson drilex1)
Newsgroups: comp.arch
Subject: Re: IEEE arithmetic (Goldberg paper)
Message-ID: <28197@drilex.UUCP>
Date: 4 Jun 91 16:18:24 GMT
References: <9106010224.AA28532@ucbvax.Berkeley.EDU>
Organization: DRI/McGraw-Hill, Lexington, MA
Lines: 74

In article <9106010224.AA28532@ucbvax.Berkeley.EDU> jbs@WATSON.IBM.COM writes:
>
>          Henry Spencer says:
>My understanding is that the funnier-looking features, in particular the
>infinities, NaNs, and signed zeros, mostly cost essentially nothing.
>
>          I believe this statement is incorrect.  Infs and nans compli-
>cate the design of the floating point unit.  Even if there is ultimately
>no performance impact, this added design effort represents a very real
>cost.  Perhaps some hardware designers could comment.
>          Also as has already been pointed out there is a software cost
>due to such features as 0*x no longer being 0.  In some cases this will
>have a performance impact in that compilers will generate inferior code.

There is a significant software cost to not having NaNs--simulating them.
The reality is that data are often missing, and systems need to deal with
that fact.  One can either store the information as to whether a given
'double' is a valid floating point number as part of its bit representation,
or one can store it elsewhere.  (Perhaps as a bitmap attached to each
array in the application system.)

Many older systems used some valid floating point number, such as '-999',
as their missing-data specifier.  Such a convention is highly portable, but
runs the risk of valid data being interpreted as missing data.  When NaNs
are available, it becomes possible to use them to signify missing data.
Generally, normal NaN-producing operations will only produce a few of
the possible NaN bit patterns, and the remaining ones can be used to
code application-specific information about missing data.

On other systems there may be a bit that does not participate in arithmetic.
There is such a bit in the Burroughs Large Systems architecture, a relic
of the B5500 representation.  This has successfully allowed us to
represent missing data in the absence of NaNs.  When the same system
was ported to the IBM 370 architecture, I used non-zero unnormalized
floating point numbers to represent these values, but with much less
confidence.

>          I guess I was a bit obscure here.  On IBM hex systems when
>floating overflow occurs the default behavior is for an error message
>to be printed which includes a traceback pointing to the offending
>instruction.  Execution then continues (with the max floating number as
>a fixup) but will terminate if more than a small number (5?) of over-
>flows occur.  I was under the impression that this was typical behavior
>for pre-IEEE systems.  Is that not the case?

As others have pointed out,
this was the behavior of a particular run-time system on IBM 370s.  By
default, the hardware simply trapped on overflows.  This behavior assumes
that the user cares about the overflows.  If the overflows were insignificant,
then extra (possibly non-portable) coding had to be done to avoid the
messages.

>          I consider this behavior much friendlier than typical IEEE
>behavior which is to run to completion then output infs and nans (or
>worse plausible but wrong numbers) with no indication of where the
>error occurred.

If running to completion, ignoring all creation of Infs and NaNs, was
the IEEE default, then I would agree with you.  I worked on a CDC 6400,
where this was the behavior, and sometimes I really wished I could get
a trap at the time of a divide-by-zero.

However, I believe that the standard specifies that by default all traps
are enabled.

>                       James B. Shearer

Also, we have software that does not care where in a calculation that
an overflow or divide-by-zero occurred, just whether it occurred.  Being
able to turn off trapping greatly simplifies the coding of this application.
-- 
Craig Jackson
dricejb@drilex.dri.mgh.com
{bbn,axiom,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb}