Path: utzoo!attcan!uunet!clyde.concordia.ca!mcgill-vision!bloom-beacon!snorkelwacker!apple!baum
From: baum@Apple.COM (Allen J. Baum)
Newsgroups: comp.arch
Subject: Re: CISC Silent Spring
Message-ID: <38462@apple.Apple.COM>
Date: 8 Feb 90 20:54:55 GMT
References: <3300098@m.cs.uiuc.edu> <771@sce.carleton.ca> <35456@mips.mips.COM> <25cb6b65.702c@polyslo.CalPoly.EDU> <7826@pt.cs.cmu.edu> <3562@odin.SGI.COM> <35647@mips.mips.COM>
Reply-To: baum@apple.UUCP (Allen Baum)
Organization: Apple Computer, Inc.
Lines: 30

[]
>In article <35647@mips.mips.COM> mash@mips.COM (John Mashey) writes:
>Gate/transistor count can be misleading.
>On anything current, most of the transistors will be in the caches & MMU
>and register files.

Actually, I thought that I'd heard that 3/4 of the area on the 88100 is
the FPU (course, that doesn't include caches)

>Some of the issues are:
>2) AS everybody gets more aggressive, the pipelines and other critical paths
>get more complex, as more aggressive = more things in parallel.
>CISCs may well take longer to design (or not), but the key issue is what
>happens in the critical paths on the chip.  From past history (i.e., things
>like 360/91), you can make any architecture go faster, but if not designed
>for smooth pipelining, the complexity can get very high.

Bingo! I believe you've said something I believe strongly, and the
crux is the "designed for smooth piplelining" phrase. I feel that this
is really the major distinguishing feature between "RISC" & "CISC".
This is far more important than the silly RISC/CISC
#of-regs/addressing modes arguments. A "CISC" which is designed for
pipelining should keep up with a "RISC". The tricks used to make
"RISC"s go faster then work for "CISC"s as well.
Most of the otherwise fundamental problems of "CISC"s (exception handling)
go away (to the same extent they go away in "RISC"s anyway)

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