Path: utzoo!mnetor!uunet!steinmetz!davidsen
From: davidsen@steinmetz.steinmetz.UUCP (William E. Davidsen Jr)
Newsgroups: comp.arch
Subject: Re: Sticky overflow (was Shift and Subtract is NOT Multiply)
Message-ID: <9767@steinmetz.steinmetz.UUCP>
Date: 3 Mar 88 14:06:11 GMT
References: <7649@pur-ee.UUCP> <7276@sol.ARPA> <718@cresswell.quintus.UUCP> <7310@sol.ARPA>
Reply-To: davidsen@crdos1.UUCP (bill davidsen)
Organization: General Electric CRD, Schenectady, NY
Lines: 21

In article <7310@sol.ARPA> crowl@cs.rochester.edu (Lawrence Crowl) writes:
| You have missed the point.  There are two situations in shift-and-subtract
| where an overflow may occur.  In the first case, n*8-n causes an overflow at
| the shift, but n*7 does not cause an overflow.  In the second case, n*7 also
| causes an overflow.  This first case is a spurious overflow, and the second
| is a real overflow.

From my old GE-600 manual, ca 1960, "An overflow is detected when the
XOR of the sign bit and the most significant bit changes." Sounds pretty
good to me. Then you could make it sticky, if you wnated.

I suspect that the decision to interrupt or not on overflow is best
controlled as a condition in a flag register, and set by a smart
compiler (or programmer). In the case where a long series of operations
is taking place, the cost of doing an exception processing would be
lower than the cost of doing useless calculation. If the calculation was
short, some form of "test and branch" at the end would be faster.
-- 
	bill davidsen		(wedu@ge-crd.arpa)
  {uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me