Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site alice.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!alice!ark
From: ark@alice.UucP (Andrew Koenig)
Newsgroups: net.unix-wizards
Subject: Re: floating point overflows (and how t
Message-ID: <4312@alice.UUCP>
Date: Thu, 12-Sep-85 19:13:35 EDT
Article-I.D.: alice.4312
Posted: Thu Sep 12 19:13:35 1985
Date-Received: Fri, 13-Sep-85 05:01:21 EDT
References: <2000026@ccvaxa>
Organization: Bell Labs, Murray Hill
Lines: 24

>> If I compile and run the following program, it will continue until
>> a floating point overflow occurs and will then go and proccess
>> the interrupt routine. However, it seems that the return from the
>> interrupt routine is returning to the start of the instruction
>> which caused the overflow in the first place. Therefore, the program
>> just goes into an infinite loop printing the overflow message.
>>	  Scott Pace, ...!philabs!micomvax!othervax!scott

> You are not doing anything wrong, DEC is!  I am sure they would claim
> this to be a feature (it is documented in the architecture handbook),
> but it sure looks like a bug to me.
>	{ucivax,trwrb}!lcc!richard

The architectural question is: when a floating point overflow
occurs, should the return address from the interrupt routine
be the failing instruction or the one that follows it.
DEC apparently feels it should be the failing instruction.
One good justification for that is that it is only moderately
difficult to write a routine that will find the instruction
following the failing one and modify the PC accordingly (knowing
that the failing instruction had to be a floating-point operation,
I wrote such a routine in about an hour).  If you only have a
pointer to the next instruction, it is impossible to determine
the address of the one that failed with certainty.