Anatomy of a CPU

assembly1-1 ended its own assemble-link-run pipeline with a shrug: "CPU execution takes over from there." This chapter opens that shrug up completely. Before writing a single real LC-3 instruction, you need to know what's actually sitting inside the box that's about to run it — the handful of components every CPU is built from, and the repeating loop, the fetch-decode-execute cycle, that those components run together to make anything happen at all.

The Building Blocks of a CPU

Strip away the marketing and a CPU is a small number of cooperating parts, each with one job:

None of these components do anything meaningful on their own. What makes a CPU a CPU is the specific, repeating sequence in which they hand work off to each other — which is exactly what the rest of this chapter walks through.

Buses — How Parts Talk to Each Other

A bus is nothing more exotic than a shared set of wires that one component can put a value onto, and another component can read a value off of. LC-3's design (and most simple CPUs) uses three logically distinct buses:

• Address bus — carries a memory address: "I want to read or write this location."
• Data bus — carries the actual value being read from or written to that address.
• Control bus — carries signals like "this is a read" or "this is a write," coordinating when the other two buses' contents are valid.

Two registers act as the CPU's staging area for talking to memory over these buses: the MAR (Memory Address Register) holds the address about to go out on the address bus, and the MDR (Memory Data Register) holds the value coming back on the data bus. You'll see both of these by name in the very next section.

The Fetch-Decode-Execute Cycle, Step by Step

Every single instruction a CPU ever runs — no matter how simple or complex — passes through the same repeating cycle. LC-3 breaks it into six phases, though not every instruction needs all six:

1. Fetch — MAR ← PC; the value at that address is read from memory into MDR; MDR's contents are copied into the IR; and PC is incremented so it's already pointing at the next instruction.
2. Decode — the control unit examines the opcode bits sitting in the IR and determines exactly which operation this instruction represents, and which other registers or memory locations it will need.
3. Evaluate Address (only for instructions that reference memory) — computes the actual memory address the instruction needs, using one of the addressing modes assembly1-3 covers in full.
4. Fetch Operands (only if needed) — reads whatever values the instruction needs from the register file or from memory, using the address computed in the previous phase.
5. Execute — the ALU actually performs the operation (addition, AND, NOT, and so on).
6. Store Result — the result gets written back to wherever it belongs: a register, or a memory location.

Tracing a Real Instruction: ADD R1, R0, R2

Take the exact instruction from assembly1-1's own pipeline example. This is a register-only instruction — it never touches memory for its operands — so phases 3 and 4 are skipped entirely:

; Fetch
MAR <- PC              ; address of this instruction
MDR <- mem[MAR]         ; the instruction's bits
IR  <- MDR
PC  <- PC + 1           ; PC now points past this instruction

; Decode
control unit reads IR's opcode bits -> "this is ADD, register mode"

; Evaluate Address  -- SKIPPED, ADD (register mode) never touches memory
; Fetch Operands
read R0 and R2 from the register file

; Execute
ALU computes R0 + R2

; Store Result
write the ALU's result into R1

Now contrast that with a memory-referencing instruction like LD R1, VALUE (also from assembly1-1's own example). Fetch, Decode, Execute, and Store Result all still happen — but this time Evaluate Address and Fetch Operands aren't skipped: Evaluate Address computes the actual memory address VALUE refers to, and Fetch Operands reads the value sitting at that address into MDR before it's written into R1. assembly1-3 picks this exact distinction back up when it covers addressing modes in full.

Hands-On Exercises