Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!hao!gatech!bbn!rochester!crowl
From: crowl@cs.rochester.edu (Lawrence Crowl)
Newsgroups: comp.arch
Subject: Re: Sticky overflow (was Shift and Subtract is NOT Multiply)
Message-ID: <7310@sol.ARPA>
Date: 2 Mar 88 16:48:05 GMT
References: <7649@pur-ee.UUCP> <7276@sol.ARPA> <718@cresswell.quintus.UUCP>
Reply-To: crowl@cs.rochester.edu (Lawrence Crowl)
Organization: U of Rochester, CS Dept, Rochester, NY
Lines: 26

In article <718@cresswell.quintus.UUCP> ok@quintus.UUCP
(Richard A. O'Keefe) writes:
)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.
)> ... [crucial text deleted] ...
)
)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.

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.  I see no immediate (i.e. cheap) way of determining if
an overflow is real or spurious.  This implies that in order to only generate
real overflows, compilers must limit themselves to the shift-and-add method.
-- 
  Lawrence Crowl		716-275-9499	University of Rochester
		      crowl@cs.rochester.edu	Computer Science Department
...!{allegra,decvax,rutgers}!rochester!crowl	Rochester, New York,  14627