Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!cam-cl!news
From: cet1@cl.cam.ac.uk (C.E. Thompson)
Newsgroups: comp.arch
Subject: Re: IEEE arithmetic (Goldberg paper)
Message-ID: <1991Jun2.221948.15889@cl.cam.ac.uk>
Date: 2 Jun 91 22:19:48 GMT
References: <9106010224.AA28532@ucbvax.Berkeley.EDU>
Reply-To: cet1@cl.cam.ac.uk (C.E. Thompson)
Organization: U of Cambridge Comp Lab, UK
Lines: 22

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?

Not particularly typical, as other postings have pointed out.

More to the point, what you are describing is the actions of a piece of
user-mode software: the IBM Fortran runtime system. There is nothing in
the IBM/3x0 architecture that specifies these fixup/termination actions;
it just generates a program interrupt. Indeed, doing the fixup involves
grubbing around in the failing instruction to find which floating point
register to modify.

Chris Thompson
JANET:    cet1@uk.ac.cam.phx
Internet: cet1%phx.cam.ac.uk@nsfnet-relay.ac.uk