Semester 4: Systems Programming
Year 2 - Systems | Phase 4 | Weeks 39-48 | 10 weeks
Semester 4 is where programming stops being mostly language-level and starts becoming machine-level and operating-system-level. You move from writing correct code to explaining what the compiler, linker, CPU, memory system, and kernel do with that code.
Goal
Build operational fluency in C, memory reasoning, machine architecture, and systems-level programming so you can write small real systems tools from the terminal and debug them without guesswork.
Prerequisites
You should enter this semester able to:
- read and write small multi-file programs in at least one high-level language
- use functions, modules, and basic testing without needing scaffolding
- reason about data structures, asymptotic complexity, and common refactoring moves
- work comfortably from the terminal with
git, a compiler, and a text editor
If Semester 3 concepts still feel unstable, especially modular design and code-reading discipline, slow down in Module 1 before trying to move quickly into pointers or fork.
Phase Completion Contract
By the end of the semester you should be able to:
- explain how a C source file becomes a running process
- reason about bytes, pointers, stack frames, heap allocation, and memory bugs
- read basic disassembly and connect code structure to hardware behavior
- use processes, file descriptors, threads, sockets, and debugging tools from C
- build one small but coherent systems project with written debugging evidence
Do not advance if you still treat compiler output, memory errors, cache effects, or syscall behavior as black boxes.
Module Path
| # | Module | What you are learning |
|---|---|---|
| 1 | C Programming Fundamentals | The C mental model, compilation pipeline, types, headers, arrays, strings, I/O, and modular builds |
| 2 | Memory, Pointers & Machine Representation | Bits, bytes, pointers, stack vs heap, layout, alignment, endianness, and memory-safety failures |
| 3 | Computer Organization & Architecture | ISA, disassembly, cache behavior, pipelines, virtual memory basics, and performance reasoning |
| 4 | Systems-Level Programming | fork/exec/wait, file descriptors, mmap, threads, sockets, gdb, strace, and perf |
| 5 | Abstraction & Interpretation | Abstraction barriers, closures, evaluation models, interpreters, and the cost of mutation |
The ordering matters. Module 4 is much easier if Modules 1 and 2 are stable, and Module 5 is more valuable after you have felt the weight of low-level details.
Core Resources
| Resource | Role this semester |
|---|---|
| The C Programming Language | Primary for C syntax, functions, headers, storage, and UNIX-flavored systems interfaces |
| Code | Conceptual support for machine execution, representation, and the hardware story |
| Computer Organization and Design | Primary for architecture, memory hierarchy, and hardware-software contracts |
| Computer Systems: A Programmer's Perspective | Strong support for machine-level execution and systems reasoning where available |
| Structure and Interpretation of Computer Programs | Selective contrast text for abstraction, evaluation, and interpreters |
Use the module concept pages as the main path. Use local book chunks selectively when you need reinforcement or an alternate explanation.
Cross-Cutting Tracks Active This Semester
| Track | Level | What it means in Semester 4 |
|---|---|---|
| Testing and verification | 3 | Compile with warnings enabled, write assertions, create small reproducible tests, and keep bug logs |
| Git, code review, CI/CD | 3 | Use disciplined commits, maintain buildable repos, and automate basic compile/test checks where practical |
| Security engineering | 1 | Treat memory safety, input validation, unsafe string handling, and syscall error handling as first-class concerns |
| Engineering fundamentals | 3 | Terminal fluency, compiler flags, debugging tools, and precise reasoning instead of folklore |
Suggested 10-Week Arc
| Week | Primary focus | Main outcomes |
|---|---|---|
| 1 | Module 1 foundations | Clean C build loop, compiler stages, warnings, headers, and functions |
| 2 | Module 1 completion | Arrays, strings, stdio, structs, and a small multi-file C utility |
| 3 | Module 2 representation | Hex, two's complement, floats, pointer drills, and memory diagrams |
| 4 | Module 2 completion | Stack, heap, allocators, ASan/Valgrind, struct layout, and endianness |
| 5 | Module 3 machine model | ISA, registers, disassembly, and source-to-assembly reading |
| 6 | Module 3 performance model | Cache, locality, pipelining, virtual memory basics, and microbenchmarks |
| 7 | Module 4 process and I/O core | fork, exec, wait, file descriptors, pipes, and shell-style redirection |
| 8 | Module 4 concurrency and tools | mmap, threads, sockets, gdb, strace, perf, and one debugging transcript |
| 9 | Module 5 abstraction and evaluation | Closures, environment model, tail calls, and tiny interpreter work |
| 10 | Integration and assessment | Semester project hardening, cumulative review, checkpoint, and exam |
How To Work Through The Semester
For each module:
- Read the module overview and concept sequence first.
- Work the concept pages in order.
- Do the practice pages before touching selective readings.
- Keep a running mistake log with actual compiler, runtime, or reasoning errors.
- Finish the module quiz only after you can explain your code aloud.
This semester is output-heavy. Handwritten memory diagrams, debugger transcripts, benchmark notes, and compile logs matter as much as the final program.
Semester Deliverables
- one working multi-file C utility project with clean headers and a reproducible build
- one memory notebook with pointer diagrams, stack/heap classifications, and bug postmortems
- one architecture notebook with disassembly annotations and cache/performance observations
- one systems lab pack covering process creation, pipes, file descriptors, threads, and sockets
- one tiny interpreter or evaluator exercise with a short reflection on abstraction vs machine detail
- one integrated semester project
- one checkpoint gate
- one cumulative review
- one semester exam
Evidence That You Are Ready For Semester 5
You are ready to move into operating systems and networking when you can:
- debug a C crash with compiler warnings plus
gdbor sanitizer output - explain why a given memory bug happened in terms of bytes and lifetimes
- reason about why a loop is slow in terms of cache or branch behavior
- build a process pipeline using
fork,exec,pipe, anddup2 - explain where abstraction helps and where machine details still dominate
If you can only produce working code by trial and error, repeat the weak module before advancing.
Capstone Throughline
Every semester must leave behind evidence that can survive into the final capstone defense.
- Artifact carried forward: systems tool/debugging transcript.
- What to preserve: Preserve debugger sessions, memory investigations, compiler/tool output, and concise explanations of root cause and repair.
- Module threads: Module 1: C Programming Fundamentals, Module 2: Memory, Pointers & Machine Representation, Module 3: Computer Organization & Architecture, Module 4: Systems-Level Programming, and Module 5: Abstraction & Interpretation.
- Defense prompt: In Semester 10, explain how this semester's artifact changed a capstone decision, reduced a risk, or made the final system easier to defend.
Model Artifact Calibration
Use the C debugging transcript model artifact to calibrate evidence-based low-level debugging writeups.