I finally got around to reading that note. My principal reponse is that it got so far down into details that I couldn't see the larger picture any more. Going back to the original IBM 801 work, the RISC concept is very simple: to make the overall system as fast as possible; it did this by making the CPU cycle time as short as possible. This results in a CPU that is not as easy to work with; therefore the compiler has to be 'smarter'. In other words, engineering complexity is moved from the hardware to the software. This is an an acceptable tradeoff; the complexity in the software is not a recurring cost, whereas extra gates add cost to every machine produced. Moreover, while the more complex compiler may be more time-consuming to run, that cost is only paid once, whereas the efficiency of the binary is felt every time the program is run. Focusing on what features a CPU does or does not have in some ways misses the whole point of RISC: it's not about what specific features the CPU has, in isolation; it's about looking at the system as a whole, all the way up through the compilers, to maximize performance. I recall Tom Knight laying out the implication for CPU design very simply, in a seminar I took back when the idea had just come out: look at the CPU design, and find the longest signal path; this will set the lower limit on the clock time. Redesign to remove that path; since the capability that needed it will inevitably be used only part of the time, the execution increase caused by losing it will be outweighed by the speedup of all the other instructions. The other thing one needs to remember, talking about RISC, is that it's now been almost 40 years since the concept was devised (an eternity in the computing field), and the technology environment has changed drastically since then. So RISC has changed and adapted as that environment changed. Nowadays, when people throw a billion transistors at each CPU, the picture is somewhat different. Register widows were just the first instance of this sort of thing; we have this unused area of the chip, what can we put there? No; compilers had been created that could use the more complex CISC instructions of, say, a VAX. RISC post-dated a lot of those developments, and had an entirely different point. Right; what's reduced is the complexity of the instructions, which leads to the speedup which is the goal, not the number of them. In fact, a RISC CPU may actually have more instructions, e.g. separate ones for different cases, with the compiler being given the responsibility of picking the right one, instead of the CPU figuring it out as it goes. This in another aspect, which I've mentioned before, behind the rise of RISC, which is the changing size and speed of main memory, relative to the CPU. Simpler instructions are faster, but a given task will need more of them. This is acceptable if the memory can supply them fast enough. If the memory bandwidth is less, more complex instructions make sense, to get more out of the limited bandwidth. Also, if memory is of limited capacity, or expensive, then more complex instructions make sense, since more can be done with a fixed amount of memory. (The PDP-11 still scores very high in code density.) This too, however, has been overtaken by the march of technology. Still, the basic idea of RISC still applies; make the CPU clock rate as fast as possible by making the instructions simple, and let software deal with the resulting issues. Noel