Visual walkthrough — Instruction formats — R-type, I-type, J-type (MIPS - RISC-V)

Step 1 — What is a "32-bit number", really?

WHAT. A MIPS instruction is one row of 32 tiny on/off switches. Each switch is a bit — a single 0 or 1. Nothing more. The CPU has no idea what any switch means until we agree on a rulebook.

WHY start here. Because the whole problem of "instruction formats" is just: how do we carve this row of 32 switches into meaningful chunks? If we don't fix the carving in advance, the hardware cannot know whether switches 21–25 name a locker or spell part of a number.

PICTURE. Below: 32 empty boxes, numbered from bit 31 (left, most significant) down to bit 0 (right). This is the blank canvas every instruction is painted on.

Step 2 — The first question: "how many things can a chunk name?"

WHAT. Before carving anything, learn the one counting rule that governs every field width on this page: a chunk of $n$ bits can spell exactly $2^n$ different patterns.

WHY this tool and not another. We keep asking "how wide must this field be to name X different things?" The inverse of $2^n$ is the logarithm base 2, written ${\log }_2$. That's the tool: ${\log }_{2}X$ answers "how many bits do I need to name X items?" We use ${\log }_2$ (not division, not $\times$) because doubling the bits doubles the choices — a multiplicative, not additive, growth.

$n\text{ bits}⟶\underset{\text{patterns}}{\underbrace{2^n}}\text{and going backwards}n=\underset{\text{bits needed for }X\text{ things}}{\underbrace{\lceil {\log }_{2}X\rceil }}$

• $2^n$ — take a chunk of $n$ switches, count how many distinct 0/1 pictures it can show.
• ${\log }_{2}X$ — the reverse question: given that we must name $X$ things, how many switches?
• $\lceil \rceil$ — the "round up" brackets (a ceiling), because you can't have a fraction of a switch.

PICTURE. A staircase: 1 bit → 2 patterns, 2 bits → 4, 3 bits → 8… and the reverse arrow reading it as "to name 32 things, climb to 5 bits."

Step 3 — Reserve the master key: the opcode

WHAT. Slice off the top 6 bits and call them the opcode. This chunk's only job is to answer "which rulebook (format) does the rest of this instruction follow?"

WHY 6 bits, and why first?

• First — so the decoder can read it immediately, before it knows anything else, and pick the right rulebook. (See Control Unit and Decoding.)
• 6 bits — this is a design choice giving $2^6=64$ possible opcodes. That's a comfortable menu of operations while leaving 26 bits below for everything else. Remember 6; it never changes across the three formats.

$\underset{6\text{ bits}=2^6=64\text{ operation names}}{\underbrace{\text{opcode}}}$

PICTURE. The 32-box strip with the leftmost 6 boxes shaded blue and labelled "opcode → which rulebook?". The remaining 26 boxes are a gray "to be decided" region.

Step 4 — R-type: carve the 26 leftover bits for "three lockers + which math"

WHAT. We want instructions like add $t0,$s1,$s2 — read two registers, combine them, write a third. That needs to name three registers and say which combining operation.

WHY these exact widths — watch them fall out.

• Three register names. Each register (from Step 2) needs ${\log }_{2}32=5$ bits. Three of them = $3\times 5=15$ bits. Call them rs, rt (the two sources) and rd (the destination).
• A shift amount. Shift instructions (sll) can move a 32-bit word by 0–31 places → ${\log }_{2}32=5$ bits. Call it shamt.
• "Which math?" Because opcode was spent as 0, we need a second selector. We have $26-15-5=6$ bits left — exactly enough for $2^6=64$ R-type operations. Call it funct.

$\underset{6}{\underbrace{\text{opcode}}}\underset{5}{\underbrace{\text{rs}}}\underset{5}{\underbrace{\text{rt}}}\underset{5}{\underbrace{\text{rd}}}\underset{5}{\underbrace{\text{shamt}}}\underset{6}{\underbrace{\text{funct}}}$

Term by term: opcode = 0 announces "R-type"; rs, rt = the two source lockers to read; rd = the destination locker to write; shamt = how far to shift (0 for non-shift ops); funct = the real operation code. Add them: $6+5+5+5+5+6=32$. ✓ Nothing left over, nothing missing.

PICTURE. The strip fully carved into six colored fields with widths labelled, and a checksum "6+5+5+5+5+6 = 32" underneath.

Step 5 — I-type: trade two fields for one 16-bit number

WHAT. Now we want a constant baked in — addi $t0,$s1,10, lw $t0,32($s3), beq. We keep the opcode (6) and only need two registers now, but we need room for a number.

WHY the number is 16 bits. Start from R-type and merge the three trailing fields rd + shamt + funct = $5+5+6=16$ bits into a single immediate field. That's where 16 comes from — it's not chosen, it's the leftover after opcode + two registers:

$32-\underset{\text{opcode}}{\underbrace{6}}-\underset{\text{rs}}{\underbrace{5}}-\underset{\text{rt}}{\underbrace{5}}=16.$

$\underset{6}{\underbrace{\text{opcode}}}\underset{5}{\underbrace{\text{rs}}}\underset{5}{\underbrace{\text{rt}}}\underset{16}{\underbrace{\text{immediate}}}$

Term by term: rs = one source (for loads it's the base address); rt = now the destination for addi/lw (it receives the result), but a source for sw/beq; immediate = the 16-bit constant/offset. Because a constant can be negative (e.g. addi $t0,$t0,-1), the top bit of the immediate is a sign, copied leftward when used — that's Sign Extension and Immediates.

PICTURE. Two strips stacked: R-type on top, and I-type below with rd|shamt|funct shown collapsing (arrows) into one wide 16-bit "immediate" block.

Step 6 — The branch trick: how 16 bits reach far away

WHAT. beq $rs,$rt,LABEL must name a target address — but addresses are 32 bits and we only have 16 left. Deriving the escape.

WHY multiply by 4, and why relative. Two observations do all the work:

1. Every instruction is 4 bytes, so every instruction address is a multiple of 4 — its low 2 bits are always 00. Storing those two zeros is a waste. So the 16 bits count words (groups of 4 bytes), not bytes. Hardware shifts left by 2 (i.e. $\times 4$) to restore the bytes.
2. Branches jump nearby (loops, ifs), so instead of an absolute address we store a signed offset from the current spot — that's why the immediate is signed (positive = forward, negative = backward).

$\text{target}=\underset{\text{next instruction}}{\underbrace{(\text{PC}+4)}}+\underset{\text{signed, in bytes}}{\underbrace{(\text{imm}\times 4)}}$

• $\text{PC}+4$ — the address of the instruction after the branch (the CPU already advanced the program counter by 4).
• $\text{imm}$ — the 16-bit signed word offset; negative reaches backward.
• $\times 4$ — undo the "counted in words" saving, converting back to bytes.

Effective reach: 16 signed bits + 2 implied = 18-bit signed byte reach ($\pm 128$ KB). See PC-relative vs Absolute Addressing.

PICTURE. A vertical column of instruction addresses (…P, P+4, P+8…). An arrow from beq at P curves to P+4 + imm×4, with a forward (green) and backward (red) example.

Step 7 — J-type: spend almost everything on an address

WHAT. j LABEL needs no registers at all — just "go there." Keep the opcode (6), give the other 26 bits to the address.

WHY 26 can still reach a 32-bit target. Same two tricks, pushed harder:

• Low 2 bits are 00 (word-aligned) → append them, buying 2 bits for free.
• The top 4 bits are not stored — they're copied straight from the current PC. So a jump can only move within the same 256 MB region the PC is already in.

$\text{target}=\underset{\text{top 4 bits, borrowed}}{\underbrace{(\text{PC}+4{)}_{[31:28]}}}\Vert \underset{26\text{ stored bits}}{\underbrace{\text{address}}}\Vert \underset{2\text{ implied}}{\underbrace{00}}$

• $(\text{PC}+4{)}_{[31:28]}$ — the four high bits taken from the program counter (not from the instruction).
• $\Vert$ — "glue together" (concatenate) the bit groups.
• $\text{address}$ — the 26 bits we actually stored.
• $00$ — the two always-zero low bits, appended by hardware.

Count restored bits: $4+26+2=32$. ✓ Effective byte reach: $26+2=28$ bits (256 MB region).

PICTURE. A 32-bit target bar split into three colored zones — top 4 "from PC" (gray), middle 26 "stored" (blue), bottom 2 "implied 00" (orange) — with braces showing 4+26+2=32.

Step 8 — Degenerate & edge cases (never leave a gap)

WHAT / WHY. Check the corners so nothing surprises you later.

• nop = all zeros. 00000000...0 decodes as opcode 0 (R-type), funct 0 = sll $0,$0,0 — a shift of register 0 by 0. It does nothing, harmlessly. So the all-off instruction is legal.
• shamt = 0 for non-shift R-types. add, sub ignore shamt; it's simply zero. The field always exists even when unused.
• Immediate = 0. addi $t,$s,0 is a valid copy; beq $x,$y,0 targets the very next instruction ($P+4+0$).
• Negative immediate. Top bit of the 16-bit field = 1 means negative; it is sign-extended to 32 bits before use, so -1 becomes 0xFFFFFFFF. Forgetting this is the classic offset bug.
• Register 0. $zero (register number 0) always reads 0 and ignores writes — even if it lands in rd. See MIPS Register File and Conventions.

PICTURE. A small table-figure: each edge case as a row (nop, shamt=0, imm=0, imm<0, $zero), with its 32-bit strip and a one-word verdict (safe / sign-extend / no-op).

The one-picture summary

All three formats sharing the same top three fields (opcode, rs, rt live in identical positions) so the same wires feed the register file — that shared alignment is the whole point of RISC regularity. Below them, the divergence: R keeps three registers + funct, I merges the tail into a 16-bit number, J merges almost everything into a 26-bit address.

Flashcards