Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: notesfiles
Path: utzoo!watmath!clyde!floyd!harpo!decvax!ucbvax!ucbcad!ucbesvax.turner
From: turner@ucbesvax.UUCP
Newsgroups: net.arch
Subject: Re: RISC perspective
Message-ID: <27900009@ucbesvax.UUCP>
Date: Mon, 19-Mar-84 22:55:00 EST
Article-I.D.: ucbesvax.27900009
Posted: Mon Mar 19 22:55:00 1984
Date-Received: Sat, 10-Mar-84 08:39:01 EST
References: <-28000@orstcs.UUCP>
Organization: UC Berkeley, EE/SESM
Lines: 39
Nf-ID: #R:orstcs:2800001:ucbesvax:27900009:000:2340
Nf-From: ucbesvax!turner    Mar  4 19:55:00 1984

> /***** ucbesvax:net.arch / orstcs!nathan / 10:42 pm  Mar  3, 1984*/
> I would like to make the claim that a RISC with a medium-to-large
> instruction cache could be called a "virtual-microcode" machine.
> ... the subroutines that implement what would be instructions on another
> architecture tend to be in the cache all the time.  This includes the
> Enter and Exit operations, loop operations, and the like; esoterica such
> as long divides would sit out in main memory until needed.  [Nathan Myers]

I think that's what they had in mind (I haven't kept up with the ever-
shifting rationale for RISC).  I still question whether the gains reaped
from the various simplifications and optimizations possible in RISC
architectures aren't lost in some ways.  RISC has no BCD or i/o formatting
instructions, because "compiler-writers don't use them."  Fine.  But
programs nevertheless spend much time translating back and forth between
ASCII/EBCDIC and binary.  Instructions with a static frequency approaching
zero might still have a dynamic frequency (and a cost for emulating them
in software) that is quite high.

So if "printf" is in the cache, rather than having much of it hardwired in
microcode, this leaves less space for other code that competes for the
cache.  Also, since RAM has a lower bit-density than ROM/PLA implementation
there is that much less space to compete for.

But then again--when you are *not* using BCD/io-format heavily, on a RISC
you don't have to pay for them.  It's a trade-off.

I have advocated "cache-advisor" instructions for RISC's--instructions
that don't *do* anything, from the programmer's point of view, but which
inform the cache-manager of highly-probable-to-certain upcoming memory
events.  This is another trade-off--a loss of code-density with a possible
net gain in performance.  That need not complicate the architecture.  It
could, in fact simplify it--if cache-block-prefetching were more effective,
then instructions could be looser and "fatter" (more easily decoded and
executed) with less worry over the fetching costs.  Possible analogies:
impurity doping of semiconductors to increase electron mobility, or
adding minute amounts of certain minerals in steel-making to improve its
tensile strength.  It's worth some experimentation, I think.
---
Michael Turner (ucbvax!ucbesvax.turner)