Foundation section · 9 lessons · Available
How programs execute
From source code to instructions, processes, system calls, and scheduling. Learn to separate work from waiting, then explain a request's complete timeline.
- 1What does the CPU actually execute?OS-01 · From code to CPU work · Lesson 1 of 9Recorded native evidence15–20 min estimated reading10–15 min exercises / exploration
- 2Where does an instruction keep its work?A profiler points at a small calculation. Before deciding how to optimize it, we need a more useful picture than “the CPU runs this line.” A line can become several instructions, disappear, or share work with another line. This lesson…Model~4 min estimated reading
- 3Why some work must wait for other workF2 · OS-01 · Dependencies before speedModel12–15 min estimated reading~10 min exercises / exploration
- 4How does a processor choose what happens next?An input passes validation, a parser sees a delimiter, or a request hits a cache. Programs constantly choose between paths. Two inputs of the same size can cause different work because those choices differ. To reason about that, we need…Model~4 min estimated reading
- 5A program is a file. A process is a running instance.You start the same service twice. Both copies run the same code, but changing a variable in one does not normally change the other. Why? The executable describes work; each running instance has its own execution context and resources.…Recorded native evidence~4 min estimated reading
- 6Where does your program end and the operating system begin?Adding two numbers and reading a file may look like adjacent function calls. They ask very different things of a machine. Arithmetic can operate on values already available to the program. Reading a file involves a resource managed by…Recorded native evidence~4 min estimated reading
- 7Ready to run is not the same as runningYour service has more threads than available CPU time. Some threads want to execute immediately. Others are waiting for a reply. An end-to-end timer cannot tell these situations apart, but the distinction changes what you should fix.Constructed case~4 min estimated reading
- 8Running is only part of elapsed timeF4 · OS-03 and measurement introductionRecorded native evidence12–15 min estimated reading~10 min exercises / exploration
- 9Investigation: explain the missing 800 millisecondsA service processes one request in 1,000 ms. A developer says, “The function has a loop, so the loop must take a second.” Another says, “CPU use is low, so the machine cannot be overloaded.” You now have the concepts to question both…Constructed case~4 min estimated reading
The first lesson needs no account; remaining lessons require a verified free account. Signed-in learners can open lessons in any order. Reading estimates exclude exercises and challenges.
About this section
You can write a function without knowing exactly how a machine carries it out. That abstraction is useful—until a service slows down, an optimization changes nothing, or a trace shows time disappearing somewhere outside the code you expected.
This section connects the familiar program to the work beneath it. We start with a tiny calculation because its result is easy to check. Then we widen the frame: instructions and dependencies, conditional paths, a running process, operating-system services, and the waits between periods of execution. Each step adds a question you can use while debugging.
The destination is practical: explain where a request's elapsed time went and choose evidence that separates competing explanations. You are not expected to memorize an instruction set or complete an operating-systems degree. This is a complete foundation section with a beginning, nine lessons, and a final investigation; it does not claim exhaustive coverage of computer architecture or Linux.
The complete section
| Lesson | Question you will be able to answer |
|---|---|
| 1. What does the CPU actually execute? | Did the work in my source survive compilation? |
| 2. Where does an instruction keep its work? | Which values does an operation read and produce? |
| 3. Why some work must wait | What can proceed independently and what must wait for a result? |
| 4. How does a processor choose what happens next? | What can a branch model explain, and what needs hardware evidence? |
| 5. A program and a process | Which running instance owns this state and these resources? |
| 6. The operating-system boundary | What did a read or send actually establish? |
| 7. Ready is not running | Is work blocked, runnable, or executing? |
| 8. Running is only part of elapsed time | Which measured boundaries account for the wait? |
| 9. Explain the missing 800 milliseconds | What change would I test, and what would disprove my explanation? |
How to use it
We assume you can follow variables, functions, and loops. Systems terms are introduced as needed. Follow the table in order for a guided route, or open the lesson closest to your current question. Completion of earlier lessons is never an access requirement.
Code has two different jobs here. Small Python models make rules inspectable; native Linux examples produce evidence about an actual environment. A model's steps are not CPU cycles, and a recorded run is not a live experiment. Every activity states its type and provides enough explanation to learn without a terminal.
Each lesson keeps explanation, activity, hints, and results together. Python models can run in your browser; native Linux examples are shown as recorded evidence from a stated environment, not executed live.
What to take away
Keep a small investigation notebook. For each lesson, record your prediction, what the example establishes, and one conclusion it cannot establish. At the end, produce the four-sentence recommendation in the final investigation. This is evidence of reasoning; simply opening nine pages is not the same achievement.
Next, memory and data movement explains where the work's inputs live and what moving them costs. The AI endpoint preview offers a direct application to serving and a route toward future AI networking material.