How Code Becomes Execution (compilers, stack & heap)

The road from the words you type to the bytes the chip runs, and the two work areas a running program keeps while it’s on that road: one that grows and shrinks with every function call, one that holds anything that has to outlive the call that made it.

Before you start. The CPU (fetch-decode-execute, the ISA, assembly) left you with a chip that does exactly one thing, forever: fetch an instruction, decode it, run it - it has no idea what a word, a loop or a function is. The Memory Hierarchy (cache, locality, the memory wall) left you with the other half: while that chip runs, everything the program is working on sits in memory, in copies at different speeds.

The idea in 30 seconds

Code you can read isn’t something the chip can run; a compiler translates all of it first, an interpreter translates one line at a time as it goes.
Interpreting costs real time: hundreds of times slower per step than translating ahead.
A running program keeps two work areas: a stack for calls that haven’t finished, and a heap for anything that has to outlive the call that made it.
The stack only ever changes from the top, one entry per call, and each entry holds the address to resume at.
A pointer is an address you can hold and follow; the resume address is one too, so writing past the end of a stack entry can overwrite it and hijack the program.
Every language, however it gets there, ends at the same machine code the chip actually runs.

Read the story · Skip to the numbers