Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!cs.utexas.edu!usc!apple!agate!shelby!portia!dhinds From: dhinds@portia.Stanford.EDU (David Hinds) Newsgroups: comp.sys.ibm.pc Subject: Re: Why The Move To RISC Architectures? ('386 vs. RISC) Message-ID: <10453@portia.Stanford.EDU> Date: 22 Mar 90 19:11:37 GMT References: <28011@cup.portal.com> <26083220.22927@maccs.dcss.mcmaster.ca> Sender: David Hinds Organization: Stanford University Lines: 37 In article <26083220.22927@maccs.dcss.mcmaster.ca>, cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) writes: > > This leads to another advantage - a given-size CISC chip has a very > large (often over 50%) portion devoted to decoding instructions. On > a RISC chip, the decoding logic is far smaller, leaving room for a > barrel shifter, an on-chip cache, an on-chip MMU, or whatever - stuff > that boosts performance. > > So, all in all, the complexity of high-level language constructs > is partially built into the architecture of a CISC chip, whereas it's > left up to the compiler in a RISC architecture. (Also, compilers > for RISC systems generally have more optimization in them for such > things as register usage - RISC chips usually have large numbers of > registers - and to maximize the advantages of pipelined execution). It looks to me like the success of RISC technology is partially the result of a temporary imbalance in circuit design technology vs. the limits of circuit density. People talk about the 80486 as implementing some RISC features. Why? Because it is fast? It seems to me that the 80486 is instead the antithesis - and nemesis - of RISC technology. If we now have the ability to design a CISC processor so efficiently that most of its instructions take only a cycle or two, why move to a less complex architecture? The 80486 had sufficient circuit space left over for a respectable amount of support stuff, as well. You could say, well, a smaller instruction set would have allowed a larger cache or more registers. But both of these follow the law of diminishing returns - beyond some threshold, you have to increase the number of registers or the amount of cache a LOT to get even a small improvement in performance. And the thresholds aren't very high. I seem to remember that analysis of register usage has shown that 4 (I think) registers were enough to efficiently code all common high-level language constructs. If you have enough registers to allocate them for variables, that is a different matter - but with high-speed caches and pipelining, a register loses most of its edge over main memory. -David Hinds dhinds@popserver.stanford.edu