Needless to say, in the 34 years since that article was published, a lot has changed. Thanks to massively increased transistor budgets, a more complex decoder with accompanying microcode ROM that might have been a big detriment in 1991 would today be a small speck of dust on the processor floor plan. At the same time, memory access performance hasn't increased to the same extent as compute performance, thus putting a relatively bigger emphasis on code density.
All this being said, RISC "won" in the sense that many RISC principles have become the "standard" principles of designing an ISA. Still, choosing "RISC purity" over code density is arguably the wrong choice. Contemporary high performance RISC architectures (ARMv9, say) are very un-RISC in the sense of having a zillion different instructions, somewhat complex addressing modes, and so forth.
Exactly. If you’re going to design a new ISA, you’d be foolish to make it a classical CISC design and would definitely choose RISC (e.g., RISC-V). But if you have a CISC ISA and you want to keep it running fast, then a virtually unlimited transistor budget allows you to create a sophisticated decoder that dispatches micro-ops to a RISC-like core and bridge the gap. That paper really take me back to working on PA-RISC designs at HP during that timeframe.
RISC is more about the time each instruction takes rather than how many instructions because consistent timing reduces bubbles and complexity. In this sense, RISC has completely won. Complexity of new instructions in the main pipeline is very restricted by this limitation and ISAs like x86 break down complex instructions into multiple small instructions before pushing them through.
ARMv9 still has very few instruction modes with far less complexity when you compare it with x86 or some other classic CISC ISA.
> memory access performance hasn't increased to the same extent as compute performance, thus putting a relatively bigger emphasis on code density.
The problem isn't RAM. The problem is that (generally speaking) cache is either big or fast. x86 was stuck at 32kb for a decade or so. Only recently have we seen larger 64kb caches included. Higher code density means more cache hits. This is the big reason to care about code density in modern CPUs.
RISC-V shows that you can remain RISC and still have great code density. Despite arguably making some bad/terrible decisions about the C instructions, RISC-V still generally beats x86 in code density by a significant margin (and growing as they add new instructions for some common cases).
> thus putting a relatively bigger emphasis on code density.
> choosing "RISC purity" over code density is arguably the wrong choice
You appear to be under the incorrect impression that CISC code is more dense than RISC code.
This seems to be a common belief, apparently based on the idea that a highly variable-length ISA can be Huffman encoded, with more common operations being given shorter opcodes. This turns out not to be the case with any common CISC ISA. Rather, the simpler less flexible operations are given shorter opcodes, and that is a very different thing. A lot of the 8 bit instructions in x86 are wasted on operations that are seldom or never used and that could, even in 1976, have safely been hidden in some secondary code page.
The densest common 32 bit ISAs are Arm Thumb2 and RISC-V with the C extension. Both of them have two instruction lengths, 2 bytes and 4 bytes, as did many historical RISC or RISC-like machines including CDC6600 (15 bits and 30 bits), Cray 1, the first version of IBM 801, Berkeley RISC-II.
The idea that RISC means only a single instruction length is historically true only for ISAs introduced in the brief period between 1985 (Arm, SPARC, MIPS) and 1992 (Alpha) out of the 60 year span of RISC-like design (CDC6600 1964, the fastest supercomputer of its time). And, as an outlier, Arm64 (2011), which I think will come to be recognised as a mistake -- they thought Amd64 was the competition they had to match for code density (and they did) but failed to anticipate RISC-V.
In 64 bit, RISC-V is by far the densest ISA.
> Contemporary high performance RISC architectures (ARMv9, say) are very un-RISC in the sense of having a zillion different instructions, somewhat complex addressing modes, and so forth.
Yes, ARMv8/9-A is complex. However there is no evidence that it is higher performance than RISC-V in comparable µarches and process nodes. On the contrary, other than their lack of SIMD SiFive's U74 and P550 are faster than Arm's A53/A55 and A72, respectively. This appears to continue for more recent cores, but we don't yet have purchasable hardware to prove it. That should change in 2026, with at least Tenstorrent shipping RISC-V equivalent to Apple's M1.
> All this being said, RISC "won" in the sense that many RISC principles have become the "standard" principles of designing an ISA.
I disagree. Maybe many RISC chip design ideas may have taken over, but only because there are massive transistor budgets. I'd like to see a RISC chip that actually has a basic instruction set. As in, not having media instructions, SIMD instructions, crypto primitives, etc. If anything, Moore's Law won and the RISC v CISC battle became meaningless and they can just spend transistors to make every instruction faster if they care to.
ARMv9 also has read-modify-write memory instructions, so does any usable RISC-V implementation. It turns out that LL-SC (which would avoid those) does not permit efficient implementations. (LL-SC does look like a rather desperate attempt to preserve a pure RISC register-register architecture.)
I get the impression people believe that instruction density does not matter much in practice (at least for large cores). For example, x86-64 compilers generally prefer the longer VEX encoding (even in contexts where it does not help to avoid moves or transition penalties), or do not implement passes to avoid redundant REX prefixes.
RISC-V is the better sweet-spot, and has no strong IP locks like arm or x86_64. Not to mention the silicon of nowdays changes everything: you avoid silicon design complexity as much as possible since it will be more than performant enough for the bulk of the programs out there.
Yep. And then we learned that transistors were almost free, could be purchased in lot quantities of 1 billion, and could be used to create a translation layer between a CISC instruction stream and a RISC core.
Pre-RISC CPU designs were pragmatic responses to the design constraints of their time. (expensive memory, poor compilers)
RISC was a pragmatic response to the design constraints of its time. (memory becomes less expensive, transistor budgets are tight, and compilers are a little better)
Post-RISC designs of today are, also, only pragmatic responses to the design constraints of today. Those constraints are different than they were in the 80s and 90s.
The supposed dichotomy is just utter horseshit. It was invented as a marketing campaign to sell CPUs. It was canonized by the most popular text books being written by /Team RISC/.
I wish, as an industry, we’d just get over it, move on, and stop talking about it so much.
10 comments
[ 2.9 ms ] story [ 31.5 ms ] threadNeedless to say, in the 34 years since that article was published, a lot has changed. Thanks to massively increased transistor budgets, a more complex decoder with accompanying microcode ROM that might have been a big detriment in 1991 would today be a small speck of dust on the processor floor plan. At the same time, memory access performance hasn't increased to the same extent as compute performance, thus putting a relatively bigger emphasis on code density.
All this being said, RISC "won" in the sense that many RISC principles have become the "standard" principles of designing an ISA. Still, choosing "RISC purity" over code density is arguably the wrong choice. Contemporary high performance RISC architectures (ARMv9, say) are very un-RISC in the sense of having a zillion different instructions, somewhat complex addressing modes, and so forth.
ARMv9 still has very few instruction modes with far less complexity when you compare it with x86 or some other classic CISC ISA.
> memory access performance hasn't increased to the same extent as compute performance, thus putting a relatively bigger emphasis on code density.
The problem isn't RAM. The problem is that (generally speaking) cache is either big or fast. x86 was stuck at 32kb for a decade or so. Only recently have we seen larger 64kb caches included. Higher code density means more cache hits. This is the big reason to care about code density in modern CPUs.
RISC-V shows that you can remain RISC and still have great code density. Despite arguably making some bad/terrible decisions about the C instructions, RISC-V still generally beats x86 in code density by a significant margin (and growing as they add new instructions for some common cases).
> choosing "RISC purity" over code density is arguably the wrong choice
You appear to be under the incorrect impression that CISC code is more dense than RISC code.
This seems to be a common belief, apparently based on the idea that a highly variable-length ISA can be Huffman encoded, with more common operations being given shorter opcodes. This turns out not to be the case with any common CISC ISA. Rather, the simpler less flexible operations are given shorter opcodes, and that is a very different thing. A lot of the 8 bit instructions in x86 are wasted on operations that are seldom or never used and that could, even in 1976, have safely been hidden in some secondary code page.
The densest common 32 bit ISAs are Arm Thumb2 and RISC-V with the C extension. Both of them have two instruction lengths, 2 bytes and 4 bytes, as did many historical RISC or RISC-like machines including CDC6600 (15 bits and 30 bits), Cray 1, the first version of IBM 801, Berkeley RISC-II.
The idea that RISC means only a single instruction length is historically true only for ISAs introduced in the brief period between 1985 (Arm, SPARC, MIPS) and 1992 (Alpha) out of the 60 year span of RISC-like design (CDC6600 1964, the fastest supercomputer of its time). And, as an outlier, Arm64 (2011), which I think will come to be recognised as a mistake -- they thought Amd64 was the competition they had to match for code density (and they did) but failed to anticipate RISC-V.
In 64 bit, RISC-V is by far the densest ISA.
> Contemporary high performance RISC architectures (ARMv9, say) are very un-RISC in the sense of having a zillion different instructions, somewhat complex addressing modes, and so forth.
Yes, ARMv8/9-A is complex. However there is no evidence that it is higher performance than RISC-V in comparable µarches and process nodes. On the contrary, other than their lack of SIMD SiFive's U74 and P550 are faster than Arm's A53/A55 and A72, respectively. This appears to continue for more recent cores, but we don't yet have purchasable hardware to prove it. That should change in 2026, with at least Tenstorrent shipping RISC-V equivalent to Apple's M1.
I disagree. Maybe many RISC chip design ideas may have taken over, but only because there are massive transistor budgets. I'd like to see a RISC chip that actually has a basic instruction set. As in, not having media instructions, SIMD instructions, crypto primitives, etc. If anything, Moore's Law won and the RISC v CISC battle became meaningless and they can just spend transistors to make every instruction faster if they care to.
I get the impression people believe that instruction density does not matter much in practice (at least for large cores). For example, x86-64 compilers generally prefer the longer VEX encoding (even in contexts where it does not help to avoid moves or transition penalties), or do not implement passes to avoid redundant REX prefixes.
Pre-RISC CPU designs were pragmatic responses to the design constraints of their time. (expensive memory, poor compilers)
RISC was a pragmatic response to the design constraints of its time. (memory becomes less expensive, transistor budgets are tight, and compilers are a little better)
Post-RISC designs of today are, also, only pragmatic responses to the design constraints of today. Those constraints are different than they were in the 80s and 90s.
The supposed dichotomy is just utter horseshit. It was invented as a marketing campaign to sell CPUs. It was canonized by the most popular text books being written by /Team RISC/.
I wish, as an industry, we’d just get over it, move on, and stop talking about it so much.