🚀 go-pugleaf

In article <3562@odin.SGI.COM> pkr@maddog.sgi.com (Phil Ronzone) writes:
>In article <7826@pt.cs.cmu.edu> lindsay@MATHOM.GANDALF.CS.CMU.EDU (Donald Lindsay) writes:
>>RISC reduced the design time - an advantage that a fast CISC doesn't
>>have. It also reduced the silicon area, but as all the players add
>>onchip caches and whatnot, that matters little.  Finally, RISC
>>increased the clock rate, but advanced CISC should come close.
>>
>>So, is it a wash? More-or-less, yes - if RISC designs stand still.
>>But they aren't. RISC is moving to ECL and GaAs, where transistors
>>are scarce. They are also moving to superscalar designs, where the
>>RISC/CISC difference is between incredible complexity and stupefying
>>complexity.
>
>I see that as the ONLY large advantage that RISC has. It simply has
>been able to reduce the design time.
>
>The second argument (gate scarcity) is interesting, but does it not
>also have a limit? If gates are "typical" in the 10,000-100,000 range,
>yes, but how about when gates are "typical" in the 1,000,000-10,000,000.

Gate/transistor count can be misleading.
On anything current, most of the transistors will be in the caches & MMU
and register files.
Certainly, with million-transistor chips, there are not enough to do
everything you like, and even 3-4M, although it gets you bigger caches,
we'll still have compromises and arguments in the hallways.

Some of the issues are:
1) In CMOS, the smaller size is less of advantage for RISC than it used to be.
Nevertheless, at a given technology level, for a few years, it often means you
get a bigger cache, a more parallel FPU, a bigger MMU, or something else on the
same die, or, that the die can be smaller and hence cheaper, or that the RISC
gets an even more aggressive pipeline in the same space.
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.  In addition,
VLSI has design constraints that forbid some of the solutions used in the
less integrated designs, i.e., lots of big busses and interconnects.
(You certainly can have big busses, but you still only get a few layers
of them, and as soon as your design exceeds what you can get on the
chip, performance drops, whereas the performance cost of incremental
complexity in a less integrated design is not necessarily so much.)
3) Exception-handling is always one of the most trouble-prone areas of
a design, and anything that makes it more complex slows down the design
process.
4) Finally, nothing will make the current CISC micro architectures
have more registers available at once [they might get register sets,
but the instruction encoding makes it pretty hard to increase the number
available to the compiler at once.]

Note: this was not intended to be a RISC commercial, merely to point out that
the transistor-count issue gets over-emphasized.  I give a talk that ends with:

IF RISC IS SO GOOD, WILL CISC DISAPPEAR?
	No.
		68Ks and X86s will be with us forver.
WILL CISCS GET FASTER?
	Yes, using RISC-like techniques, or in fact, the same techniques that
	mainframe and supermini people have been using for 20 years to
	speed existing CISC architectures.
WILL THEY CATCH UP?
	No:
	Intellectual complexity.
	Longer design cycles.
	Less registers than match current global optimizers.
WHERE ARE THEY NOW?
	It is hard to tell, as I've seen no real benchmarks for an
	040 yet [they may exist, I haven't seen them], and I'm hoping to
	see SPEC ratios for 486 fairly soon, which will really help get over
	apples and oranges comparisons.o

I have been collecting some numbers in advance of that, although unfortuantely
limited to *stones & such, and will post some soon.  What I see so far says
that 25 MHz 486s, in 32-bit mode (I think), have floating point that
looks mostly like a MIPS M/500, and integer somewhat less than an M/800,
even with external caches as well as internal.
This is faster than an 8MHz R2000, and slower than a 12.5MHz one....
To be fair, they're somewhat faster under MS/DOS, and I'm not sure if that's
compiler differences, or (more likely) 16-vs-32 bit model differences.
-- 
-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