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!mhuxt!houxm!vax135!petsd!peora!jer From: jer@peora.UUCP (J. Eric Roskos) Newsgroups: net.arch Subject: Re: risc, cisc, and microprogramming Message-ID: <1078@peora.UUCP> Date: Mon, 17-Jun-85 08:53:10 EDT Article-I.D.: peora.1078 Posted: Mon Jun 17 08:53:10 1985 Date-Received: Tue, 18-Jun-85 08:07:26 EDT References: <557@hou2b.UUCP> Organization: Perkin-Elmer SDC, Orlando, Fl. Lines: 54 > funny how things come full circle. one way to implement the above is to > have dynamically loaded microprogrammed instruction sets. but as dave > paterson mentions in his paper (i think), the difficulty of writing > and supporting microprograms along with the time penalty in using > microprogrammed logic (versus hardwired logic) led to the RISC idea. At this point I think we have more or less exhausted the basic tenets of the two viewpoints here. You are certainly correct that this is the RISC argument; yet I had this in mind when I made the statement you are commenting on. [Now, I am naturally a little biased in favor of dynamically loaded micro- programmed instruction sets; my Master's thesis research was on the foundations of the tools necessary to produce exactly that on a PE 3220. (See Micro-14). (It was subsequently implemented by Len B. Reed for his Master's thesis, providing a microprogram image that was swappable on a per-user basis; and this was then built upon by E. Mike Carter for part of his PhD dissertation to implement dynamic type-oriented vertical migration. All this was done under the direction of R. I. Winner.)] A weak point of the RISC argument is that a lot of it is based on the notion of what is "easy" and what is "difficult". It's "difficult" to write and maintain microcode; it is "easy" to build RISC machines. Furthermore some CISC machines are poorly-designed, giving some vague support to the benefits of the RISC machines. And of course, it has been shown that the instruction set required for a particular program may be quite different from that required for another. Thus, we come down in some sense to the very old argument of the merits or limitations of generating subroutines inline. I think that the two issues have fundamental similarities. If you have instruction sequences that are recurrent throughout a program, is it better to generate them again each time, or generate a subroutine call to one copy of them? Is it possible to produce a general-purpose subroutine that can be used by many programs, or will such a routine be unusable for one reason or another? What about the possibility of discovering a new, better way to do the code sequence; in one case, you can change the subroutine; in the other, you must generate the code all over again. On the other hand, with compilers it's not that hard to regenerate it. I think the real merits of the RISC architecture are not in the "RISC vs. CISC" debate. It appears that people have a tendency to become conceptually entrenched in the design of architectures of various types. Every once in awhile, someone comes along and does it all in a simple way, and people marvel at how well it works, and how simple it is. Operating systems were like this; Unix was an example of a demonstration of what you can and can't do with a much simpler approach than what had been the focus of research. -- Full-Name: J. Eric Roskos UUCP: ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jer US Mail: MS 795; Perkin-Elmer SDC; 2486 Sand Lake Road, Orlando, FL 32809-7642 "Gnyx gb gur fhayvtug, pnyyre..."