Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!pasteur!ucbvax!hplabs!pyramid!prls!mips!hansen
From: hansen@mips.COM (Craig Hansen)
Newsgroups: comp.arch
Subject: Re: Sticky overflow (was Shift and Subtract is NOT Multiply)
Message-ID: <1755@mips.mips.COM>
Date: 2 Mar 88 23:43:16 GMT
References: <7649@pur-ee.UUCP> <7276@sol.ARPA> <718@cresswell.quintus.UUCP>
Lines: 39

In article <718@cresswell.quintus.UUCP>, ok@quintus.UUCP (Richard A. O'Keefe) writes:
> 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?

It doesn't work for the multiply-by-seven case, because the
multiply-by-eight might overflow (and set the overflow bit) even
though the final result is OK.

It's not that big a deal (doesn't justify having much extra stuff), as
you can do a multiply by 7 with full overflow check with 4 instructions:

	addo	r2 <- r1 + r1	; *2
	addo	r2 <- r2 + r1	; *3
	addo	r2 <- r2 + r2	; *6
	addo	r2 <- r2 + r1	; *7

...and in fact, shift-and-add is just two instructions:

	sh2addo	r2 <- r1 << 2 + r1  ; *5
	sh1addo	r2 <- r1 << 1 + r2  ; *7

If you want to get shift-and-subtract with overflow checking, you can
easily keep one extra bit of precision after the shift, so that you
properly check overflow after the subtract. With such a well-defined
primitive (that only overflows if the result of the operation, not the
intermediate result, overflows), you can safely use shift-and-subtract
instructions so long as the intermediate products you put in registers
aren't larger than the final result.

-- 
Craig Hansen
Manager, Architecture Development
MIPS Computer Systems, Inc.
...{ames,decwrl,prls}!mips!hansen or hansen@mips.com   408-991-0234