Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!wuarchive!brutus.cs.uiuc.edu!apple!mips!mash
From: mash@mips.COM (John Mashey)
Newsgroups: comp.arch
Subject: Re: RISC vs CISC (rational discussion..) + new IBM 'beyond RISC'
Message-ID: <31149@winchester.mips.COM>
Date: 10 Nov 89 03:16:59 GMT
References: <503@ctycal.UUCP> <31031@winchester.mips.COM> <36340@apple.Apple.COM>
Reply-To: mash@mips.COM (John Mashey)
Organization: MIPS Computer Systems, Inc.
Lines: 62

In article <36340@apple.Apple.COM> baum@apple.UUCP (Allen Baum) writes:
>>In article <31031@winchester.mips.COM> mash@mips.COM (John Mashey) writes:
>>ARGUMENT 1: RISC is better because it's smaller, for new technologies
>>When die size is a limit, RISC is better, because you can do it,
>   Agreed. However, current trends appear to indicate that new technologies
>   mature reasonably quickly. This argument works for just a few (<10?) years.
Agreed, although 10 years is almost an eternity, epsecially given the
structure and trends in the computer business, i.e., it's getting harder and
harder to introduce new architectures successfully....

>>ARGUMENT 2: RISC is better for cost reasons, because it's smaller
>   When you get to 1M transistors on a chip, the space for some extra decoding
>   logic is neglible. This argument works only during the initial (e.g.
>   'new technology' phase.
Sorry, I should have been more specific: I was assuming architectures
upward-compatible with any of the current prevalent CISCS, i.e., that
would typically use large microcode ROMS for some instructions, even
if the most frequent ones were hardwired as in 486s, etc.

>>ARGUMENT 3: RISC is better, because even if there is enough space on a die
>>	to put a whole CPU plus other things, the RISC can afford more space
>>	for caches and other good things, and so it will be faster.
>    See argument above. What is the performance difference between a 32k cache
>    and a 31k cache?
Of course, if there is that little difference, it doesn't make very
much difference, EXCEPT if to fit the size of chip you can actualy make,
it makes the difference between 16K and 32K, which can happen quite easily.

>>ARGUMENT 4: RISC is better, because it's simpler, and hence there is faster
>>	time to design and test the chips.
>>	COMMENT: maybe, maybe not.
>   Agreed. Notice as we get more and more transistors, we start to do more
>   complex (superscalar, hi-perf FP, graphics) things, not just add more
>   cache.  Superscalar may double your performance. It would literally
>   impossible to add enough cache to do that, so simple, regular hardware is
>   probably not where the transistors will go. (for disbelievers, if your
>   cache miss penalty * miss ratio <1, then even if every access hits, you'll
>   save less than a cycle, so CPI approaches 1. Superscalar does better.)
>
>>ARGUMENT 4: But when you can get zillions** of transistors  on a die, it
>>	it doesn't matter.
>>	... More transistors will help everything, however, it may be
>>		that the "limiting factor" will be not die space,
>>		but COMPLEXITY in critical paths and exception-handling.
>>
>>This last point is illustrated by the recent i486 bugs, and also, by the
>>errata list carried for a long time by the i386
>
>Ah, yes. I think its safe to say that our simple RISCs are going to start to
>get fairly complex, as we start to play all the little hardware tricks we've
>known from the supercomputer world, and some that we'll invent. Note that a
>lot of errors come from exception handling kinds of problems, and while CISC
>machines have them, superscalar, out-of-order execution RISC machines will
>have them in spades.
Yes, but superscalar, out-of-order CISCs would have them in spades & hearts :-)

The new IBM stuff looks interesting....
-- 
-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: 	{ames,decwrl,prls,pyramid}!mips!mash  OR  mash@mips.com
DDD:  	408-991-0253 or 408-720-1700, x253
USPS: 	MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086