Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site peora.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!ihnp4!houxm!hjuxa!petsd!peora!jer
From: jer@peora.UUCP (J. Eric Roskos)
Newsgroups: net.arch
Subject: Re: RISC cache vs CISC u-code
Message-ID: <2022@peora.UUCP>
Date: Wed, 12-Mar-86 10:40:42 EST
Article-I.D.: peora.2022
Posted: Wed Mar 12 10:40:42 1986
Date-Received: Fri, 14-Mar-86 05:12:57 EST
References: <136@pyramid.UUCP> <5100024@ccvaxa>
Organization: Concurrent Computer Corporation, Orlando, Fl
Lines: 52

> I agree with your basic point, but there's another aspect to RISCs:
> there is a big difference at the moment between hardware, where it is
> easy to do things in parallel, and software, where it isn't. Microcode
> is just software used to implement sequential operations. One of the
> things we can do to increase speed is to make sequential operations
> parallel, which usually comes down to implementing serial operations
> combinatorically. Whenever you have a serial operation that cannot be
> made parallel, there are usually enough special cases that can be detected
> at compile time to make a standard library function suboptimal - and this
> is just as true for microcode as it is for a matrix mathematical library.

While I must admit that I have some difficulty understanding how some of
the statements above follow from one another, there's one basic idea here
that sort of bothers me; the idea that "microcode" is just like RISC
instructions.

Someone in another recent posting stated it very well -- the RISC
instructions are similar to *vertical* microcode.  In the case of vertical
microcode, it's true that you have a limited amount of parallelism.  But,
in machines with a more "horizontal" microcode, you can achieve a great
deal of parallelism.

Furthermore, not all microcode looks anything at all like a conventional
program; as Mead & Conway point out, possibly the only reason so many
microprogrammed machines have microprograms that look like a conventional
"assembly language" program is that people are more used to writing that
kind of program than they are at writing microprograms in state machines.

Awhile back I said that I think that really the RISC and CISC goals,
beneath all the politics, are fairly similar.  Let me explain one reason
why.

One of the ongoing areas of research in microprogramming involves "vertical
migration" -- analyzing sequences of code to determine things that can
be migrated into the microcode, essentially to produce new instructions.

From the RISC end you'd just go the other way; it's been argued that the
cache does that "automatically," but it's hard to believe that in the long
run, when the RISC approach has come to be seen as mundane, that someone
doesn't start doing statistical analyses on RISC instruction sequences, and
discovers that some sequences commonly occur, and makes new instructions
out of those.  But that's essentially identical to the vertical migration
strategy.  You probably come up with cleaner sequences than you would from
some arbitrary CISC instruction set [although I suspect in the long run
they would be self-refining anyhow], but I think the underlying approach
is more or less the same.
-- 
      e:                  (             )                     jer@j
 omp                    (      (   )      )                         ter Co
     d,                   (             )                     o, FL

"It's a long way from Brooklyn to LA..."