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)