Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site spar.UUCP
Path: utzoo!watmath!clyde!bonnie!akgua!whuxlm!harpo!decvax!decwrl!spar!freeman
From: freeman@spar.UUCP (Jay Freeman)
Newsgroups: net.arch
Subject: Re: RISC/CISC - IBM mainframes
Message-ID: <345@spar.UUCP>
Date: Thu, 20-Jun-85 13:29:02 EDT
Article-I.D.: spar.345
Posted: Thu Jun 20 13:29:02 1985
Date-Received: Sun, 23-Jun-85 01:38:14 EDT
References: <1452@ecsvax.UUCP> <1062@peora.UUCP>
Reply-To: freeman@max.UUCP (Jay Freeman)
Organization: Schlumberger Palo Alto Research, CA
Lines: 42
Summary: 

In article <1062@peora.UUCP> jer@peora.UUCP writes:

>A reasonable approach to producing CISC machines, then, would be to have the
>compiler writers design the instruction set; and to have the instruction set
>be changeable for different languages.  This could be extended by having the
>instruction set be further changeable by the individual user, or automatically
>by a program that analyzes instruction usage and moves frequently-used
>instructions into microcode (vertical migration).

The issue seems to be the tradeoff between the following two approaches
to implementing the functional equivalent of a complicated instruction set:

(A) Do a CISC with loadable microcode, and put the complicated stuff therein.

(B) Do a RISC and put the messy things in a ("loadable", of course) runtime
    library in main memory.

Lower-level issues in the tradeoff would include (1) virtues of using CPU
real-estate for microcode and interpreter (CISC) vs. registers (RISC); (2) 
speed and efficiency of paging and cache-management (since the RISC will 
access its runtime library more often than the CISC); (3) Possible slower
operation of the CISC because of bottlenecking by stuff to support the
microcode interpretation; (4) who's ahead in the race between memory speeds
and processor clock rate -- are the systems bound by fetches or by
processing time?

A fine point, is that most of the CISCs' prospective vices do not go away if
we should decide to minimize use of the microcode store -- we can't turn the empty
store into more registers at runtime, nor can we speed up the clock.  Thus
if we consider a range of implementations:

(1) RISC with runtime library
(2) CISC with very little microcode and lots of runtime library too
   .
   .
   .
(N) CISC with mucho microcode

there is a prospective discontinuity in throughput between (1) and (2),
whose possible existence and nature will probably complicate comparison of
the various architectures.
-- 
Jay Reynolds Freeman (Schlumberger Palo Alto Research)(canonical disclaimer)