Program Execution: From Source Code to Machine Code

In the previous article, Instruction Representation, we saw how instructions are encoded in bits and how addressing modes determine where the processor finds each operand. But you write x = y + z in Python, not 0001 10110100. Someone has to do the translation. That someone is the toolchain that turns source code into machine code: the assembler, the compiler, the linker, and the loader.

Understanding this chain means understanding why C and C++ usually produce native executables, why Java distributes bytecode for the JVM, and why, when you run python script.py, the CPython interpreter first compiles the code to bytecode and then executes it in its virtual machine. In every case, the final goal is the same: to arrive at instructions the hardware can execute, directly or indirectly.

From human language to silicon: a brief history

#

The first programming languages were created in response to a simple demand: to make programming less error-prone and closer to human thought. The following table shows the timeline of some languages that shaped software development:

A few dates deserve a note, because different versions circulate out there. COBOL sometimes appears as 1958, but the CODASYL committee was only formed in May 1959 and the specification was approved in January 1960. The year 1958 belongs to ALGOL 58, a different language. And Ada appears as 1979, the year of the preliminary manual, as 1980, the year of MIL-STD-1815, and as 1983, the year of the MIL-STD-1815A and ANSI standardization, which is the canonical date.

Many others could be listed, but these are some of the most influential and representative. Each of them was designed with specific goals in mind (readability, performance, portability, safety, or ease of use) and each contributed to the evolution of the software development ecosystem.

The abstraction hierarchy

#

Languages form an abstraction pyramid: the higher the level, the closer to human language, and the farther from the hardware. Each level must be translated to the level below before the processor can execute the code.

But how does this translation chain work in practice? Let’s descend to the level closest to the hardware and start with the most direct process: assembling Assembly code.

The assembly process (Assembly)

#

The assembler converts assembly code into machine language. The translation is practically 1:1: each mnemonic corresponds to one machine instruction. The assembler works in two passes:

Assembly example: an assembly program to compute:

Using the hypothetical processor presented earlier in this series, with:

• \(Y\) at address 1F, containing 051
• \(Z\) at address 20, containing 03E
• \(T\) at address 21, containing 003
• \(X\) at address 22

The program starts at address 18:

Addresses 1D and 1E are left empty on purpose: the code ends at 1C and the data starts at 1F, and the gap is just the choice of where to begin the data block. In a real program, the assembler decides this layout.

The sequence does exactly what is expected:

1. loads \(Y\) into the accumulator;
2. adds \(Z\);
3. subtracts \(T\);
4. stores the result in \(X\);
5. ends the execution.

It is worth checking the arithmetic, since that is what proves the assembly worked. In decimal, \(Y = \text{051}_{16} = 81\), \(Z = \text{03E}_{16} = 62\), and \(T = \text{003}_{16} = 3\), so \(X = 81 + 62 - 3 = 140\). At the end of the execution, address 22 contains \(140_{10} = \text{08C}_{16}\).

The execution cycle for the LDA 1F instruction (which we already know from the article on the hypothetical processor) works exactly like this:

Compilation: a classic transformation pipeline

#

While the assembler translates instructions very close to the hardware, the compiler solves a broader problem: transforming high-level code into a form executable on the target architecture. A classic compilation pipeline goes through stages such as lexical, syntactic, and semantic analysis, generation of an intermediate representation, optimization, and object code generation.

This flow is extremely useful as a teaching model, although real compilers may reorder, merge, or even omit some of these stages internally.

%%{init: {'flowchart': {'useMaxWidth': false}}}%%
flowchart LR
    A([Source Code]) --> B["1. Lexical Analysis
(Tokenization)"]
    B --> C["2. Syntax Analysis
(Parser / AST)"]
    C --> D["3. Semantic Analysis
(Types and Scope)"]
    D --> E["4. Intermediate
Code (TAC)"]
    E --> F["5. Optimization"]
    F --> G["6. Object Code"]
    G --> H([Linker])
    H --> I([Executable])

Phase 1: lexical analysis (tokenization)

#

The lexical analyzer reads the source code character by character and groups the characters into tokens, the smallest units of meaning. It discards comments and whitespace.

Input:    x = y + z * 2

Tokens:   [ID: x] [OP: =] [ID: y] [OP: +] [ID: z] [OP: *] [NUM: 2]

Each token has a type (identifier, operator, numeric literal, keyword) and a value. Tokenization errors are the first to be detected.

Phase 2: syntax analysis (parser)

#

The parser checks whether the sequence of tokens obeys the grammar of the language. If so, it builds the Abstract Syntax Tree (AST), which represents the hierarchical structure of the code.

The figure below shows the AST of x = y + z * 2. Each node sits in the column of its token, and so the tree holds two readings: from left to right, it gives back the source code; from bottom to top, it gives the order in which the operations happen.

The AST captures operator precedence: * is deeper in the tree than +, which means it will be executed first.

Phase 3: semantic analysis

#

Checks the meaning of the code beyond its structure:

• Were all variables declared before use?
• Are the types compatible in operations and assignments?
• Is the number of arguments in function calls correct?

int x;
x = "hello";  // Semantic ERROR: correct syntax, but incompatible type

Semantic errors go unnoticed by the parser (the syntax x = something is valid), but the semantic analyzer detects them by checking type compatibility.

Phase 4: intermediate code generation

#

Produces a machine-independent representation, which eases portability and later optimization. The most common format is Three-Address Code (TAC): each instruction has at most three operands.

TAC for x = y + z * 2:

T1 = z * 2
T2 = y + T1
x  = T2

TAC resembles the language of our hypothetical processor: simple instructions, temporary registers, no nested operations.

Phase 5: optimization

#

Improves the intermediate code without changing the observable result. Some classic techniques:

In practice, real compilers (such as the famous GCC, widely used for languages like C and C++) let the programmer choose how aggressive this optimization is, and these levels have names:

Watching optimization happen

#

None of this has to stay abstract. Consider this C function, which is the same expression we have been following since lexical analysis:

int calculate(int y, int z) {
    int x = y + z * 2;
    return x;
}

Compiling with gcc -S -O0 -masm=intel, the compiler generates twelve instructions, with each variable going back and forth to memory, because without optimization it translates literally what the program said:

calculate:
        push    rbp
        mov     rbp, rsp
        mov     DWORD PTR [rbp-20], edi   ; stores y on the stack
        mov     DWORD PTR [rbp-24], esi   ; stores z on the stack
        mov     eax, DWORD PTR [rbp-24]   ; reads z back
        lea     edx, [rax+rax]            ; edx = z * 2
        mov     eax, DWORD PTR [rbp-20]   ; reads y back
        add     eax, edx                  ; eax = y + z*2
        mov     DWORD PTR [rbp-4], eax    ; stores x on the stack
        mov     eax, DWORD PTR [rbp-4]    ; reads x back to return it
        pop     rbp
        ret

Now the same file with gcc -S -O2 -masm=intel:

calculate:
        lea     eax, [rdi+rsi*2]
        ret

One computing instruction, plus the ret. The compiler realized that the variable x does not need to exist, that the parameters are already in registers (rdi and rsi, by the calling convention), and that x86 has an addressing mode (base plus scaled index, which the previous article described) capable of computing \(y + z \times 2\) in a single lea operation. The twelve instructions of -O0 and the two of -O2 do exactly the same thing.

This is why reading optimized assembly is hard: the code no longer has a line-by-line correspondence with the source. And this is why you debug with -O0 and ship with -O2.

Phase 6: object code generation

#

Translates the optimized intermediate code into machine instructions for the target processor. Produces an object file (.o on Linux/macOS, .obj on Windows).

At this stage, we have a binary file that the CPU understands, but it is still a loose piece. The file contains unresolved external references: for example, if your program uses a function from another file of yours, or functions from the system’s standard library (such as a print to write to the screen), the object code points to a “void”. It needs an integrator. Enter the Linker.

Linking (Linking)

#

The linker combines multiple object files and libraries into a single executable, resolving all external references.

Loading (Loading)

#

The loader transfers the executable from storage to Main Memory and prepares the environment so that it can start running. In real systems, this may involve not only copying the program into memory, but also adjusting addresses, mapping segments, and preparing shared libraries.

With the program properly assembled, compiled, linked, and loaded into Main Memory, the preparatory cycle ends. From this exact moment, the silicon takes over and the CPU starts the perpetual loop of fetch, decode, and execute that we dissected in the previous articles of the series.

Compilation × interpretation

#

The distinction between compiled and interpreted languages is useful, but it must be seen as a teaching model, not as an absolute boundary.

In practice, modern systems often mix strategies:

• compilation to bytecode;
• interpretation by a virtual machine;
• JIT compilation at run time;
• caching of intermediate artifacts.

That is why it is better to think of a spectrum of translation and execution, not a rigid dichotomy.

Typing: when types are checked

#

The discussion about compilation and interpretation connects directly with typing: how and when a language checks type compatibility between variables and operations.

Static × dynamic

#

Strong × weak

#

By language

#

Conclusion and next articles

#

The path from x = y + z to the bits the processor executes involves several transformations: source code analysis, generation of internal representations, production of object code, linking, loading, and execution. Depending on the language and the environment, some of these stages are explicit to the programmer; others happen invisibly inside the runtime.

If you want to keep exploring, three references cover well what this article only introduces. Compiler Explorer shows the assembly generated for any snippet of code, in dozens of languages and architectures, without installing anything. It is this section’s gcc -S, with an interface. Crafting Interpreters, by Bob Nystrom, is a complete, free book that builds two implementations of a language from scratch, covering the phases discussed here and going beyond them. And Linkers and Loaders, by John Levine, is the classic reference on the stage that almost no material covers in depth: precisely linking and loading.

In the next article, we will explore how the process happens in practice using Python, observing each phase directly in the interpreter. We will see how the tokenize module handles lexical analysis, how the ast module builds the abstract syntax tree, how the compile function generates bytecode, and how the dis module lets us inspect the generated bytecode. It will be an opportunity to see each stage in action, using a high-level language that many of you already know.

See you then!