Path: utzoo!mnetor!uunet!husc6!mit-eddie!uw-beaver!cornell!rochester!ur-tut!sunybcs!boulder!hao!ames!eos!aurora!labrea!decwrl!hplabs!pyramid!prls!mips!hansen
From: hansen@mips.COM (Craig Hansen)
Newsgroups: comp.arch
Subject: Re: Shift and Subtract is NOT Multiply
Message-ID: <1745@mips.mips.COM>
Date: 2 Mar 88 16:35:36 GMT
References: <7649@pur-ee.UUCP> <7276@sol.ARPA>
Lines: 27
Summary: true, but irrelevant

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.
> For example, a*7 implemented as (a<<3)-a may overflow where (a<<2)+(a<<1)+a
> will not.  If we detect an overflow with (a<<3)-a, then we cannot immediately
> tell whether or not a*7 would overflow.

This is true, but completely irrelevant to the issue of performing
multiplications for index calculations. Such multiplications do
not require overflow checks, as the index itself can be tested
for the proper subrange more easily than the address of the array element.
The MIPS compiler will generate shift and subtract sequences for
multiplications without overflow check, but restricts the generated
sequences to adds for multiplications with overflow checking.
The HP Precision architecture does this in fewer cycles by checking
for overflow on the shift and the add in the shift-and-add instructions
(checking for overflow on shift instructions is a nice idea).

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