Interpreters vs. Compilers – what really happens when code runs

Interpreters vs. Compilers – what really happens when code runs

Programming languages do not “run themselves”; they need some mechanism to turn human-readable source into the electrical signals a CPU understands. Two classical mechanisms dominate:

Most modern runtimes blend the two (e.g., a byte-code interpreter that just-in-time compiles hot functions), but the pure forms illustrate the fundamental trade-offs.

1 Interpreter pipeline — step by step

1. Lexing & parsing – convert source into a parse tree or byte-code.
2. Dispatch loop – a small virtual machine fetches the next instruction, decodes it, and calls the routine that implements it (add, branch, print…).
3. State updates – results are stored in an interpreter-managed stack or environment table.
4. Repeat until no instructions remain.

The critical point is that each high-level instruction is revisited at run time, so the interpreter pays decoding cost every loop.

2 Compiler pipeline — step by step

1. Front-end analysis – the compiler parses the whole program, builds an Abstract Syntax Tree, checks types, and reports errors.
2. Optimisation – intermediate representation (IR) passes remove dead code, propagate constants, vectorise loops, etc.
3. Code generation – IR is mapped to machine instructions for a specific CPU and operating-system ABI.
4. Linking – object files and libraries are stitched together; the result is a native executable.

At run time the CPU reads already optimised instructions directly from memory; no further translation is needed.

3 A tiny worked example – adding three integers

High-level source (same logic, two languages)

# Python (interpreted by CPython)
a, b, c = 4, 7, 2
total = a + b + c
print(total)

/* C (compiled with GCC or clang) */
#include <stdio.h>
int main(void) {
    int a = 4, b = 7, c = 2;
    int total = a + b + c;
    printf("%d\n", total);
    return 0;
}

What the interpreter does

Each BINARY_ADD is a byte-code fetched by the VM; the real CPU is executing the VM’s dispatch loop hundreds of times per high-level operation.

What the compiler produces (x86-64 excerpt)

mov    eax, 4        ; load a
add    eax, 7        ; a += b
add    eax, 2        ; a += c
mov    esi, eax      ; prepare printf argument
mov    edi, fmt_ptr  ; "%d\n"
call   printf

The three add instructions are executed directly by the processor with almost no overhead.

4 Why the difference matters

A JIT-equipped runtime (Java, .NET, JavaScript V8, PyPy) lands in between: start quickly from byte-code, then compile the hot functions so they approach native performance after a warm-up period.

5 Choosing the right approach

Core Concepts in Language Execution (Interpreters vs Compilers)

Lexical and Syntactic Analysis

Abstract Representation and Analysis

Execution and Translation Pipelines

Intermediate and Machine-Level Concepts

Take-away

• Interpreters execute high-level constructs as they go—simpler to start, perfect for rapid iteration, but slower in the long run.
• Compilers do the heavy work up front, paying translation cost once to deliver tight, predictable machine code.
• Modern language runtimes often mix both ideas, compiling when it helps and interpreting when it keeps development nimble.

Understanding where translation effort lands—in the editor loop, at program start-up, or dynamically while the program runs—lets you pick the right tool chain for every project.