1. As microprocessors became dominant freezing complex microcode - with possible bugs - on an IC was a really bad idea. Better to run with simpler instructions and less microcode.
Look at the debugging issues that National Semiconductor had with the NS32016 - which I think really hindered its adoption.
2. You needed a much smaller team to design a RISC CPU - low double figures for IBM 801, Berkeley RISC, MIPS and Arm. This opened the door to lots of experiments and business models that would not have been possible with CISC.
What RISC took advantage of was decoupling the memory bus from the CPU clock rate and the introduction of instruction and data caches.
RISC is a simple interface, but the internal processor complexity is as high or higher than CISC (thanks to RISC simplicity). Speculative execution, reordering instructions, hazards, branch prediction these issues are the same across both.
The front end isn't this huge deal. CPUs all do the same thing, attempt to unroll huge state machines and compress time. The ISA is just a way to get that problem into the CPU.
I actually cited an example of a major CISC design that basically failed because it was so buggy.
The early microprocessors all had hard coded microcode - Intel only had upgradeable microcode with P6 in the mid 1990s.
I didn't say that it was the reason - there were many reasons - but that it was one factor. It was absolutely the case that original RISC designs were simpler to design and that helped them to get traction.
1990? No system without soft microcode? That's a very restricted definition of system for the field of computing in 1990.
Intel 8086 was introduced in 1978, with hardcoded microcode. Intel didn’t introduce microcode patching support until the Pentium Pro in 1995.
Interesting. Was the guiding principle of CISC ISAs essentially that be easy to write assembly code for then? Maybe it's obvious but I had never considered how or where CISC evolved from. Would I have to look at something like the history of the VAX ISA to understand this better?
What is certainly true is that a single instruction could do a lot, making for much more concise code than would be the case for RISC code.
IBM S/360 is probably the most influential CISC architecture. There is lots of S/360 documentation online. If of interest I did a short post on S/360 assembly a little while ago.
https://thechipletter.substack.com/p/writing-ibm-s360-assemb...
I genuinely had no idea how awful it was - of course you don't see pop-ups if you are logged in. To be fair to Substack the control to turn off pop-ups was there but it was turned on by default and a bit buried away in the UI.
I've removed any mid-article calls to action and turned off pop-ups now so hopefully a much better and less aggressive experience.
On the S/360, the article I linked too was a short look at how complex some S/360 instructions were and at how assembly used to be written using pen and paper. If you're interested in more on S/360 Assembly then the principles of operation may be worth a scroll through.
Thanks again - really appreciate that you fed back rather than just closing your browser window.
[1] http://bitsavers.org/pdf/ibm/360/princOps/A22-6821-0_360Prin...
And more importantly, future compilers, not the tech they had at the time.
You have it right: this is almost exactly (in different words!) what Radin wrote in his original RISC paper.
I think the design principles of RISC were actually on a meta level above this: take the quantitative approach, use your transistors to best serve the software you have and compilers you can build. "Nice ISA to write assembly code for" was thrown out, or at least demoted significantly.
In that 80s moment in the transistor count curve, it meant simplifying the ISA very radically in order to implement fewer instructions in hard coded way without microcode, to the point of ditching HW multiply instructions. The microarchitecture could either do fast, pipelined execution or large instruction set in the transitor budget, you optimized for bang for the buck in the whole-system sense. You could make simple fast machines that were designed to run Unix (so had just enough VM, exception, etc support).