Xref: utzoo comp.arch:6950 alt.next:258
Path: utzoo!mnetor!cxsea!ssc-vax!uw-beaver!cornell!mailrus!rutgers!apple!baum
From: baum@Apple.COM (Allen J. Baum)
Newsgroups: comp.arch,alt.next
Subject: Re: RISC v. CISC --more misconceptions
Message-ID: <19762@apple.Apple.COM>
Date: 31 Oct 88 22:00:16 GMT
References: <156@gloom.UUCP> <18931@apple.Apple.COM> <40@sopwith.UUCP>
Reply-To: baum@apple.UUCP (Allen Baum)
Organization: Apple Computer, Inc.
Lines: 29

[]
>In article <40@sopwith.UUCP> snoopy@sopwith.UUCP (Snoopy T. Beagle) writes:
>In article <18931@apple.Apple.COM> baum@apple.UUCP (Allen Baum) writes:
>| You may find, howver, that it won't make any difference in your
>| performance because no one needs an integer multiplier very
>| often. Like a lot of things that RISC designers have left out.
>
>I humbly disagree.  Just because *you* never use an integer multiply
>does not imply that noone else ever does.

Oh, please!
I didn't say noone.
I didn't say ever.
Of course there are applications that are integer multiplication
intensive (as opposed to floating point).
What I did say is that they are quite rare.

Integer floating point intensive is defined (here and now, by me) to
be an application that will suffer a performance degradation of more
than 3% without a fast hardware multiplier (2-3 cycles, vs. the
average 11 cycles that HP can do in pure software. (A back of the
envelope calculation will show that means .3%- pretty high for
multiply) Most integer multiplies that I am aware of are used for
index scaling and other address calculations. Good optimizing
compilers will strength reduce these away

--
		  baum@apple.com		(408)974-3385
{decwrl,hplabs}!amdahl!apple!baum