baum@Apple.COM (Allen J. Baum) (10/18/88)
[] >In article <156@gloom.UUCP> cory@gloom.UUCP (Cory Kempf) writes: >A while back, I was really hot on the idea of RISC. Then a friend >pointed out a few things that set me straight... > >First, there is no good reason that all of the cache and pipeline >enhancements cannot be put on to a CISC processor. Some are trying to do it, but they can't do it as well as a RISC processor because they don't have room on the chip, because they're busy supporting instructions and addressing modes that hardly ever get used. >Second, to perform a complex task, a RISC chip will need more >instructions than a CISC chip. First of all, not necessarily true. Second of all, so what? The number of instructions used by RISCS has been greatly exaggerated. First generation RISCS may have a code expansion of 50% in bytes. However, this is a static measurement. It doesn't mean that the inner loops will use twice as many cycles. And, since the datapath of a RISC machine is simpler, its cycles are likely faster. >Third, given the same level of technology for each (ie caches, pipelines, >etc), a microcode fetch is faster than a memory fetch. Perhaps, but the microcode is only good for one thing: interpreting macro- code. A the code in a cache is good for whatever I happen to be executing at the time. >As an aside, the 68030 can do a 32 bit multiply in about (If I remember >correctly -- I don't have the book in front of me) 40 cycles. A while >back, I tried to write a 32 bit multiply macro that would take less >than the 40 or so that the '030 took. I didn't even come close (even >assuming lots of registers and a 32 bit word size (which the 6502 >doesn't have)). Check out the ASPLOS II proceedings. There is an article the by Dan Magenheimer of HP explaining how the do 11 cycle average multiplies, without a multiplier, and without a multiply step instruction. Besides, if you have a RISC machine, and multiply is truly important, the you have room for multiply support, up to having a full multiplier. 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. -- {decwrl,hplabs}!nsc!baum@apple.com (408)973-3385
snoopy@sopwith.UUCP (Snoopy T. Beagle) (10/31/88)
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. _____ /_____\ Snoopy /_______\ |___| tektronix!tekecs!sopwith!snoopy |___| sun!nosun!illian!sopwith!snoopy
david@ms.uky.edu (David Herron -- One of the vertebrae) (10/31/88)
Yea really ... and compilers use integer multiplies all the
time when referencing into arrays...
I for one would like to see floating point tossed out, since I
never use it (and I happen to dislike my numerical analysis class :-)
--
<-- David Herron; an MMDF guy <david@ms.uky.edu>
<-- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<--
<-- Controlled anarchy -- the essence of the net.baum@Apple.COM (Allen J. Baum) (11/01/88)
[] >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
kyriazis@rpics (George Kyriazis) (11/01/88)
In article <10471@s.ms.uky.edu> you write: >Yea really ... and compilers use integer multiplies all the >time when referencing into arrays... > >I for one would like to see floating point tossed out, since I >never use it (and I happen to dislike my numerical analysis class :-) >-- Floating point is getting faster and faster every day. One example that I know of is the AT&T DSP32 Digital Signal Processor. It needs 1 CPU cycle to do a floating point multiplication and accumulation. An interesting side-effect is in the calculation of array referencing. It expands the array index to FP, does the array indexing, and then truncates the resulting address to an integer. (The compiler I am talking about is the one that is the one that AT&T gives for their Pixel Machine). -- George Kyriazis kyriazis@turing.cs.rpi.edu ------------------------------ George Kyriazis kyriazis@turing.cs.rpi.edu ------------------------------
guy@auspex.UUCP (Guy Harris) (11/02/88)
>Yea really ... and compilers use integer multiplies all the >time when referencing into arrays... Integer multiplies by *constants*, most of the time; you can often do those better with shifts and adds than you can with the machine's multiply instruction (and no, I'm not talking about the 68010, which doesn't have a 32x32 multiply instruction).