RISC-V, the ISA, the Privileged Spec, and the Vector Extension

01.Part 1, what an instruction set actually is

1.1 One 32-bit number, decoded by hand

Here is a number.

$\texttt{0xFEC30293}$

That is all a processor ever receives. Not an instruction in any human sense, just thirty-two bits fetched from memory. Everything the machine does next is a consequence of how those thirty-two bits are agreed to be carved up.

Write it in binary and group the bits the way RISC-V agrees to group them.

$\underbrace{\texttt{111111101100}}_{\text{bits }31{:}20}\ \underbrace{\texttt{00110}}_{19{:}15}\ \underbrace{\texttt{000}}_{14{:}12}\ \underbrace{\texttt{00101}}_{11{:}7}\ \underbrace{\texttt{0010011}}_{6{:}0}$

Now read it right to left, because that is the order the hardware cares about.

The bottom seven bits, 0010011, are the opcode. In RISC-V that value means "integer operation with an immediate operand." Bits 14:12, called funct3, are 000, which within that opcode means "add." Bits 11:7 hold 00101 $= 5$, the destination register, so the answer goes into x5. Bits 19:15 hold 00110 $= 6$, the first source register, so one operand comes from x6. And bits 31:20 hold a twelve-bit two's-complement number, 111111101100. As an unsigned value that is 4076. Interpreted as a signed twelve-bit number it is $4076 - 4096 = -20$.

So the whole instruction says: take the contents of x6, add $-20$, put the result in x5. Written the way an assembler writes it, addi x5, x6, -20.

Nothing about that carving is a law of nature. A different committee could have put the opcode at the top, made the destination register four bits, or used a fifteen-bit immediate. The carving is a decision, and the collection of all such decisions is an instruction set architecture.

1.2 The contract, and the two things it deliberately does not say

An instruction set architecture is the contract between the person who compiles a program and the person who builds the chip. It says exactly what state the programmer can see, which is the registers, the memory, and the privileged control state. It says exactly what each instruction does to that state. And it says exactly what the encoding of each instruction is, so that a compiler can emit bits and a decoder can read them back.

What it deliberately does not say is how fast anything is, or how it is built. Whether the add above takes one cycle or four, whether the machine is in-order or out-of-order, how many entries the branch predictor has, how wide the caches are, none of that is in the contract. All of it is microarchitecture, and every note from CPU Foundations Pipeline and Hazards onward in this set is about microarchitecture. This note is about the other thing, the contract, and it is worth being precise about the boundary because interviewers probe it constantly. "Is a store buffer part of the ISA?" No, but the memory ordering model that constrains what a store buffer is allowed to do is. That distinction is the whole of Part 4.

RISC-V made three structural choices about its contract that distinguish it from Arm A64 and from x86-64.

It is a small mandatory base plus optional extensions. The mandatory part, the base integer instruction set, is about forty instructions. Everything else, multiply, atomics, floating point, compressed encodings, vectors, bit manipulation, is separately specified and separately optional. Arm A64 and x86-64 both have a large mandatory core.

It is open and royalty-free, with a governed specification. Anyone may implement it without a license. That is the reason six different companies in one job search are building competing cores against the same document, which is a situation with no parallel in Arm or x86.

It is split across several documents rather than one manual. The unprivileged specification, formerly called the user-level ISA, defines the base and the unprivileged extensions. The privileged specification defines privilege modes, traps, control registers, and address translation. Separate documents define the Debug Specification, the Advanced Interrupt Architecture, and the profiles. When an interviewer says "the spec," ask which one. The split is real and the two main volumes are versioned independently.

1.3 The naming string, decoded

An implementation announces which parts of the contract it honors with a string. Decode one.

RV64GC

RV is RISC-V. 64 is XLEN, the width of an integer register in bits, so this is a machine with 64-bit registers. G is a shorthand meaning IMAFD plus Zicsr and Zifencei, the set that a general-purpose operating system expects. C is the compressed instruction extension. Expanded, RV64GC is RV64IMAFDC_Zicsr_Zifencei. The underscores are not decorative, because the naming convention requires one before every multi-letter extension and a toolchain will reject the string without them.

The individual letters are covered in Part 3. What matters here is that the string is the entire statement of what the hardware implements. There is no equivalent of "Armv8.2-A" as a single monolithic version number that pulls in a fixed bundle. You name each piece.

1.4 The problem that modularity created, and profiles

Modularity is wonderful for a microcontroller. A deeply embedded core can implement RV32I alone, roughly forty instructions, with no multiplier, no floating-point unit, no CSRs, and no address translation, and it is a legal RISC-V machine.

Modularity is a disaster for a Linux distribution. If every vendor picks a different subset, there is no single binary that runs everywhere, and the software ecosystem fragments into per-vendor builds. That is exactly the failure mode that made early Arm Linux painful and that RISC-V, being far more modular, would have suffered far worse.

The fix is a profile, which is a named bundle that says "if you claim this profile, you implement all of these extensions." RVA23U64 is the current application-class user-mode profile, and the change that matters most is that the V vector extension is mandatory in it, where it had been optional in the previous RVA22U64. Zicond for branchless conditional moves and the Zba, Zbb, Zbs bit-manipulation extensions are also mandatory. Zbc, carry-less multiply, is an option rather than a requirement.

Saying that sentence in an interview is worth more than it looks, because it demonstrates you understand that the ISA's headline virtue, modularity, has a real cost, and that the community had to build a second mechanism to contain it.

---

02.Part 2, the base integer ISA and why it is shaped this way

2.1 Thirty-two registers, and one of them is zero

RV64I gives the programmer 32 integer registers, named x0 through x31, each 64 bits wide, plus a program counter. x1 through x31 are ordinary read-write registers. x0 is different. It is hardwired to zero. Reads of x0 always return 0. Writes to x0 are discarded.

Start with why thirty-two, because the answer is arithmetic rather than taste. A register specifier for 32 registers needs $\log_2 32 = 5$ bits. The most demanding instruction format names three registers, two sources and one destination, so that is 15 bits. The opcode is 7 bits and the funct3 field is 3 bits, which is 25. The remaining 7 bits become funct7. Total:

$3 \times 5 + 7 + 3 + 7 = 32$

The register count and the instruction width fit each other exactly. Going to 64 registers would need 18 bits of specifier and would leave only 4 bits for funct7, which is not enough to encode the arithmetic operations. Going to 16 registers would waste encoding space and hurt the compiler. Thirty-two is the number that makes a three-address 32-bit instruction word come out even.

Now x0. Hardwiring one register to zero looks like throwing away a register, and it is, but it buys a startling amount. A large fraction of what other architectures need dedicated instructions for falls out of x0 for free:

Every one of those would otherwise need its own opcode. x0 also removes the need for a "suppress the write" bit in the encoding, because writing to x0 is the suppression, which matters for instructions executed only for their side effects.

There is a microarchitectural consequence worth naming, because it is a good interview detail. In a register-renaming machine, per Out of Order Execution, x0 never needs a physical register or a rename table entry. The rename stage special-cases it. And an addi x0, x0, 0 can be killed at decode rather than allocated a reorder-buffer slot, though whether an implementation bothers is its own choice.

Arm A64 does something related but not identical. It has 31 general registers plus a special encoding in the 32nd slot that means either the zero register XZR or the stack pointer SP, depending on the instruction. RISC-V's version is cleaner. x0 is zero everywhere, and the stack pointer is just x2 by software convention with no architectural meaning at all.

2.2 The decision everything else bends around: register fields never move

Look again at the decode in 1.1. rs1 came from bits 19:15 and rd from bits 11:7. Here is the rule that shapes the entire encoding:

In every RISC-V instruction format that has an rs1, it is at bits 19:15. In every format that has an rs2, it is at bits 24:20. In every format that has an rd, it is at bits 11:7.

They never move. Not for loads, not for stores, not for branches, not for jumps.

Why this is worth a whole subsection is a timing argument, and it is the argument a logic designer will find most natural. Consider what the decode stage must do in one cycle. It must work out what the instruction is, and it must get the source operands out of the register file so that execute can use them next cycle.

If the register specifier's position depended on the opcode, the sequence would be serial: decode the opcode, then use the decoded opcode to select which instruction bits are the register number, then drive that number into the register file's address decoder, then read the array. From Digital Logic and Timing and SRAM Arrays and ECC, the register-file read itself is already a significant fraction of a cycle. Putting an opcode decode and a 5-bit mux in front of it is exactly the kind of serial chain that does not fit.

Because the fields never move, the sequence is parallel instead. At the instant the instruction word arrives, bits 19:15 and 24:20 are driven straight into the register file address decoders with zero logic in between. The opcode decode happens at the same time, off to the side, and its result is needed only later, to decide what to do with the values that came back. The register file read starts at $t = 0$ of the decode cycle.

Put a rough number on it. At 3 GHz the cycle is 333 ps. A 5-bit 4-to-1 mux plus the opcode decode that controls it is easily 60 to 80 ps in a typical library. Removing that from the front of the register-file read recovers a fifth of the cycle. That is not a rounding error. That is the difference between closing timing and re-pipelining decode into two stages.

Now the consequence, and it is the whole point of the next subsection. If rs1, rs2, and rd are nailed to fixed bits, then the immediate has to live in whatever bits happen to be left over. Different instruction kinds have different leftovers. A store has no rd, so bits 11:7 are free. A branch has no rd either but needs a larger reach. A jump has no rs1 or rs2, so bits 24:15 are free too. The immediate is scrambled because the register fields refused to move.

2.3 The six formats, and three instructions decoded by hand

RISC-V has six base instruction formats. Rather than list them abstractly, decode one instruction of each of the three interesting kinds and let the pattern emerge.

An I-type, already done. addi x5, x6, -20 is 0xFEC30293. The twelve-bit immediate sits in one contiguous piece at bits 31:20.

An S-type. sw x7, -20(x6) stores the word in x7 to the address x6 - 20. This instruction needs two source registers, x6 for the address base and x7 for the data, and it has no destination register. Since rs1 must be at 19:15 and rs2 at 24:20, the twelve-bit immediate cannot fit above rs2 any more. Only bits 31:25 are left up there, which is seven bits. The other five go into bits 11:7, the slot a destination register would have used.

$\underbrace{\texttt{1111111}}_{imm[11{:}5]}\ \underbrace{\texttt{00111}}_{rs2 = 7}\ \underbrace{\texttt{00110}}_{rs1 = 6}\ \underbrace{\texttt{010}}_{\text{SW}}\ \underbrace{\texttt{01100}}_{imm[4{:}0]}\ \underbrace{\texttt{0100011}}_{\text{STORE}} = \texttt{0xFE732623}$

Check the immediate. Splice 1111111 and 01100 back together and you get 111111101100, which is $-20$ again, the same twelve-bit value as before. The immediate was cut in two, but neither half was moved or rotated. Bits imm[11:5] are still at instruction bits 31:25, exactly where imm[11:5] was in the I-type.

A B-type. beq x5, x6, -20 branches back 20 bytes if x5 equals x6. Branch targets are always even, because instructions are two-byte aligned at worst, so the low bit of the offset is always zero and there is no reason to encode it. That frees one bit, so a B-type carries a thirteen-bit signed offset in twelve encoded bits, giving a reach of $\pm 4$ KiB rather than $\pm 2$ KiB.

Write $-20$ as a thirteen-bit two's-complement number: 1111111101100. So $imm[12] = 1$, $imm[11] = 1$, $imm[10{:}5] = \texttt{111111}$, $imm[4{:}1] = \texttt{0110}$, and $imm[0] = 0$ by construction. The encoding is

$\underbrace{\texttt{1}}_{imm[12]}\ \underbrace{\texttt{111111}}_{imm[10{:}5]}\ \underbrace{\texttt{00110}}_{rs2}\ \underbrace{\texttt{00101}}_{rs1}\ \underbrace{\texttt{000}}_{\text{BEQ}}\ \underbrace{\texttt{0110}}_{imm[4{:}1]}\ \underbrace{\texttt{1}}_{imm[11]}\ \underbrace{\texttt{1100011}}_{\text{BRANCH}} = \texttt{0xFE6286E3}$

This is where it looks insane. $imm[11]$ has been yanked out of its natural place and stuffed into instruction bit 7, and $imm[12]$ sits alone at bit 31. Compare against the S-type: $imm[10{:}5]$ is at instruction bits 30:25 in both, and $imm[4{:}1]$ is at instruction bits 11:8 in both. The only bits that moved are the two ends. That is not an accident, and 2.4 is the reason.

Here are all six formats drawn together. Read it as a picture of which instruction bits each format claims.

Read down the columns rather than across the rows and the design becomes visible. The rs1 column at bits 19:15 is teal in R, I, S, and B. The rs2 column at 24:20 is teal in R, S, and B. The rd column at 11:7 is teal in R, I, U, and J and amber in S and B, meaning the immediate stole exactly the field that was not needed. And bit 31 is amber in every single format that has an immediate at all.

2.4 Why the immediate is scrambled, from first principles

This is a classic interview question and it has a precise answer that most candidates get half right. The half most people give is "the sign bit is always at bit 31." That is true and it is one of three constraints. Here are all three, and then the arithmetic that shows what they are worth.

Constraint one: the sign bit is always instruction bit 31. Every RISC-V immediate is sign-extended to XLEN bits. Sign extension means replicating the top bit of the immediate across all the bits above it. In a 64-bit machine an I-type's twelve-bit immediate must be replicated into bits 63 down to 12, which is 52 copies of one wire. If the sign bit lived at a different instruction bit depending on the format, you would need a mux in front of that 52-way fanout, and that mux would sit at the head of the longest fanout in the decoder. By pinning the sign bit to instruction bit 31 in every format, the fanout driver's input is a single wire with no logic in front of it, so sign extension proceeds in parallel with the opcode decode instead of after it.

Constraint two: an immediate bit should come from as few different instruction bits as possible. The decoder ultimately produces one 64-bit immediate value regardless of format. Think of that as a function from instruction bits to immediate bits. In the worst imaginable design, any immediate bit could come from any instruction bit, and you would need a 32-to-1 multiplexer for each of 32 immediate output bits. RISC-V instead arranged that most immediate bits have only one possible source, and none has more than four.

Constraint three: never shift. Branch and jump offsets are in units of two bytes, so encoding them requires multiplying by two, which in hardware is a shift by one. A shift by a constant is free if you do it by wiring, and expensive if you do it with logic. RISC-V does it by wiring. The B and J formats place their immediate bits so that $imm[1]$ lands in the instruction bit that an I-type would use for $imm[1]$, and so on. The spec's own rationale states that rotating the bits in the B and J encodings, rather than using dynamic multiplexers to multiply the immediate by two, reduces instruction signal fanout and immediate multiplexer cost by roughly a factor of two.

Now the table that makes all three visible at once. For each output immediate bit, this is where it comes from in each format.

Count the rows carefully, because the shape of the distribution is the answer. One row, $imm[31]$, has a single source and needs no mux at all. Five rows need only a 2-to-1 or a 3-to-1. And one single bit, $imm[11]$, needs a 4-to-1. Everything above bit 31 is sign extension driven from that same one wire.

Count the two-input muxes that implies. A 3-to-1 costs two 2-to-1s and a 4-to-1 costs three.

$\underbrace{11 \times 1}_{imm[30:20]} + \underbrace{8 \times 1}_{imm[19:12]} + \underbrace{1 \times 3}_{imm[11]} + \underbrace{6 \times 1}_{imm[10:5]} + \underbrace{4 \times 2}_{imm[4:1]} + \underbrace{1 \times 2}_{imm[0]} = 38$

Thirty-eight two-input multiplexers. Compare against the naive alternative where any of 32 immediate bits could come from any of 32 instruction bits, which is $32 \times 31 = 992$ two-input muxes. That is a factor of roughly 26 in area, and, more importantly, the depth falls from five levels of mux to at most two. At 3 GHz, five levels of 2-to-1 mux at perhaps 25 ps each is 125 ps of a 333 ps cycle spent on nothing but shuffling immediate bits. Two levels is 50 ps. Those gate counts are illustrative rather than taken from a real library, but the ratio is the point and the ratio is robust.

One honest caveat to add unprompted when you give this answer. The saving is real but it is a saving in the simplest implementations. A wide out-of-order machine that decodes six instructions per cycle has six immediate generators, so the area saving multiplies, but that machine also has separate dedicated adders for branch targets and load addresses and would not have been limited by an immediate mux anyway. The design was optimized for the cheap end of the range and costs the expensive end essentially nothing. Saying that shows you understand who the optimization was for.

The cost the design pays is entirely on the software side. A human reading a hex instruction dump has to reassemble a branch offset from four scattered pieces, and an assembler, a disassembler, and a linker relocation all have to implement the scramble. That is a one-time software cost paid by a handful of tool authors against a per-chip hardware saving paid by every implementer, which is the trade the committee made deliberately.

2.5 No condition codes, and what that costs

Here is how Arm A64 branches on a comparison.