This page is about the course rather than the computer. It explains the two ways each idea is written and the caption that sits on every listing. It also names the three places where code runs while you work through the book: when the course was built, on the page, and on your own machine.
Two explanations, and your setup
Most ideas in this course are explained twice. The Textbook version is exact and uses the official vocabulary, the way a manual written by a chip maker would. The Plain English version (this one) explains the same ideas for someone who has never met them, defining every term in everyday words as it comes up. It says everything the Textbook version says; it just takes more room to say it. Read whichever suits you, or both. The quizzes use the official words, so it pays to learn them as you go.
Some instructions depend on which computer you have. Building a program on Windows uses different commands from building it on a Mac, as you saw in §4. In those places the page shows tabs, one per system, and later a second row of tabs for the kind of processor chip. Pick yours once under My setup on the course page, or click any tab, and the whole course remembers. If there are no tabs, the material is the same on every computer.
Most ideas are explained twice, side by side. The Textbook lane is precise: it uses the standard terms and states rules in full, the way a processor manual or a compiler's documentation would. The Plain English lane says the same things for a reader meeting them for the first time: every term is explained in ordinary words where it appears, and nothing is left out. Read either, or both. Questions use the terms from the Textbook lane, so it is worth knowing them.
Some steps depend on your computer. Where they do, the page shows tabs (Windows, macOS, Linux, as in §4) and, from Chapter 1, a second set of tabs for the processor family. Choose once under My setup on the course page, or click any tab, and every matching block in the course follows your choice. Material without tabs is the same everywhere, and the text says so when that matters.
Worked example
Setting up once
-
1
Priya uses a Windows laptop for her coursework. On the course page she opens My setup and picks Windows.
-
2
In §4 of this chapter, the build commands now open on the Windows tab: Developer PowerShell,
cl,.\sum.exe. -
3
In Chapter 6, where every system has its own way to build an assembly program, the Windows steps are the ones she sees first. She can still click the macOS or Linux tab to compare.
Worked example
One idea, two lanes
-
1
The Textbook lane in §4 says a compiler driver "runs all of them in order and hands each the right settings". Is the Plain English lane's foreman, who gives each tool its job in turn, a different claim?
-
2
No. Both say the same two facts: several tools do the build, and one command starts them all in the right order.
-
3
The Textbook sentence gives you the official term, compiler driver, which questions use. The Plain English version builds the picture for a reader who has never seen a build.
-
4
If the two lanes ever seemed to disagree, that would be a mistake in the course. They are two tellings of one set of facts.
Practice: Two lanes and your setup (4 problems · doesn’t affect your progress)
Which lane is written for a reader meeting an idea for the first time?
Right on try — credit. Right — the answer had already been shown, so no credit this time. Next try is worth Answer shown after three tries — this one no longer earns credit. You chose to see the answer — this one earns no credit.
The Textbook lane is the precise, official version, which can be dense on a first read.
Plain English starts from nothing and defines every term as it appears.
Questions use the Textbook terms, but that lane isn't the one written for newcomers.
Why
Plain English explains every idea from scratch, in everyday words. Textbook is the precise version with the official terms.
One lane is a translation of the other.
Plain English
Priya chose Windows under My setup. A block of build steps has Windows, macOS and Linux tabs. Which tab opens first for her?
Right on try — credit. Right — the answer had already been shown, so no credit this time. Next try is worth Answer shown after three tries — this one no longer earns credit. You chose to see the answer — this one earns no credit.
Tab position doesn't matter. Her saved choice does.
Order on the page doesn't decide it.
The point of My setup is that she chooses once.
Why
Her saved choice, Windows, opens first on every block that has a Windows tab.
What did she tell the course?
Windows
In Chapter 6, Priya clicks the Linux tab on one block to compare. What happens to the other tab blocks?
Right on try — credit. Right — the answer had already been shown, so no credit this time. Next try is worth Answer shown after three tries — this one no longer earns credit. You chose to see the answer — this one earns no credit.
A click on any tab sets the choice for every matching block, the same as My setup.
Nothing switches back on its own.
There's no confirmation step; the switch is immediate.
Why
Choosing under My setup and clicking any tab both set the same remembered choice, so every matching block follows. She can click Windows again to switch back.
Clicking a tab and using My setup do the same thing.
They switch to Linux as well, because clicking a tab changes the saved choice
Which of these would you expect to appear without any system tabs?
Right on try — credit. Right — the answer had already been shown, so no credit this time. Next try is worth Answer shown after three tries — this one no longer earns credit. You chose to see the answer — this one earns no credit.
Opening a terminal is different on Windows, macOS and Linux.
Installing differs on each system, as §4 showed.
That's ./sum on macOS and Linux but .\sum.exe on Windows.
Why
A for loop is C++ and behaves the same everywhere. Opening a terminal, installing a compiler and running a program all differ by system, so they sit behind tabs.
Which one is the same on every computer?
How a for loop counts from 0 to 9
The caption on every listing
Remember from §1 that machine code only makes sense to one family of processor chips, and that Windows, macOS and Linux each package programs their own way. So a page of machine code is meaningless unless you know which chip and which system it was made for. That's why, from Chapter 1 on, every listing has a caption naming both, such as "x86-64 · Linux".
The course follows three families of processor chip. You'll meet them properly in Chapter 1; for now, just know the names:
- x86-64 is the family inside most Windows PCs and many servers.
- ARM64 is the family inside phones, newer Macs and many cloud servers.
- RISC-V is a newer, open design that anyone may build, common in small gadgets and spreading.
Here's why the system matters too. The table shows the one-line add
code from §1 translated three ways by the same compiler, Clang. The x86-64
version for Linux and the x86-64 version for Windows are almost the same:
same chip family. But one number differs, because Windows and Linux have
different habits about where a piece of code finds its inputs. Chapter 12
explains those habits. The ARM64 version doesn't look like either of
them, and it's twice as long. Same C++, three different sets of numbers.
Machine code is specific to a processor family and to a system (§1). So from Chapter 1 on, every machine-code or assembly listing carries a caption naming both, such as x86-64 · Linux or ARM64 · macOS. The course uses three processor families. Chapter 1 §4 compares them; for now, the names are enough:
- x86-64: the processors in most Windows PCs and many servers.
- ARM64: phones, Apple-silicon Macs, many cloud servers.
- RISC-V: an open design used in small embedded chips, and growing.
The system matters as well as the chip. Here is the add code from §1,
int add(int a, int b) { return a + b; }, compiled by Clang at -O1
for three targets, with the machine code written in decimal:
| Caption | Machine code |
|---|---|
| x86-64 · Linux | 141 4 55 195 |
| x86-64 · Windows | 141 4 17 195 |
| ARM64 · Linux | 32 0 0 11 192 3 95 214 |
The two x86-64 lines share most of their numbers: same chip family. But Windows and Linux agree on different places to put a function's inputs, so one number differs (Chapter 12 explains why). The ARM64 line has nothing in common with either. Without the caption, a listing can't be read correctly.
Run it as it is, or rebuild?
Sort each case: can the copied executable run as it is, or does the program have to be built again from its source code?
Loading interactive…
Right on try — credit. Right — the answer had already been shown, so no credit this time. Next try is worth Answer shown after three tries — this one no longer earns credit. You chose to see the answer — this one earns no credit.
What this task checks
Structure checked automatically. Whether your ideas are convincing isn't graded, so reread with the checklist.
The compiler says
A model answer
Correct answer
Also accepted:
Why
Why
Worked example
Reading a caption before the code
-
1
A listing in Chapter 7 is captioned ARM64 · macOS. Kofi has an x86-64 Windows PC. Can he learn from it?
-
2
Yes. The caption tells him what the listing is: machine code (in its readable spelling) for ARM64 chips, built the way macOS expects. The ideas it shows apply to his machine too.
-
3
What he can't do is paste it into his own build and expect it to work. His x86-64 chip doesn't understand ARM64 machine code, and his system packages programs differently.
-
4
If he sets My setup to Windows and x86-64, the pages show his own version first wherever one exists. The caption is how he knows which one he's reading.
Check your understanding (counts toward your progress)
A listing's caption names a different processor family from your laptop's. What can you do with it?
Right on try — credit. Right — the answer had already been shown, so no credit this time. Next try is worth Answer shown after three tries — this one no longer earns credit. You chose to see the answer — this one earns no credit.
The ideas a listing shows apply to every family.
Machine code is specific to one family; yours can't follow it.
The caption describes the code. Editing it changes nothing about the numbers.
Why
You can read and learn from any listing; the caption tells you what it is. To run something on your machine, you need code for your own family and system.
Reading and running are different things.
The add code was 141 4 55 195 for one processor family on Linux, and 141 4 17 195 for the same family on Windows. Why do they differ?
Right on try — credit. Right — the answer had already been shown, so no credit this time. Next try is worth Answer shown after three tries — this one no longer earns credit. You chose to see the answer — this one earns no credit.
Both are from the same processor family. The difference comes from the system.
Nothing is stamped onto machine code like that; only one number changed, the one about where the inputs are.
Both are correct, captured from a real compiler.
Why
Same chip, same steps, but each system has its own habit about where inputs are found, so one number differs. Chapter 12 explains those habits.
Same chip family, different system: what did the section say each system decides?
Sort each question: does a listing's caption answer it, or not?
Right on try — credit. Right — the answer had already been shown, so no credit this time. Next try is worth Answer shown after three tries — this one no longer earns credit. You chose to see the answer — this one earns no credit.
What this task checks
Structure checked automatically. Whether your ideas are convincing isn't graded, so reread with the checklist.
The compiler says
A model answer
Why
The caption names the family and the system. From the family you also know the code isn't for any other family. Timing and authorship aren't in it.
Correct answer
Also accepted:
Why
If you know which family it's for, you also know which families it isn't for.
What two things does the caption on a machine-code listing name?
Right on try — credit. Right — the answer had already been shown, so no credit this time. Next try is worth Answer shown after three tries — this one no longer earns credit. You chose to see the answer — this one earns no credit.
The reader needs to know what the numbers are for, not who wrote them or when.
Build time doesn't change how the listing should be read.
Captions say what machine the code is for, not where it sits in the book.
Why
Machine code is tied to one processor family and one system, so every listing names both. Without them, the numbers can't be read correctly.
Machine code is tied to two things.
Practice: Setup and captions (4 problems · doesn’t affect your progress)
You click the Linux tab on one block of steps. What happens to the other tab blocks in the course?
Right on try — credit. Right — the answer had already been shown, so no credit this time. Next try is worth Answer shown after three tries — this one no longer earns credit. You chose to see the answer — this one earns no credit.
Every block in the same group follows your choice.
There's one course; the tabs adapt it in place.
The switch is immediate.
Why
Clicking a tab sets your choice for every matching block, the same as choosing in My setup.
Choose once.
They all switch to Linux too, and the choice is remembered
A block of steps has no tabs at all. What does that tell you?
Right on try — credit. Right — the answer had already been shown, so no credit this time. Next try is worth Answer shown after three tries — this one no longer earns credit. You chose to see the answer — this one earns no credit.
Material for one system sits behind a tab, or says so.
Tab blocks show a default tab even before you choose.
No tabs is deliberate: there's nothing to choose between.
Why
Tabs appear only where the steps differ. Material without them is universal.
Tabs appear only where systems differ.
The material is the same on every system
Why can't you copy a listing made for one processor family into a build for another family?
Right on try — credit. Right — the answer had already been shown, so no credit this time. Next try is worth Answer shown after three tries — this one no longer earns credit. You chose to see the answer — this one earns no credit.
Nothing stops copying. The problem is what the numbers mean.
The caption is a description; it isn't part of the code.
There's no such limit.
Why
Machine code is in the format of one processor family; another family would read the same numbers as different steps.
What did §1 say machine code is tied to?
The other family reads the numbers in a different format
In the add table, one processor family's version has eight numbers and the other two have four. What's the best conclusion?
Right on try — credit. Right — the answer had already been shown, so no credit this time. Next try is worth Answer shown after three tries — this one no longer earns credit. You chose to see the answer — this one earns no credit.
Both versions add two numbers and go back. The encoding differs, not the work.
All three were captured from a real compiler.
One small example can't support an "always".
Why
Each family has its own machine-code format. Here the eight-number family happens to use four numbers per step; that's a difference in encoding, not in work. Chapter 1 §4 compares the families.
All three versions do the same two steps.
Each processor family encodes the same work in its own way
Captured, modelled, or run on your machine
Code runs in three places while you work through this course, and it helps to know which one you are looking at.
There are three places where code gets run in this course, and it's worth knowing which one you're looking at.
Before you arrived. When the course was put together, real compilers on real computers produced every output you see on a page. That means what a program prints, what an error message says, and the machine code for a piece of C++, and what a debugger showed. A debugger is a tool that runs a program under your control. It can pause the program partway through and show you the numbers it is holding at that moment. That copied-in result is called a captured listing. It isn't typed by hand. Each time the course is rebuilt, the programs are run again, and if the real output has changed, the page is held back until it's fixed. All the outputs in this chapter were made that way.
On the page, while you read. Some pages contain a model: a simplified pretend version of a piece of hardware that follows a few fixed rules, so you can watch it work step by step. A model of a processor, for example, lets you click through its work one step at a time. It's labelled as a model, because a real chip is far more complicated and much faster. A model shows you how something works, not how long it takes. Questions are answered on the page too. When you type code into a question, the site reads it to check its shape, like the order of your lines or the fix you made. It never runs it.
On your own computer. Anything you run yourself happens on your own machine: the C++ you built in §4, the assembly programs you'll write from Chapter 6, and the labs. A lab is a folder you download, with tests already written that pass once your work is right.
When the course was built. Every program output, compiler message, machine-code listing and debugger reading on a page is a captured listing: text real tools produced when the course was built, and re-checked on every rebuild. If a compiler or the course changes and the real output no longer matches, the page can't be published until it's fixed. Every program output shown in this chapter is captured this way. A debugger is a tool that runs a program under your control: it can pause the program partway through and show the numbers it is working with at that moment. Chapter 6 installs one; until then, every debugger reading in the course is captured.
On the page. Some pages run a model: a simplified, predictable imitation of a piece of hardware, such as a processor stepping through its machine code (Chapter 5) or a cache deciding what to keep (Chapter 27). A model follows rules stated on the page and is labelled as a model. It shows how a mechanism works. It doesn't claim the timing of a real chip, and where a model does claim what a real program does, its result is compared with a captured run. Questions are also answered on the page, and code you write in one is read, never run: the site checks its shape (the order of your lines, the text of your fix, what you say a program prints).
On your own machine. Everything you run is run here: the C++ you build in §4, the assembly you write from Chapter 6, and every lab. A lab is a project folder you download, with tests already written that pass when your work is right.
Captured, model, or yours?
Sort each item by where it comes from.
Loading interactive…
Right on try — credit. Right — the answer had already been shown, so no credit this time. Next try is worth Answer shown after three tries — this one no longer earns credit. You chose to see the answer — this one earns no credit.
What this task checks
Structure checked automatically. Whether your ideas are convincing isn't graded, so reread with the checklist.
The compiler says
A model answer
Correct answer
Also accepted:
Why
Why
Worked example
What a model can and can't tell you
-
1
A model processor in Chapter 5 shows one step finishing on each click, and says so. Ana concludes that her laptop's processor also does exactly one step at a time.
-
2
The model shows the order of the work: fetch the next step, work out what it means, do it. That order is real, and it's what the model is for.
-
3
How long each step takes, and whether several overlap, is outside what this model claims. A real processor overlaps many steps at once, which Chapters 24 to 26 show with their own models and with measurements.
-
4
So: trust a model for the mechanism it says it shows. For what real hardware does, look for a captured listing or a measurement.
Bug hunt, spot mode
This program should add up three prices and print 15. It has 1 mistake. Click the line that is wrong.
Loading interactive…
Right on try — credit. Right — the answer had already been shown, so no credit this time. Next try is worth Answer shown after three tries — this one no longer earns credit. You chose to see the answer — this one earns no credit.
What this task checks
Structure checked automatically. Whether your ideas are convincing isn't graded, so reread with the checklist.
The compiler says
A model answer
Correct answer
Also accepted:
Why
Why
Worked example
Working a bug hunt
-
1
A bug hunt tells you how many mistakes there are, not where. In spot mode you click the broken lines; in fix mode you edit the code.
-
2
Start from what the program should do: add three prices and print 15. Then read line by line, asking whether each line does its part.
-
3
Lines 5 and 6 set up the array and a total of 0: fine. Line 7's loop condition is
i <= 3, which gives four passes for three elements. That's the line. -
4
Nothing ran. The site compared the line you clicked with the line the answer names. In fix mode it reads your edited code and checks the change, still without running it.
Check your understanding (counts toward your progress)
A model processor finishes one step per click. What can you safely conclude about a real processor from it?
Right on try — credit. Right — the answer had already been shown, so no credit this time. Next try is worth Answer shown after three tries — this one no longer earns credit. You chose to see the answer — this one earns no credit.
Real processors overlap many steps. The model doesn't claim timing.
Speed is a measurement on real hardware, not something a model claims.
Models show real mechanisms; they just don't claim timing.
Why
A model is trustworthy for the mechanism it states. Timing and overlap come from captured runs and measurements on real hardware.
What does the model say it shows?
What is a model, in this course?
Right on try — credit. Right — the answer had already been shown, so no credit this time. Next try is worth Answer shown after three tries — this one no longer earns credit. You chose to see the answer — this one earns no credit.
No real hardware runs on the page. A model follows a few stated rules.
A real processor is far too complicated to copy exactly; a model simplifies on purpose.
A captured listing is real output. A model follows its own stated rules.
Why
A model follows simple, stated rules to show how a mechanism works. It is labelled so you know it isn't a real chip.
It's labelled as one for a reason.
You type a fixed program into a bug hunt and submit it. What does the site do with your code?
Right on try — credit. Right — the answer had already been shown, so no credit this time. Next try is worth Answer shown after three tries — this one no longer earns credit. You chose to see the answer — this one earns no credit.
Code you write in a question is never compiled or run.
Nothing is sent to your machine. Your own runs are ones you start yourself.
Models illustrate hardware. They don't grade your answers.
Why
The site reads your code and checks its shape: which line changed and how. It never compiles or runs it.
Nothing you write on a page is run.
A compiler update changes the real output of one example. What happens to its captured listing?
Right on try — credit. Right — the answer had already been shown, so no credit this time. Next try is worth Answer shown after three tries — this one no longer earns credit. You chose to see the answer — this one earns no credit.
Captured listings are re-checked on every rebuild, exactly so they can't go stale.
A mismatch stops publishing; it isn't hidden.
The check is automatic. Nobody has to notice it by hand.
Why
Every rebuild runs the examples again and compares. A mismatch blocks the page until the listing is updated, so what you see matches real tools.
Captured listings are checked again every time the course is rebuilt.
Practice: Captured, modelled, or yours (4 problems · doesn’t affect your progress)
Where does ./sum run when you type it?
Right on try — credit. Right — the answer had already been shown, so no credit this time. Next try is worth Answer shown after three tries — this one no longer earns credit. You chose to see the answer — this one earns no credit.
The site never runs your programs.
Models illustrate hardware; they don't run your executables.
Typing it in your terminal really runs it.
Why
Anything you run in your own terminal runs on your own machine.
Who typed it, and where?
On your own machine
Can a model of a processor tell you exactly how long your laptop takes to run a program?
Right on try — credit. Right — the answer had already been shown, so no credit this time. Next try is worth Answer shown after three tries — this one no longer earns credit. You chose to see the answer — this one earns no credit.
A model simplifies on purpose and says so.
Clicking speed has nothing to do with the chip's speed.
Length doesn't matter; timing is never what a model claims.
Why
Timing comes from real hardware: captured runs and measurements. A model shows the mechanism it states.
What does a model leave out?
No: a model shows a mechanism, not real timing
Why can you trust the output printed under a C++ program on a page, without running it yourself?
Right on try — credit. Right — the answer had already been shown, so no credit this time. Next try is worth Answer shown after three tries — this one no longer earns credit. You chose to see the answer — this one earns no credit.
Nothing is typed by hand; hand-typed output can drift from reality.
Program outputs are captured from real runs, not modelled.
It's exact: the real output of a real run.
Why
It's a captured listing: real compilers built and ran the program when the course was built, and every rebuild checks it again.
What kind of listing is it?
It's real output from a real run, re-checked each rebuild
You want to know what a real processor does with a program. Which is the strongest evidence?
Right on try — credit. Right — the answer had already been shown, so no credit this time. Next try is worth Answer shown after three tries — this one no longer earns credit. You chose to see the answer — this one earns no credit.
A model shows a mechanism; it doesn't claim what real hardware did.
Reading C++ doesn't tell you what machine code it became.
Both lanes describe the same facts; neither replaces evidence.
Why
Captured runs and measurements come from real hardware. Models illustrate; they don't replace evidence.
Real tools, real hardware.
A captured run or a measurement on real hardware
Where this goes next
Chapter 1 §4 compares the three processor families named here, and Chapter 1 §6 reads a listing's parts, caption first. Chapter 5 introduces the first model, a processor you step through. Chapter 6 is where you build and debug assembly on your own machine, and labs with tests start there.