Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!vsi1!altnet!uunet!portal!cup.portal.com!
From: bcase@cup.portal.com (Brian bcase Case)
Newsgroups: comp.arch
Subject: Re: RISC v. CISC (was The NeXT problem
Message-ID: <10193@cup.portal.com>
Date: 19 Oct 88 19:15:34 GMT
References: <156@gloom.UUCP>
Organization: The Portal System (TM)
Lines: 46

>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.

True for the simple instructions in the CISC instruction set.  Not so
true for the ones with complex addressing modes, etc.  Fixed instruction
size, format, and prevention of page-boundary crossings are very good
things to do.  This limits the CISCy ness of an instruction set, or the
instructions will need to be very long, or they will need to be two-address
instead of three address, or worse, one-address, or....

>Second, to perform a complex task, a RISC chip will need more
>instructions than a CISC chip.

This is simply an exageration.  Yeah, maybe 1.2 to 1.5 times as many,
but this is usually not a big deal.  If it is (it might be for some),
then CISC away.

>Third, given the same level of technology for each (ie caches, pipelines,
>etc), a microcode fetch is faster than a memory fetch.

But not much faster than a cache fetch.  And the cache will have the
"macros" that the program actually uses, not the ones that the instruction
set designers assumed the application would use.  The problem is that it
is presumptuous to think that you know exactly how the procedure linkage,
run-time addressing model, etc. is going to be implemented by the language
and operating system designers.  Once its in uCode, it's there for a long
time.  And if the microcode routines are longer than one instruction, you
no longer have single cycle instructions.  But this is a complex issue.

>As an aside, the 68030 can do a 32 bit multiply in about (I don't have
>the book in front of me) 40 cycles. 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)).  

First of all, the 6502 is simple, but it is very far from a RISC.  Maybe
you mistyped.  Second, if multiply is important, which it typically isn't
in systems code, implement it combinatorially, in parallel.  Third, you
probably failed to check for the reduced cases in your macro; by checking
for small operands, etc. you can get the cycle count down.  And multiplies
by small constants (the most frequent case in system codes) can be done in
very few cycles using shifts, adds, and subtracts.

Disclaimer:  Everone is entitled to an opinion.