Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!rpi!bu.edu!encore!jcallen
From: jcallen@Encore.COM (Jerry Callen)
Newsgroups: comp.arch
Subject: Re: IEEE arithmetic (Goldberg paper)
Message-ID: <15059@encore.Encore.COM>
Date: 3 Jun 91 14:07:46 GMT
References: <9106010224.AA28532@ucbvax.Berkeley.EDU>
Reply-To: jcallen@encore.Com (Jerry Callen)
Organization: Encore Computer Corp, Marlboro, MA
Lines: 27

In article <9106010224.AA28532@ucbvax.Berkeley.EDU> jbs@WATSON.IBM.COM writes:
>          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?
>          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.

This may be obvious, but let's not confuse "compiler and runtime system 
behavior" with "floating point hardware behavior." Yes, Fortran on 360/370
systems behaves as you describe. In PL/1 it is possible to completely ignore
exponent overflow if you wish and get meaningless results.

Similarly, IEEE overflow behavior is under programmer control. If you WANT to 
ignore overflow and then just check to see if some error occurred at the
end of the calculation you may do so; if you want to know immediately, you can 
do that, too.

>                       James B. Shearer

-- Jerry Callen
   jcallen@encore.com