Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!mcgill-vision!bloom-beacon!mintaka!yale!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!apple!portal!portal!cup.portal.com!bcase
From: bcase@cup.portal.com (Brian bcase Case)
Newsgroups: comp.arch
Subject: Re: '040 vs. SPARC (was: Next computer...)
Message-ID: <26737@cup.portal.com>
Date: 9 Feb 90 00:55:05 GMT
References: <8905@portia.Stanford.EDU> <160@zds-ux.UUCP>
  <38415@apple.Apple.COM> <2101@crdos1.crd.ge.COM>
Organization: The Portal System (TM)
Lines: 21

>  This is very impressive. I would like to propose using MISC instead of
>CISC, since the microcode which used to require many cycles per
>instruction is now replaced by hard logic for virtually all of the
>instructions, maybe all in the 040. I expect the 586 to have 1+
>instructions per cycle average, too, indicating that traditional RISC
>may have been the way to go when chips were small, and that richer
>instruction sets may become possible in the next decade without giving
>up any performance.

No, hard logic is there for the simple instructions; the complex ones
do a "Hold everything for a few cycles until we can finish this
thing."  Yes, the 586 may indeed have 1+ instructions per cycle
on average, but that will only be for programs that use the simple
instruction subset.

Hey guys, only certain kinds of instructions can be made to fit in
a reasonable-length, uniform, lock-step pipeline.  That's a fact and
it's one of the ones on which RISC is based.  CISC chips are looking
good because they are making the simple instructions go fast and because
the compilers are changing.  And that's a function of $$ available
for development efforts....