Picture a single lightbulb. It is dark or lit — no in-between. That "dark-or-lit" is one bit of information.
Why the topic needs it: the parent note keeps saying "the CPU only sees a 32-bit number." A "32-bit number" is just 32 of these switches sitting in a row. If you don't feel what one switch is, the whole row is a mystery.
If one switch holds 2 possibilities (0 or 1), then a row of switches holds many. To read a row as an ordinary number, we give each switch a place value — exactly like the ones/tens/hundreds columns you already use, except each column is worth twice the one to its right instead of ten times.
Why the topic needs it: every field in an instruction (opcode, register number, immediate) is a small binary number packed into a few switches. Encoding add $t0,...is turning register names into these little binary numbers.
The single most-used fact in this whole chapter is:
Why the topic needs it — and why log2 and not some other tool: the parent asks "why is a register field 5 bits?" The honest answer is a counting question — "how many switches do I need to give 32 registers each their own pattern?" The tool that inverts "n switches → how many patterns" is exactly the base-2 logarithm: log232=5. We use log2 (not log10) because each switch doubles, and doubling is base 2. This one formula justifies 5-bit register fields, 5-bit shamt, and 6-bit funct (26=64 operations).
MIPS has 32 such lockers, numbered 0–31. The whole set is the register file.
Programmers also give lockers nicknames ($t0, $s1, …) so code reads nicely. The number and the nickname are the same locker — see MIPS Register File and Conventions.
Why the topic needs it: R-type and I-type instructions spend most of their switches naming lockers. add $t0,$s1,$s2 is "take locker 17, locker 18, add them, store in locker 8."
Crucially, not every field appears in every instruction. Each format (R, I, J) is one particular way to snap the same 32-bit bar, and the fields always sum to exactly 32. The table below shows, per format, which pieces exist:
Format
Fields (left → right, MSB first)
Widths
Sum
R-type
opcode · rs · rt · rd · shamt · funct
6+5+5+5+5+6
=32
I-type
opcode · rs · rt · immediate
6+5+5+16
=32
J-type
opcode · address
6+26
=32
And the plain meaning of each individual piece:
Field
Width
Plain meaning
Used in
opcode
6
the "which rulebook" code word
R, I, J
rs
5
a source locker number
R, I
rt
5
source (R) / destination (I) locker
R, I
rd
5
destination locker number
R only
shamt
5
shift amount (how far to slide bits)
R only
funct
6
which R-type math, when opcode = 0
R only
immediate
16
a constant / offset baked in
I only
address
26
a jump target (partial)
J only
Why the topic needs it: a "format" (R/I/J) is literally a choice of how to cut the bar into fields. That is the entire subject.
The 16-bit immediate must be able to be negative (e.g. jump backwards, subtract a constant). Computers store negatives using two's complement: the top bit carries a negative place value.
Why the topic needs it:beq offsets and addi constants can be negative, so before the ALU adds them they get stretched to 32 bits keeping their sign. Without sign extension, "go back 3 instructions" would look like a huge positive jump forward.
Instructions are stored on word-aligned addresses: every instruction sits at a byte address that is a multiple of 4 (0, 4, 8, 12, …). In binary, "multiple of 4" means the bottom 2 bits are always 00.
Why the topic needs it: this is the trick behind target = (PC+4) + imm×4 and the J-type reconstruction. See PC-relative vs Absolute Addressing for how branches count from PC+4.
Why the topic needs it: branch and jump targets are measured relative toPC+4. If you don't know PC advances by 4 each step, formulas like (PC+4)+imm×4 are meaningless.
Everything on the left is equipment. The three format boxes (R, I, J) are defined and encoded in the parent topic; this page only supplies the alphabet they are written in.
