Path: utzoo!attcan!uunet!aplcen!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!mips!apple!bbn!bbn.com!slackey
From: slackey@bbn.com (Stan Lackey)
Newsgroups: comp.arch
Subject: Re: CISC Silent Spring
Message-ID: <51951@bbn.COM>
Date: 8 Feb 90 20:14:46 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>
Sender: news@bbn.COM
Reply-To: slackey@BBN.COM (Stan Lackey)
Organization: Bolt Beranek and Newman Inc., Cambridge MA
Lines: 53

In article <35647@mips.mips.COM> mash@mips.COM (John Mashey) writes:
>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.

Microcode is the way this problem is commonly dealt with.  Microcode
turns an intractable hardware control mechanism into a part of the
design that many a computer hardware or software person can
understand, design, debug, etc.  Because exception handling must be
dealt with in hardware in a RISC, one could make the claim that this
makes RISCs more complex (from a certain point of view) than CISCs.

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

This issue keeps coming up.  You know, I have seen so many compiled
routines that contain inner loops that only use 5 or 6 registers,
inner loops that determine the performance of the program, that I
really wonder how many registers are needed (Oh no not that again!)
Global register allocation and all, who cares if you save and restore
a half dozen registers outside of a loop that is going to execute 100
times.  

Having more registers really does help some of the time, and when
the industry starts making new CISC architectures I'll bet you will
see more, now that program size is not so constraining.

>IF RISC IS SO GOOD, WILL CISC DISAPPEAR?
>	No.
>		68Ks and X86s will be with us forver.
As will lots of other architectures, as long as RISCs are going to neglect
certain functionality.

>WILL THEY CATCH UP?
>	No:
>	Intellectual complexity.
>	Longer design cycles.
>	Less registers than match current global optimizers.
Vector machines always run faster on vector problems than non vector
machines.  Even if the cycle time is a little slower.

The shoe is moving to the other foot, so to speak; in order to match
vector machines, RISCs will need to go to super scalar execution
(assuming they don't add the large register sets or the instructions
to do vectors).  To do this they need to deal with variable length
instructions (variability determined by register dependencies and
stuff in the pipe, not to mention the surrounding instructions),
register and opcode fields in variable places in the instruction word,
complexity handling exceptions, and all the other CISC characteristics 
RISCers love to bash.
-Stan