Computer Organization & Architecture

What is a computer, really?

Before registers and pipelines mean anything, start with the one idea underneath all of them - a machine built from switches that only ever does exactly what it's told.

Binary, decimal and hexadecimal - counting with different amounts of fingers

Why computers count in binary, how place value math actually works, and how to freely convert between binary, decimal and hex by hand.

How does binary represent negative numbers?

There are no minus signs inside a computer. Here's how two's complement lets addition hardware handle negative numbers for free.

How does binary store 3.14? Floating point, BCD and character codes

Two's complement only handles whole numbers. Here's how computers represent fractions using scientific notation in binary, plus the smaller codes worth knowing - BCD, ASCII and parity bits.

Logic gates - teaching switches to make decisions

How a handful of transistors combine into AND, OR and NOT gates, and how Boolean algebra lets you calculate with true/false the same way you calculate with numbers.

Building an adder - combinational circuits from gates

Wire a handful of gates together and you get a circuit that adds numbers, or chooses between inputs. Here's how the half adder, full adder, and multiplexer actually work.

Giving circuits a memory - flip-flops, registers and the clock

Combinational circuits forget everything instantly. Here's how a tiny feedback loop lets a circuit remember one bit, and how a clock signal keeps millions of them in sync.

Foundations of Computing Quiz

11 questions

The fetch-decode-execute cycle - how a CPU actually runs a program

A CPU never "runs" a program the way you imagine. It repeats one tiny loop, billions of times a second - fetch an instruction, figure out what it means, do it, repeat.

What does an instruction actually look like in memory?

An instruction is just a number. Here's how opcodes and operands pack into that number, and why RISC and CISC machines split the difference between simplicity and flexibility.

The three jobs every instruction set needs to do

Every instruction, in every CPU ever built, falls into one of three families - move data, compute on it, or change what happens next. Here's why that's the whole story.

Addressing modes: how an instruction says where its data actually is

An instruction can't just say "add two numbers" - it has to say exactly where to find them. Every addressing mode is just a different answer to that one question.

Registers, the register file, and what an ISA actually promises

An ISA is a contract, not a circuit. Here's exactly what that contract covers, and how the CPU's small set of registers gets shared across an entire running program.

Instruction Set Architecture Quiz

9 questions

The ALU: the calculator hiding inside every CPU

The Arithmetic Logic Unit is the one circuit that actually computes things. Here's how it's built, and how a single opcode picks between add, subtract, AND, OR and more.

The datapath: wiring the register file, ALU and memory together

The ALU alone can't do anything without wires connecting it to registers and memory. Here's how those wires form the datapath, one instruction type at a time.

The control unit: the conductor that sets every switch

Every multiplexer and every ALU operation needs to be set correctly, every single cycle. The control unit is the circuit that does exactly that, decoded straight from the opcode.

How does a CPU actually multiply and divide?

The ALU we built only adds, subtracts and does logic. Multiplication and division need their own algorithms, built entirely out of that same adder - here's exactly how, with worked examples.

Datapath & Control Unit Quiz

10 questions

Pipelining: doing laundry for four people at once

A single-cycle CPU wastes enormous amounts of time. Pipelining fixes it with the same trick as an assembly line - and comes with the same one big catch.

Data hazards: when the next instruction needs a value that isn't ready yet

Pipelining assumed independent instructions. Real programs constantly break that assumption - here's exactly how, and the clever wiring trick called forwarding that fixes most of it for free.

Control hazards: when the pipeline doesn't even know what to fetch next

Branches don't just delay a value like data hazards do - they delay knowing which instruction comes next at all. Here's how stalling, delay slots and branch prediction each deal with that.

Measuring pipeline performance, and going beyond one instruction per cycle

CPI ties every hazard from this module into one number you can actually calculate with. Then we look at what happens once one pipeline isn't enough anymore.

Instruction Pipelining Quiz

10 questions

Why can't we just build one giant, fast memory?

Fast memory is expensive and small. Cheap memory is huge and slow. The memory hierarchy is the compromise every computer makes, and locality is the reason the compromise works.

How cache actually works: blocks, tags and the address split

A cache can't remember an infinite number of addresses, so it has to be clever about which few bytes it holds, and how it instantly checks whether it's holding what you asked for.

What happens when you write to cache, and what gets evicted?

Reading from cache is only half the story. Writing raises a whole new question - when does main memory find out? - and a full cache needs a rule for deciding what to throw away.

Main memory: how RAM stores a bit as a leaking bucket of charge

RAM is not just a bigger, slower register file. It's built on a totally different, much simpler cell design - one with a genuinely strange problem that needs fixing every few milliseconds.

Memory interleaving, and the read-only memory your computer boots from

One memory module can only serve one request at a time. Here's how splitting memory into interleaved banks lets several requests overlap, plus everything worth knowing about ROM.

Secondary storage: why your files survive being turned off

RAM forgets everything the instant power is lost. Secondary storage is built specifically not to - here's how a spinning disk and a solid-state drive each pull that off, completely differently.

Virtual memory: giving every program its own private, pretend address space

Every program thinks it owns all of memory, starting from address zero. It doesn't. Here's the layer of indirection that makes that comfortable illusion possible.

Memory Hierarchy Quiz

13 questions

How does the CPU even talk to a keyboard or a screen?

A keyboard isn't memory, but the CPU still needs to read from it. Here's the simple trick that lets the exact same LOAD/STORE instructions talk to any device at all.

Interrupts: letting the device tap the CPU on the shoulder

Instead of the CPU constantly asking "are you ready yet?", what if the device could just interrupt whatever the CPU is doing the moment it actually has something? That's an interrupt.

What happens when two devices interrupt at the exact same time?

Real computers have dozens of devices that can all demand attention. Here's how the CPU figures out which interrupt fired, and which one to service first when several arrive together.

DMA: letting devices copy data without bothering the CPU at all

Interrupts fixed waiting for slow devices, but transferring a huge file still means the CPU babysitting every single word. DMA is the trick that removes the CPU from that loop entirely.

Polling vs interrupts vs DMA - choosing the right tool

Three ways to move data in or out of a computer, each solving a real limitation of the one before it. Here's how to reason about which one a given device actually needs.

I/O Interfaces & Interrupts Quiz

11 questions

You press the power button. Here's the very first thing that happens.

Before any operating system, before any program, before even the first instruction - there's a reset signal, a fixed address, and a tiny piece of permanent firmware. This is where every single boot begins.

How does a tiny piece of firmware find and load an entire operating system?

Firmware doesn't know anything about Windows or Linux. Here's the small, deliberate handoff chain - firmware to bootloader to kernel - that gets a full OS from a cold disk into running RAM.

The kernel wakes up - taking over the hardware you spent five modules learning

The instant the kernel's first instruction runs, it inherits raw, unmanaged hardware and has to organize all of it from scratch - memory, interrupts, devices, and the very first process - before anything you'd recognize as an "operating system" exists.

You double-click an app. Now trace every single thing that happens.

From a click, to a process being born, to the very first instruction fetched, to your first keystroke reaching the screen - every mechanism from every earlier module, chained together in the exact order they fire.

While your program runs, dozens of other things are happening that you never asked for

A running computer is never doing just one thing. Timer interrupts, context switches, DMA transfers, cache refills, DRAM refresh - here's the constant, invisible background activity happening underneath the program you think has your CPU's full attention.

Boot-to-Execution Quiz

10 questions

Foundations of Computing Quiz

Foundations of Computing · 11 questions

Instruction Set Architecture Quiz

Instruction Set Architecture · 9 questions

Datapath & Control Unit Quiz

Datapath & Control Unit · 10 questions

Instruction Pipelining Quiz

Instruction Pipelining · 10 questions

Memory Hierarchy Quiz

Memory Hierarchy · 13 questions

I/O Interfaces & Interrupts Quiz

I/O Interfaces & Interrupts · 11 questions

Boot-to-Execution Quiz

Boot to Execution: The Full System Trace · 10 questions

Computer Organization & Architecture Final Assessment

Final assessment · 29 questions