ISA Design Choices: RISC, CISC and Extensions

Every instruction set is a collection of design decisions: how long instructions are, how many registers there are, whether arithmetic can read memory directly, how complex a single instruction may be. Those decisions were made under the constraints of their time and still shape how processors are built today. This article explains the two great families, CISC and RISC, compares the same C loop compiled for x86 and for RISC-V instruction by instruction, measures what RISC-V's compressed extension does for code size, and puts a number on what an extension costs in silicon by synthesizing a hardware multiplier.

13 min read | Beginner to Intermediate

What You'll Learn

• Describe the main design choices of an ISA and the trade-offs behind each
• Compare CISC and RISC instruction sets and explain how each came about
• Explain code density and what compressed instructions save
• Weigh the hardware cost of an extension against what it gains

The Choices Behind an ISA

An ISA designer decides, among other things:

• Instruction length: all instructions the same size (fixed length), or each as long as it needs (variable length).
• Operands: how many registers an instruction names (two, with the result overwriting one source, or three), and how many registers exist.
• Memory access: whether only loads and stores touch memory, or arithmetic instructions can read and write memory too.
• Addressing modes: one simple way to form an address, or many.
• Condition codes: whether arithmetic sets flags that branches test, or branches compare registers themselves.
• Instruction complexity: only simple operations, or also complex ones such as copying a whole string in one instruction.

None of these has one right answer. Each trades the size of the program against the complexity of the hardware, and the balance depends on what is expensive at the time.

CISC: Doing More per Instruction

In the 1970s, memory was expensive and slow, and compilers were simple. An ISA that packed a lot of work into each instruction saved memory and let programmers, who often wrote assembly by hand, express a task in few lines. These complex instruction set computers (CISC), such as the DEC VAX, the Motorola 68000 and Intel's x86, had variable-length instructions, arithmetic that could read and write memory directly, many addressing modes, and powerful instructions for strings, loops and procedure calls.

Inside, such processors often executed each complex instruction as a sequence of simpler internal steps, stored in an on-chip ROM as microcode. The hardware stayed manageable, and new complex instructions could be added by writing more microcode.

RISC: Simple Instructions, Fast

By around 1980, researchers measuring real programs noticed that compilers used mostly the simple instructions, and that the complex ones were rare and often slower than an equivalent sequence of simple ones. At the same time, pipelining promised to start one instruction per cycle, but only if instructions were regular. The result was the reduced instruction set computer (RISC): fixed-length instructions with fields in fixed places, a load/store architecture, many registers (usually 32), three-operand arithmetic and simple addressing. The first RISC designs at Berkeley and Stanford led to SPARC and MIPS; IBM's work led to POWER; and Arm and, later, RISC-V followed the same principles. RISC-V itself grew out of the Berkeley RISC tradition.

The bet was that simpler instructions would let the hardware run faster and pipeline easily, and that a good compiler could make up for needing more of them. The Performance Equation gives the exact form of that trade: run time is instructions x cycles per instruction x clock period, and RISC accepts more instructions to lower the other two.

The Same Loop on x86 and RISC-V

Take a loop that adds up a 1,024-element array. Compiled with optimization for x86-64 (with automatic vectorization switched off, so that the loop stays one element at a time) and for RV32I, its inner loop is:

x86-64                                           RV32I
38:  03 10              add  (%rax),%edx         44:  00072783  lw   a5,0(a4)
3a:  48 83 c0 04        add  $0x4,%rax           48:  00470713  addi a4,a4,4
3e:  48 39 c8           cmp  %rcx,%rax           4c:  00f50533  add  a0,a0,a5
41:  75 f5              jne  38                  50:  fec71ae3  bne  a4,a2,44
     4 instructions, 11 bytes                         4 instructions, 16 bytes

The x86 loop shows several CISC traits at once. Its first instruction, add (%rax),%edx, reads memory and adds in a single 2-byte instruction, where RISC-V needs a load and an add. Its instructions are 2, 4, 3 and 2 bytes long; elsewhere in the same function they reach 7 bytes. Its arithmetic has two operands, with the result overwriting one of them. And its branch tests flags set by the cmp before it, where RISC-V's bne compares the registers itself.

Yet both loops have four instructions. x86 saves the separate load, RISC-V saves the separate compare. The real differences are in bytes and in how hard the instructions are to decode: the x86 decoder must find where each instruction ends before it can work on the next, while every RV32I instruction starts at a multiple of 4 bytes with its fields in the same places.

The Lines Have Blurred

Modern x86 processors do not execute x86 instructions directly. Their front end translates each one into simpler internal operations, usually called micro-operations, and the rest of the core is essentially a very large RISC-like machine. Arm, for its part, added compressed 16-bit instructions (Thumb) to improve code density, then designed its 64-bit ISA with fixed 32-bit instructions again. RISC-V keeps a fixed-length base but offers a compressed extension. The lesson of four decades is that both ends of the trade matter: simple, regular instructions for the hardware, and compact code for memory and caches.

Code Density and the C Extension

Code density is how much program fits in a given number of bytes. It matters wherever instruction memory is costly: in a microcontroller's flash, and in every processor's instruction cache, where denser code means more of the program fits and fewer fetches go to slower memory.

The RISC-V C extension gives the most common instructions an alternative 16-bit encoding. It is possible because those instructions often use only a few registers, small constants, or a destination equal to a source: addi a4, a4, 4 fits in 16 bits as c.addi, add a0, a0, a5 as c.add. Each 16-bit instruction expands to exactly one 32-bit instruction, so C adds no new operations. The same loop compiled for rv32ic:

34:  431c        lw    a5,0(a4)       16-bit
36:  0711        addi  a4,a4,4        16-bit
38:  953e        add   a0,a0,a5       16-bit
3a:  fec71de3    bne   a4,a2,34       32-bit (a branch between two registers has no 16-bit form)
     4 instructions, 10 bytes: smaller than the 11 bytes of x86 for this loop

In one test of six small programs, about half of the instructions got a compressed form, and the code shrank by a fifth to more than a quarter.

The price is paid in the processor's front end. Instructions are now aligned to 2 bytes instead of 4, so a 32-bit instruction can straddle two fetched words, and the fetch logic must collect its halves. The decoder needs an expander that turns each 16-bit form into its 32-bit equivalent. For small cores with tight flash budgets the trade is clearly worth it, which is why nearly every RISC-V microcontroller implements C.

What an Extension Costs

Extensions are optional because they cost hardware. The M extension's mul needs a multiplier. In one test, a 32 x 32-bit multiplier that returns the low 32 bits of the product, exactly what mul computes, was built from the same gate library as a small five-stage RV32I core.

That single-cycle multiplier came to about 22 percent of the core's area, roughly a fifth more hardware. A slower multiplier that takes several cycles would be smaller. Against that stands the gain: a matrix program needed about a third less code with M, and at run time each multiplication shrinks from a call into a shift-and-add routine of dozens of instructions to a single mul. For a program that multiplies constantly, the extension pays for itself many times over; for one that never multiplies, it is pure cost.

Designers can also choose a middle way. A multi-cycle multiplier that processes a few bits per cycle is much smaller and still far faster than the software routine. The ISA does not care: mul must give the right result, and how many cycles it takes is a microarchitecture decision. This is exactly the freedom described in What an ISA Defines.

Custom Extensions and the Limits of Adding

RISC-V reserves encoding space for custom instructions, so a company can add operations specific to its product without colliding with standard ones. A custom instruction can replace a hot loop of dozens of instructions with one, which is attractive for accelerating a particular algorithm. But every added instruction must be supported by the compiler, debugger and simulators, verified in every corner case, and kept forever if software depends on it. The history of CISC shows the risk: instructions added for one generation's needs remain a burden decades later. Good ISA design adds only what measurements show to be worth it.

Common Mistakes