Visual walkthrough — Instruction formats and encoding

We assume you can count in binary and nothing else. If a word like "opcode" or "register" is fuzzy, the Instruction Set Architecture (ISA) and Registers and the Register File notes are the ground floor.

Step 1 — The empty ruler: 32 slots waiting to be filled

WHAT. A CPU that uses fixed-length encoding grabs exactly the same number of bits every time it fetches an instruction. RISC-V grabs 32 bits. So picture a ruler with 32 slots, each slot holding one 0 or one 1.

WHY start here. Before deciding what goes where, we must agree on how much room we have. Fixed width means the total budget never changes — so every field we invent must be carved out of these same 32 slots. Nothing can spill over.

PICTURE. The ruler below is numbered slot 0 on the far right up to slot 31 on the far left. That right-to-left counting matters: slot 0 is the "least significant" bit, the way the 1s digit sits on the right of a normal number.

Step 2 — Reserve the opcode first, and pin it to the right edge

WHAT. The first field we place is the opcode — the "what job to do" field. RISC-V gives it 7 bits, and it lives in positions 0–6 (the rightmost 7 slots).

WHY 7 bits, and WHY the right edge?

• Why 7: we want to name roughly a hundred-plus operation classes. To name $N$ different things you need $b=\lceil {\log }_{2}N\rceil$ bits, because $b$ bits can spell $2^b$ distinct patterns. With $2^7=128$ patterns we comfortably cover $>100$ classes. Six bits ($2^6=64$) is too few.
• Why the right edge: the decoder must find the opcode first, before it knows which format this even is. If the opcode always sits in the same fixed slots, the decode hardware can be a single fixed wire tap — no searching. Pinning it to positions 0–6 is a promise every format keeps.

PICTURE. The 7 orange slots on the right are now claimed. 25 slots remain white.

Reading the annotation: the brace spans 7 slots; the label says these 7 bits answer which operation class. This is the Instruction Decode Stage's very first question.

Step 3 — An R-type needs three registers: 5 bits each, why exactly 5

WHAT. An R-type instruction like add x5, x6, x7 names three registers: a destination rd and two sources rs1, rs2. RISC-V has 32 registers, so each register field needs $\lceil {\log }_{2}32\rceil =5$ bits. Three fields cost $5\times 3=15$ bits.

WHY 5, shown concretely. With 5 bits you can spell $2^5=32$ patterns — 00000 through 11111 — exactly one per register x0…x31. Four bits would give only 16 names, half the register file unreachable; six bits would waste a slot on every register field (and we have three of them — 3 wasted slots we can't afford).

PICTURE. Below, one 5-bit field is expanded into its 32 possible codes so you can see that 32 registers fit with zero waste and zero shortfall — the number $2^5$ landing exactly on 32.

Term by term: rd = destination register (where the answer is written); rs1, rs2 = the two source registers being read. See Registers and the Register File for what these numbers actually select.

Step 4 — Placing the three registers around the fixed opcode

WHAT. We slot the three register fields into the ruler, keeping the opcode untouched on the right. RISC-V's chosen positions are: rd in bits 7–11, then funct3 (coming in Step 5) in 12–14, then rs1 in 15–19, then rs2 in 20–24.

WHY this arrangement (the deep reason). The magic constraint is that rs1 and rs2 occupy the same bit positions in every format that has them. Register-read is on the critical timing path — the CPU wants to start reading registers immediately, even before decode fully finishes. If rs1 is always bits 15–19, the wires feeding the register file are hard-wired and never re-routed. This is the single most important design decision in the whole format family, and it echoes through Pipelining where early register-read overlaps with decode.

PICTURE. Watch the register fields fill the ruler while the orange opcode stays frozen on the right.

Running tally so far: $7(\text{opcode})+5+5+5(\text{three regs})=22$ bits used, 10 slots left.

Step 5 — The two funct fields: telling twins apart with the last 10 slots

WHAT. add and sub want to share the same opcode (both are "reg-reg arithmetic"), so we need extra selector bits to distinguish them. RISC-V uses a 3-bit funct3 (positions 12–14) and a 7-bit funct7 (positions 25–31). That's the final $3+7=10$ bits.

WHY split the selector into 3 and 7 instead of one 10-bit field? Because funct3 sits in a spot that also exists in the I-type and S-type formats, letting those formats reuse it as a sub-selector without moving anything. The 7-bit funct7 lives in the top slots that immediate-carrying formats spend on their number instead. Splitting lets each format repurpose the leftover holes — the same trick that later lets S-type and B-type split their immediate across scattered gaps.

PICTURE. The last 10 slots fill: 3 violet in the middle-left of the low half, 7 magenta on the far left. The ruler is now completely full.

Each brace is a field; the number under it is its bit-width. Read left-to-right (high position → low position), exactly how the picture stacks them.

Step 6 — Fill it with a real instruction: add x5, x6, x7

WHAT. Now we encode — turn a human instruction into the 32 actual bits. For add x5, x6, x7: opcode = 0110011, funct3 = 000, funct7 = 0000000, rd = 5, rs1 = 6, rs2 = 7.

WHY these numbers. Convert each register number to 5-bit binary because each register slot is 5 wide: $5=00101$, $6=00110$, $7=00111$. The opcode/funct values are fixed constants the RISC-V manual assigns to "add".

PICTURE. Each slot of the ruler now shows its final 0 or 1, colour-coded by field, with the human field values written above.

Reading each brace: the bits under rs2 spell 7, under rs1 spell 6, under rd spell 5 — precisely the registers we named, sitting in their permanent homes.

Step 7 — The degenerate case: what if a field needs to shrink or vanish?

WHAT. Not every instruction has three registers. addi x1, x2, 100 has only two registers plus a number (an immediate). So the I-type format deletes rs2 and funct7 (that's $5+7=12$ slots) and glues those slots together into one 12-bit immediate in the top positions.

WHY this is a "degenerate" case worth its own step. It's the boundary where the R-type template bends: same opcode position, same rd/funct3/rs1 positions — but the right-hand structure collapses. Seeing which fields stay put and which get absorbed is the key to reading every other format (S, B, U, J). The invariant survives: opcode, rd, funct3, rs1 never move.

PICTURE. The R-type ruler on top, the I-type ruler below it, aligned — so the 12 slots that were rs2 + funct7 visibly merge into one immediate block, while the four shared fields line up column-for-column.

The one-picture summary

Everything above, compressed: the empty 32-slot ruler on top; the requirements that carve it (opcode → 3 registers → 2 funct selectors) as arrows pointing down; the finished R-type layout in the middle with widths $7-5-5-3-5-7$; and the I-type variant at the bottom showing rs2 + funct7 merging into the immediate while the four anchor fields hold their columns.

Active recall