Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!bbn!bbn.com!slackey
From: slackey@bbn.com (Stan Lackey)
Newsgroups: comp.arch
Subject: More RISC vs. CISC wars
Message-ID: <42550@bbn.COM>
Date: 11 Jul 89 16:44:17 GMT
References: <2190@oakhill.UUCP> <13980@lanl.gov>
Sender: news@bbn.COM
Reply-To: slackey@BBN.COM (Stan Lackey)
Organization: Bolt Beranek and Newman Inc., Cambridge MA
Lines: 31

In article <13980@lanl.gov> jlg@lanl.gov (Jim Giles) writes:

>But, RISC machines are easier to pipeline

I don't see how this can be true, other than possibly in the scoreboarding
logic.  If it has it.  

>easier to speed up the clock for

Unless your cycle time is limited by memory chips (for the cache), in
which case it doesn't matter.

>easier to provide staged functional units for, etc..  

I don't get this one

>I don't
>know of any CISC machines with 'hardwired' instruction sets.  Micro-
>coding slows the machine down.

This is an interesting statement.  As I recall hearing, Cray started 
this perception back in the 70's.  I thought it had been proven wrong.
For example, the Alliant executes the instruction:

	add.d  (an)+, fp0

in one cycle (yes, that's double precision memory-to-register add,
auto increment), and it's microcoded.  Are you saying that it would be
done in zero cycles if we got rid of the microcode?  Gee, and after
spending so much real estate on those microcode RAM's...
:-) Stan's opinions only.