loading…
CPU and FDE: SL / HL · Pipelining: HL
Write a little program, assemble it into memory, then step through the fetch-decode-execute cycle and watch each register and bus do its job. Read the theory
Assembly code
An operand like x is a label. A label can be attached to any line, often a DAT data cell, and the assembler turns labels into addresses.
Input
Load a program first. INP is what reads input.
Output
RAM
Program ready.
Holds the address of the next instruction to be fetched. Fetch advances it by one memory cell in this machine; a taken branch replaces it.
No write to this register in the retained history.
Explore two separate system models. They do not read or change your assembly program above. The cache example has one CPU reader; the core comparison has independent tasks.
Choose an address to read its value. The CPU checks L1 first, then checks the next level only after a miss. A hit supplies the value without reading RAM.
L1
Not checked2 words · lookup +1 unit
L2
Not checked4 words · lookup +3 units
L3
Not checked6 words · lookup +8 units
RAM
Not read8 words · lookup +30 units
All caches are empty. Read an address, then read it again to compare the cost.
Each cache entry holds one word and its address. Any address can occupy any entry (fully associative). A full level replaces its least recently used entry. A hit refreshes that level; missed levels receive a copy. Levels not checked keep their order.
This example is inclusive: L1 entries also exist in L2, and L2 entries also exist in L3. Evicting a lower-level entry invalidates any upper-level copies. Actual processors use different capacities, policies and sharing arrangements.
The lookup costs are invented teaching units, added in sequence. They are not nanoseconds or clock cycles. Refill time, overlapping requests, multiword cache lines and memory writes are outside this read-only model.
Registers hold the CPU's immediate working values. RAM holds active programs and data and loses its contents when power is removed. ROM retains contents without power and typically holds firmware; it is not another cache level.
Both machines square the same six inputs: 2, 3, 4, 5, 6, 7. Each task takes two work units on one core and uses no other task's result. At every step, each core advances its own task by one unit.
One core
0/6 tasks completeCore 1
Ready
0 work units elapsed.
Two cores
0/6 tasks completeCore 1
Ready
Core 2
Ready
0 work units elapsed.
Step 0: one core has completed 0 tasks; two cores have completed 0 tasks.
This is ideal task parallelism with equal-speed cores and no scheduling or communication overhead. A dependent or uneven workload can gain less from a second core. These work units are not instruction cycles. Pipelining overlaps stages within a core; multiple cores can each run their own pipeline. The pipeline activity models those stages separately.
A GPU provides many processing units suited to doing similar operations across large collections of data, such as pixels or matrix elements. CPUs handle general-purpose control and a wide range of tasks; a CPU can coordinate work sent to a GPU. Data transfer and coordination have costs, so a GPU does not make every program faster. This page explains that role without simulating GPU execution.
A1.1.6 HL, pipelining
One instruction at a time leaves parts of the CPU waiting while another stage works. A pipeline starts the next instruction before the last one finishes, so the units stay busy. Same five instructions, same clock, two machines. Here each stage takes one clock cycle. The CPU counter above counts completed instructions, including HLT, so its unit is different.
Prediction: five instructions, four stages. Pipelined, how many clock cycles?
One instruction at a time
waiting for the clock
Pipelined
waiting for the clock