Processors typically split into two camps, with the x86 processor in your PC classified as CISC and the (typically) Arm processor in your phone classified as RISC. CISC, standing for Complex Instruction Set Computer, and RISC, standing for Reduced Instruction Set Computer, are still labels that indicate something about the instruction set your software sees, but much less about the hardware actually running them. And for more than 30 years, high-performance x86 cores have actually been using techniques associated with RISC, while big Arm cores are now using techniques associated with CISC.
I use an x86-based computer, and I use an Arm-based MacBook Pro for most of my day-to-day work. My phone is Arm-based as well, and you might think that a big part of Arm's efficiency is thanks to that RISC architecture. After all, why else would it show up in portable devices so consistently? The instruction set alone doesn't explain the biggest differences.
RISC and CISC still describe two distinct philosophies when it comes to designing an instruction set, but it's been a long time since they described how the chips running them are actually built. There's still a cost associated with x86 in the form of its more complicated instruction encoding, but that cost isn't enough to explain where the performance and efficiency associated with Arm actually comes from.
CISC chips were built around microcode
The 8086 relied heavily on microcode
Intel's original 8086, released in 1978, used microcode to control the execution of many x86 instructions. These routines lived in an on-chip ROM and directed the simpler steps needed to carry out an instruction. Ken Shirriff's reverse engineering found a control store containing 512 micro-instructions, each 21 bits wide, supporting roughly 75 instruction types. Other instructions, along with parts of the decoding and execution process, used dedicated logic.
Microcode was a common way to implement complex instruction sets, and larger computers took it much further. In a Turing Award lecture, Stanford University's John Hennessy and UC Berkeley's David Patterson, two computer scientists known for co-developing RISC, talked about how 20% of the VAX's instructions occupied 60% of its microcode but accounted for just 0.2% of execution time. RISC was their response to that, taking a different approach to the problem.
The philosophy of RISC was simple: give software simpler instructions that the hardware could execute without a microcoded sequence, and spend more of the chip's resources on registers and instruction caching. Stanford's MIPS and Berkeley's RISC-I demonstrated this approach in the early 1980s, and both Hennessy and Patterson later described a historical DEC comparison in which CISC needed fewer instructions per program, but many more cycles per instruction, leaving RISC roughly four times faster in similar technology.
Patterson saw that complexity firsthand while helping fix VAX microcode at DEC. He proposed ways to repair microprocessor microcode after shipping, but IEEE Computer rejected the paper; reviewers objected to building processors complicated enough to need those fixes, and in a rather harsh way. According to Patterson, the bottom line was "This is a stupid way to design computers. It doesn't make sense to design microprocessors this way and, with this extra RAM, and cost, and patching and the field. This is nuts."
The irony is that Intel and AMD now routinely distribute microcode updates for chips people already own.
By the late 1980s, plenty of researchers thought x86 was on the losing side. Bob Colwell, later a senior architect of Intel's Pentium Pro, recalled that some people inside Intel were urging management to abandon CISC, but the company took a different approach, instead changing how it executed the instructions.
x86 adopted RISC's techniques one chip at a time
From the 486 to the Pentium Pro
Intel's 486, released in 1989, showed how much could change without abandoning x86. It had a five-stage pipeline capable of sustaining one simple instruction per clock under favorable conditions, including register work and some loads or stores that hit the cache. Complicated instructions took longer, though, and an add that updated memory required three cycles in the execute stage alone.
The bigger change came in the mid-1990s, but Intel wasn't first to the party. NexGen's Nx586, introduced in 1994, translated x86 instructions into simpler operations for its internal core, which was the first RISC-like change in the x86 world. AMD, with its K5, then took a similar approach, though it had an advantage thanks to its prior RISC work. The K5's lead architect, Mike Johnson, had previously designed the AMD Am29000, and it was reported that the K5 core drew heavily on a superscalar 29000 design. Its decoder turned x86 instructions into between one and four internal operations.
Intel followed with the Pentium Pro in November 1995, and its decoder translated x86 instructions into simpler internal operations called micro-ops, or uops. At the time, these were described as following a RISC-like load/store model: an x86 instruction that adds to a value in memory could be broken into a load, an add, and a store. A conventional RISC program would express those steps as separate instructions.
The benefit of working with micro-ops was that it made it easier to apply techniques associated with high-performance RISC designs, in an effort to enjoy the best of both worlds. The core could execute ready operations out of order, then retire their results in program order so software still saw the expected behavior. That let x86 combine compatibility with deeper pipelines and multiple operations per clock, though the processor still had to preserve x86's rules for memory access, exceptions, and instruction completion.
Microcode didn't disappear, either, as hardware decoders handled common instructions while more complicated cases could use longer microcoded sequences. In a SIGMICRO oral history given by Colwell, he gives the example of a far call through a gate that might require 200 micro-ops. The difference, though, was that ordinary code no longer depended on that slower path for every instruction.
Big Arm cores now do things x86 was known for
Splitting instructions and caching the results
Modern Arm cores, nowadays, also split instructions into micro-ops, sometimes even dozens of them. On Fujitsu's A64FX, used in Japan's Fugaku supercomputer, Chips and Cheese mentions that the SVE instruction FADDA expands into 63 micro-ops, performing an ordered floating-point reduction and adding vector elements into a scalar accumulator. LDADD expands into four and combines a memory read, an addition, and a write in one instruction. A RISC instruction doesn't necessarily translate into a simple hardware operation, and these are examples of that.
There's another thing that Arm does which is borrowed from x86-land: caching. On Arm, cores cache decoded operations in order to avoid decoding the same instructions repeatedly. The Cortex-A77, introduced in 2019, added a 1.5K-entry macro-op cache, and while the terminology differs from x86's micro-op caches, the purpose is similar. You can reuse decoded work to improve throughput and reduce fetch and decode activity.
This doesn't make AArch64 a CISC-based architecture; after all, it still uses fixed-width, 32-bit instructions and generally keeps ordinary arithmetic separate from memory access. However, that doesn't stop one instruction from describing a large body of work, especially with vector and atomic operations. As cores get wider and more ambitious, their internal mechanisms can look increasingly similar to each other even when their instruction sets remain different.
Not everyone agrees there's a RISC core inside x86
Including one of the people who designed it
Referring to x86's micro-ops as "RISC-like" has a couple of bundled caveats, given that the architect of the Pentrium Pro, Bob Colwell, disagrees with that assertion. Specifically, he objected to blurring the distinction between the instruction set software sees and the hardware that implements it.
Collwell's defence was rather simple, leaning on the fact that the instruction set is a promise to software about what instructions exist and what they do, while the microarchitecture is how a particular chip keeps that promise. Chip designers are able to change the pipelines, the decoders, and the execution mechanisms while still preserving the behavior programs expect, and that's what the Pentium Pro did. It still remained an x86 processor despite how different it was underneath.
Internal micro-ops aren't instructions that software can target, and the Pentium Pro's 118-bit format carried information for the processor itself. This means that comparing its width with a 32-bit RISC instruction doesn't tell you much about either design's complexity. Later Intel cores also used micro-op fusion, allowing for things like a load and arithmetic operation from one x86 instruction to share an entry through parts of the core. In this instance, the load and arithmetic still requires separate execution work, but the core doesn't have to track them separately.
The confusion comes from using "RISC" for both an instruction-set philosophy and the implementation techniques associated with early RISC processors. x86 kept its instruction set while adopting many of those techniques. Calling parts of the implementation "RISC-like" makes sense, but all your software sees are x86 instructions.
The instruction set still costs x86 something
Just not as much as you'd think
x86's variable-length instructions make decoding more complicated, but accurately describing a penalty is harder. In a 2016 study of Intel's Haswell Core i7-4770, researchers estimated the decoder power using Intel's own energy reporting alongside a statistical model. In two selected microbenchmarks, decoding accounted for roughly 3% and 10% of package power, and they state that switching to another instruction set would save "only a small amount of power" given that instruction decoding is unavoidable. Keep in mind that this is a single Haswell-based core rather than a broader evaluation of x86 compared to Arm, though.
Modern x86 cores use micro-op caches to reduce repeated decoding and feed more operations into the core. AMD's Zen 5 has a 6K-entry cache, and in testing, Chips and Cheese measured a 20.3% drop in SPEC CPU2017 integer performance with it disabled. There's a pretty big benefit from reusing decoded instructions, though the same gain isn't likely to be universally applicable. The same testing found almost no difference between Cyberpunk 2077 and Grand Theft Auto V, suggesting that reusable instructions can make a big difference, but it's entirely dependent on the workload.
Arm's Cortex-A715 core took a different approach. Introduced in 2022, it dropped AArch32 support, simplified its decoders, and removed the decoded-operation cache used by its predecessor, which shows how simpler decoding can change a core's tradeoffs. x86's legacy operating modes are a separate part of its compatibility burden, and removing them wouldn't make its remaining instructions fixed-width.
There's also evidence against treating either ISA class as inherently more efficient, with another study from 2013 finding no fundamental energy-efficiency advantage for either ISA class among the processors and workloads it examined. It doesn't tell us anything about today's x86 overheard, but it supports a broader point: a chip's design goals, manufacturing process, caches, branch predictors, and power management all matter. There's a lot that goes in to making a device efficient, and it's not just about comparing CISC to RISC.