Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!mailrus!tut.cis.ohio-state.edu!husc6!sri-unix!quintus!ok
From: ok@quintus.UUCP (Richard A. O'Keefe)
Newsgroups: comp.arch
Subject: Sticky overflow (was Shift and Subtract is NOT Multiply)
Message-ID: <718@cresswell.quintus.UUCP>
Date: 2 Mar 88 06:18:05 GMT
References: <7649@pur-ee.UUCP> <7276@sol.ARPA>
Organization: Quintus Computer Systems, Mountain View, CA
Lines: 23
Summary: new topic

In article <7276@sol.ARPA>, crowl@cs.rochester.edu (Lawrence Crowl) writes:
> In article <7649@pur-ee.UUCP> hankd@pur-ee.UUCP (Hank Dietz) writes:
> >For example, a multiply by 7 (not a nice power of 2) is really shift to
> >multiply by 8 and then subtract the original number.
> 
> If you use this method for multiplication by 7, and you do not provide for
> a double width result, using subtraction will lose the overflow information.

One big difference between IEEE floating-point arithmetic and older approaches
is that it lets you delay overflow checks to the end of a calculation, instead
of requiring the hardware to trap (which should permit a simpler pipeline,
shouldn't it?) or forcing an overflow check after each FP instruction.  This	
works because overflow is sticky: any calculation involving a NaN or Infinity
yields a NaN or Infinity.  (BTW: does anyone know if the MC 68881 has a
trap-now-if-NaN-or-Infinity instruction?)

How about something like this for integer arithmetic?  Suppose there were
two flavours of load/move instruction (one to clear the overflow bit, one
to leave it alone), and that integer arithmetic instructions were to set
the overflow bit, but not clear it.  Then this argument against shift-and-
subtract would go away.

Are there any machines which use this approach?
What are its disadvantages?