An opcode becomes control lines
How an instruction turns into action
Decoding an instruction is a table lookup from its opcode to the exact set of enable, load, and function control lines to raise, so the control unit is simply a mapping from each opcode to one row of control signals.
Builds onMachine code
You have seen machine code: each instruction is an opcode (what to do) plus an operand (what to do it to). And you have seen a datapath full of control lines (enables, loads, an ALU function select). The next lesson, the control unit, connects them. This bridge answers the mystery in the middle: how does a *number* (an opcode) turn into the *right set of raised wires*?
The gap feels big because an opcode looks like passive data (just a byte in memory) while control lines are active hardware (they make registers load and the ALU compute). It seems like something intelligent must "interpret" the opcode. Nothing intelligent is needed. The insight: the mapping from opcode to control lines is a fixed table, decided once at design time. Decoding is nothing more than looking up which row of that table the current opcode names.
The control table
Imagine a grid: one row per opcode, one column per control line. Each cell is a
0 or 1 saying whether that line is raised for that instruction. To "decode" LOAD you go to the LOAD row and read across: raise the line that puts memory on the bus, raise the accumulator's load, leave the ALU function at pass-through, and so on. ADD is a different row with a different pattern (raise the ALU's add function, drive the operand onto the other ALU input). The opcode is just the row index.That is why the control unit is often literally built from a decoder (turn the opcode into a one-of-N "this instruction" line) feeding a small array of OR gates or a ROM whose stored words *are* the rows of the table. There is no interpreter; there is a wired-in lookup. A worked example in our ISA: the
LOAD opcode selects its row, whose raised lines route a RAM byte onto the bus and clock it into the accumulator. Same hardware, different row, and the machine does something else entirely.A concrete analogy: a hotel front desk with a board of room switches. A guest hands over a key card encoded with a room number (the opcode). The desk does not reason about it, it uses the number to flip exactly the switches for that room (unlock this door, turn on that light). The card is just an index into a fixed board of actions. An opcode indexes a fixed board of control lines the same way.
The operand is not decoded into control lines the way the opcode is. The opcode picks *which* control pattern to raise; the operand is data (usually an address) that flows through the datapath the pattern sets up. Confusing the two, trying to "decode" the operand into control signals, is a classic misunderstanding. Decode the opcode; route the operand.
Check yourself
Explain, without any notion of a program "understanding" instructions, how the single opcode
ADD causes the ALU to add and the result to be stored.Answer
The
ADD opcode selects its row in the fixed control table. That row has 1s in exactly the columns needed: raise the enable that drives the operand onto one ALU input, set the ALU function-select lines to "add", and raise the accumulator's load so it captures the result. It is pure lookup, the opcode indexes a row, the row's 1s are the wires raised. No interpretation, just a wired-in table.Frequently asked
How does a CPU turn an opcode into actions?
Through a fixed lookup table with one row per opcode and one column per control line. Decoding an instruction means selecting its row and raising the control lines marked
1 in it. The control unit is built as a decoder plus gates or a ROM that implements this table, so no interpretation is needed.What is instruction decoding?
Instruction decoding is mapping an instruction's opcode to the exact set of enable, load, and function-select lines the datapath must raise to carry it out. It is a table lookup: the opcode is the row index, the control-line settings are the row.
What is the difference between an opcode and an operand in decoding?
The opcode selects which control-line pattern (which table row) to raise; the operand is data, usually an address, that flows through the datapath that pattern configures. Only the opcode is decoded into control signals; the operand is routed as data.
With "decode = pick a row of control lines" in hand, the control unit lesson builds that table into real gates, and the datapath finally runs whole instructions.
Every lesson here builds toward one thing: a working CPU, from the transistor up.
Open the free lab →