What was it about, and does it matter today?
While modern CISC (that is x86-64) processors use many RISC principles in their design. They ultimately are still stuck with the old instruction set. This was improved in x86-64 but still has the fundamental CISC way of working.
Like the 68060 this complexity has an impact on the design on the processors. Of the 3 forms of complexity mentioned previously, this especially impacts fetch and decode. Fetch is most likely done via a large buffer. Instruction lengths have to be worked out so this involves partially decoding the instruction.
Once instruction sizes are established and instructions are fetched, the hardware must work out exactly which of the myriad instruction formats it is. Once the instruction format is established the is instruction sent to the relevant decoder where it is decoded and broken into micro-ops for execution.
Execution is somewhat different as it involves putting the micro-ops into a large out-of-order execution engine. It is in the execution stages that modern RISC and CISC processors are likely to be the most similar. One exception however is the CISC processors will use more temporary registers and these also need to be tracked and renamed and tracked. Though I don't think this will make that much of a difference. Status bits may prove more challenging but some RISC designs also have at least a few of these.
There are several RISC families still going but IBM is mostly in servers while RISC-V is mostly in embedded. For desktops and workstations it's pretty much just Arm64 (officially called AArch64).
While modern RISC chips are highly complex [M1RE], they used fixed length instructions and limited numbers of instruction formats. The fetch and decode stages in these processors can be a great deal simpler than x86-64.
Fetch is done via an instruction buffer. Some top end Arm64 processor cores fetch and issue up to 10 instructions per cycle (Apple M4, M5, Nvidia Olympus [OLY]). Modern RISC designs also use micro-ops but the instructions being broken up are not nearly as complex as x86 instructions, and many instructions aren't broken up at all.
On the CISC side, Both AMD's Zen 5 and Intel's Lion cove / Cougar cove have 8 wide decoders, however the width of the decoder however may not be directly comparable as individual CISC instructions can be more complex and can conceivably get more done. That said, x86 decoders, at least in the past would be grouped with simple and complex decoders, with more of the simple decoders.
The CISC decode requires hardware in x86 processors to deal with a level of complexity that Arm64 or (other RISC processors) just don't require.
This extra hardware is highly complex hardware. Hardware that calculates the lengths of instructions in parallel or predict the location of further instructions all requires power. Adding more to handle multiple instructions per cycle only requires even more complex logic.
Running this soft of hardware at a high clock speed only serves to increases power requirements even more. I think this is the fundamental limitation that x86-64 vendors are now hitting.
The RISC decode process is so much simpler that RISC processors don't require this much complex hardware and thus don't need to power it. They can either allocate the power to something else to boost performance, or just run at lower power levels.
Intel used to have the best silicon process in the industry and consequently made the fastest single-threaded processors. They had this lead for many, many years. This was a circular advantage - the best silicon meant they could make the fastest chips, they made more money, so Intel invested in better silicon process and this allowed them to make better chips... Intel broke that circle when they didn't invest in EUV technology, leaving them stuck on the 10nm node for several years.
In 2021 Intel brought back previous CTO Pat Gelsinger save the company. He bet on getting Intel's silicon process technology back even with TSMC. After spending a great deal of money and several years of high accelerated development, Intel's 18A process is now technically the most advanced in the industry. The engineering heroism worked but it doesn't appear to be providing much of a performance advantage as of yet. However, even if it was, silicon processes and fabrication plants have become so expensive that Intel now have to make chips for other companies, including competitors. Apple, SpaceX and Nvidia have all been mentioned [FAB].
The silicon process has become the great equaliser and this first enabled AMD to pull ahead of Intel. It then enabled Arm64 vendors (notably Apple) to produce laptop chips with similar or better single threaded performance than x86 desktop parts [Bench].
Single threaded performance may not seem important these days as modern processors add more and more cores, however, it very much still matters, probably more than you think.
Every application has sequential sections that can only run on a single core and this limits the performance of the entire application. The performance of any algorithm running on multiple cores is determined by the single threaded performance of a processor. This was first presented by computer architect Gene Amdahl in 1967 and became known as Amdahl's law. [Amdahl]
Not only is the single threaded performance level of the M5 highest on the market, it is achieved at considerably lower power consumption than x86-64 processors. x86-64 processors have clock rates up to 6GHz and peak power consumption figures up to 170W for AMD and up to 250W for Intel's highest desktop models.
Apple's M5 Max has been measured at up to 90W under a sustained heavy load - and that includes the GPU!
To get the throughput that an Arm64 can achieve, the x86-64 processors must either increase the number of decoders, costing complexity and power, or up the clock rate, also increasing power.
Simpler decode makes for lower power and faster processors. There is the x86 ecosystem advisory group [EAG], who are putting forward proposals to increase performance, in the process making x86 even more RISCy [APX]. This will help, but it isn't clear how x86-64 vendors can fight against Arm's simpler decode advantage.
Arm came up from below (and partly above) to attack x86. Arm however is now under pressure from another contender attacking Arm from below. Another modern RISC design, RISC-V, is increasing having success in the embedded market.
RISC-V is the fifth CPU developed at Berkeley. This processor is also public and open source [Patterson].
I began this article with what I described as the 4 tenets of RISC, 46 years later, are these still relevant?
Nobody is making processors with the type of complex microcode that the original RISC paper talked about. The move towards making processors implement high level language features appears long dead.
Internal registers are used exclusively in RISC instructions but not in x86 instructions where an instruction can include an operation and a memory access.
x86 have been breaking instructions into micro-ops since at least the Pentium Pro. Instructions that include memory operations are broken apart so internally x86 processors are essentially load-store machines. For example, a load will executed separately into a temporary register, when the data is loaded the operation is executed. If there is a memory write that would also be executed as a separate operation.
Plenty of special instructions or data types have been added over the years but these are to typically speed up specific algorithms. Other features have also been added over time such as SIMD units or security features but these increase functionality. There has been no adding of complex addressing modes just because they can.
An explained in previous sections the RISC processors have a much easier time fetching and decoding instructions. I think this is the biggest difference between modern RISC and CISC designs. In my opinion, it is the complexity decoding the x86 instruction set that is giving processor designers an increasingly hard time improving performance, allowing Arm64 (a RISC design) to pull ahead.
The type of processor designs that RISC was a reaction to, are long dead.
x86-64, the only remaining mainstream CISC architecture (which wasn't really what CISC originally meant) uses many of the RISC concepts. Processors today are a great deal more complex now than early RISC designs, but the complexity is mostly not in the areas that slowed the original CISC processors. So, yes, in my opinion that tenets of RISC are alive and well and every bit as relevant today.
RISC has taken over the vast majority of the CPU market. CISC may remain king on the desktop, but it's not really CISC and today, RISC processors are also making inroads on the desktop.
I have talked about the complexity in CISC processors and their disadvantages, but not all of CISC is bad. One feature of CISC instruction sets that their advocates focus on is that they tend to have very good code density. The code they run tends to be small and thus fits better into cache.
For embedded processors code density is very important as memory is at a premium. On the other hand, this appears to have relatively little effect on the desktop for most workloads. I suspect it could be providing a little extra performance.
Can RISC processors also somehow get this advantage?
Some RISC instruction set architectures such as Arm's Thumb, MIPS16e, and RISC-V C extensions use a mixed 32/16 bit instruction set to achieve better code density. This makes code smaller and it is still simple to decode, but typically these techniques have limitations.
Is it possible for RISC take a leaf out of the CISC playbook and get even better code density, but without the associated complexity? Can you make the variety of variable-length instructions CISC processors use, simple to fetch and decode?
I think there is a way to do this, using a technique from the CDC 6600 in 1964: Pack different lengths of instructions into a long fixed word.
The aim of this proposal is to provide a way to use variable length instructions but keep the decoding simplicity of RISC.
Firstly, instructions are packed into a fixed length long instruction package, at for example, 128 bits. The package provides a way to fit variable length instructions together but the package itself cannot roll over a cache line or memory page.
A bit field indicates how the package is divided into instructions. For example, 4 bits would give you 16 package-formats, that is, 16 different ways to pack instructions.
The package-formats are predefined so the instructions will always be in set locations that are defined in the package-format. There is no requirement to calculate the length or position of instructions.
An unpacker stage is required that extracts the instructions and expands each to a full 32 bit (or bigger) fixed-length RISC format. Because the instruction locations are known by the unpacker, this is relatively simple and importantly, instruction extraction can be done in parallel. This means you can use variable length instructions but without much of the associated complexity.
Package formats can be pre-designed to include different lengths, including non-powers of two. Addressing modes can also be defined by the format. Both of these remove the need to use bits in the instructions to indicate these, thus improving code density further. This is all fixed in the package-format so is relatively easy to implement.
As found during the 801 research [801], most code uses a small number of the total available instructions. If the most commonly used are made as small as possible, there can potentially be some very good code density gains. Andrew Tanenbaum encouraged this in his work [EM-1] but not in a packed format.
I think this example serves as an illustration of the RISC philosophy. It's not about the features you want to implement, it's how you do it. Variable length instructions are typically seen as a CISC feature, however in this proposal I show how they can be done in a manner compliant with the RISC philosophy.
RISC vs. CISC at 46, Section A
RISC vs. CISC at 46, Section B
RISC vs. CISC at 46, Section C
RISC vs. CISC at 46, Section D
RISC vs. CISC at 46, Section E
© Nicholas Blachford 2026