Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!husc6!cmcl2!brl-adm!umd5!eneevax!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.arch
Subject: Re: Multiply as Shift-Add(Subtract)
Message-ID: <6651@mimsy.UUCP>
Date: Tue, 12-May-87 17:50:48 EDT
Article-I.D.: mimsy.6651
Posted: Tue May 12 17:50:48 1987
Date-Received: Sat, 16-May-87 02:03:37 EDT
References: <1270@aw.sei.cmu.edu> <8012@utzoo.UUCP> <16640@amdcad.AMD.COM> <27685@rochester.ARPA>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 22

In article <27685@rochester.ARPA> crowl@rochester.ARPA (Lawrence Crowl) writes:
>[When using additive power-of-two multipy] approaches an overflow at
>any step indicates an overflow for the entire multiply.  However, in
>the last approach [using subtraction], an overflow may occur at a step
>in the computation while the entire multiply itself does not overflow.
>... how do implementations using subtracts in the shift-add approach
>to multiplication detect overflow for an entire multiplication?

Since the multiply is by a constant, you can decide ahead of time
what range will *not* overflow, then generate two branches:

	// if x * [-58 .. 57] is ok:
	cmp	rX,#57
	bgt	overflow
	cmp	rX,#-58
	blt	overflow
	// go ahead, ignoring overflow

I suspect, however, that the usual answer is `they do not bother'.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
Domain:	chris@mimsy.umd.edu	Path:	seismo!mimsy!chris