rb@ccivax.UUCP (03/11/86)
In article <377@ektools.UUCP> john@ektools.UUCP (John H. Hall) writes: >In article <449@ccivax.UUCP> rb@ccivax.UUCP (What's in a name ?) writes: >>Yup! If you ran ALL instructions directly from main memory, this would >>be correct, but RISC chips usually have either internal or tightly >>coupled CACHE which reduces the number of fetches from main RAM. In >>fact, some RISC machines have several LAYERS of CACHE, such as 2K >>internal, 2 meg external, then the bus, and even a cache to the disk. >Is there some reason that RISC machines require cache to operate? Not really, you could build a RISC machine with 10 meg of 50 ns RAM. Of course, you could probably do the same with CISC. If you made heavy use of the complex instructions, CISC would even have an advantage. Cache simply allows the RISC processor to have the optimimum "complex" instruction set for what is being done at that particular moment. >Are the benefits of cache greater for RISC architectures? It depends on whether you view the cache as "just any old ram" or as the equivelant of the micro-code in a CISC machine. As micro-code, the advantages are fairly clear, the "complex" instructions (subroutines) in the machine during a particular loop or whatever will be optimum for that moment, compared to a ROM microcode which is optimum only when the complex instructions are used. >I guess I see cache as an architectural feature separate from the >RISC-iness of a machine's instructions set. These archetectural features are simply ways of making RISC cost/performance competitive with CISC machines. The archetectural features are useful options in CISC, but gain importance in RISC. >Why wouldn't cache benefit a CISC machine? They do, in fact they are helpful options on a CISC machine, and may become an integral part of future CISC designs. The 68020 has cache built into the chip. As these features are added, the simpler instructions become almost as efficient as the complex ones. Now, given various tradeoffs (real estate, cost, gate count...), should instructions become more complex even though they are not frequently used, or should more resources be directed toward improving the flow of the simple instructions? >For single-chip designs, given a particular die-size and line width it >is easier to find room for on-chip cacheing with a RISC design. (Of >course, the extra space could also be used for a huge register file, >another "RISC characteristic" that seems to be equally applicable to >CISC designs.). >Are we muddying the waters by lumping a bunch of good ideas: > - Reduced instruction sets > - Large register files > - Multi-layer cache >all into the category of RISC? Yes, but discussion of how to use the "extra real estate" RISC leaves available is the whole point of using RISC in the first place. These are choices which can vary from manufacturer to manufacturer without changing the instruction set. The CCI 6/32 for example, optimises 'C' calls and context switches heavily, the overhead is typically 5% over inline coding. A DSP device may optimize data throughput and do very little to optimize subroutine calls. Some of the areas that I haven't seen yet are things like "Demand Paging" the cache, multiple parallel caches, and multiple pipelined caches. Perhaps these are too complex or time consuming to be practical. We could really muddy things up by adding the role of multi-processing, multi-computing, and various other "Non-RISC" issues. RISC is simply a sign of changing focus from the instruction set to other, more interesting and possibly more important archetectural issues. The assumed advantage of CISC was that compilers, programmers and software would make use of the complex instructions, and that those complex instructions would be used frequently and heavily. With instructions like divide and multiply, this is might be the case, but could be more efficiently done with a hardware multiplier than a micro-code subroutine. Other instructions are seldom used and waste real estate. The best compromise between RISC and CISC is probably any instruction/addressing mode that gives >2:1 improvement over a "pure RISC" machine. The goal of RISC should be to be able to run at a net speed of > twice the speed of the equivilant price/real estate CISC machine. Perhaps, in a year or two, we'll see the best of both worlds on a single chip :-). Rex B.