Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: Notesfiles $Revision: 1.7.0.8 $; site ccvaxa
Path: utzoo!watmath!clyde!cbosgd!ihnp4!inuxc!pur-ee!uiucdcs!ccvaxa!preece
From: preece@ccvaxa.UUCP
Newsgroups: net.unix-wizards
Subject: Re: floating point overflows (and how t
Message-ID: <2000026@ccvaxa>
Date: Tue, 10-Sep-85 11:28:00 EDT
Article-I.D.: ccvaxa.2000026
Posted: Tue Sep 10 11:28:00 1985
Date-Received: Thu, 12-Sep-85 10:56:38 EDT
References: <1240@brl-tgr.ARPA>
Lines: 23
Nf-ID: #R:brl-tgr.ARPA:-124000:ccvaxa:2000026:000:1005
Nf-From: ccvaxa.UUCP!preece    Sep 10 10:28:00 1985


> > 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 idea is probably that your interrupt routine should fix the
condition that caused the error before returning.  There are
situations where this is a perfectly reasonable way to do things,
allowing rational responses to predictable exceptions.  

-- 
scott preece
gould/csd - urbana
ihnp4!uiucdcs!ccvaxa!preece