We will trace the single assignment statement position = initial + rate * 60 through all six phases of compilation. This is the canonical example from the Dragon Book, and it perfectly illustrates every phase's role.

The Symbol Table at this point already contains entries for position, initial, and rate (all declared as type float earlier in the program).

The Lexical Analyzer (scanner) reads the source character stream and groups characters into meaningful units called tokens. Whitespace and comments are discarded.

For our statement, the scanner produces the following token stream:

1<id, 1>   →  'position'  (identifier, Symbol Table entry 1)
2<=>       →  assignment operator
3<id, 2>   →  'initial'   (identifier, Symbol Table entry 2)
4<+>       →  addition operator
5<id, 3>   →  'rate'      (identifier, Symbol Table entry 3)
6<*>       →  multiplication operator
7<60>      →  integer literal

Each <id, N> token does not store the name itself — it stores a pointer to the Symbol Table entry. This is how the compiler avoids duplicating strings.

The Syntax Analyzer (parser) takes the token stream and checks that the sequence of tokens conforms to the grammatical rules of the language (the Context-Free Grammar). It produces a Parse Tree (or Abstract Syntax Tree) that represents the grammatical structure of the statement.

The tree captures the operator precedence correctly — * is a child of +, meaning multiplication is performed before addition, exactly as per the grammar rules.

The Semantic Analyzer checks the parse tree for semantic consistency — meaning that is correct beyond mere grammar. Its most critical job is type checking.

Looking up the Symbol Table, the analyzer determines:

• position, initial, and rate are all of type float.
• The literal 60 is of type int.
• You cannot directly multiply a float (rate) with an int (60) without a conversion.

The semantic analyzer inserts an explicit type coercion node (inttoreal) into the tree:

This is the annotated AST — the same tree structure, but enriched with type information at every node.

The Intermediate Code Generator traverses the annotated AST and produces a machine-independent intermediate representation. The most common form is Three-Address Code (TAC), where each instruction has at most one operator and three addresses (two sources, one destination).

For our statement, the TAC sequence is:

1t1 = inttoreal(60)      # Convert integer 60 to float 60.0
2t2 = id3 * t1           # rate * 60.0
3t3 = id2 + t2           # initial + (rate * 60.0)
4id1 = t3                # position = result

t1, t2, t3 are compiler-generated temporary variables. TAC is easy to generate from the AST and easy to optimize in the next phase.

The Code Optimizer improves the TAC sequence to make the final program run faster or use less memory, without changing its meaning.

A simple but powerful optimization is constant folding: the compiler notices that inttoreal(60) always produces the same constant 60.0 — so there is no need to compute it at runtime. It can be folded in at compile time.

The optimized TAC:

1t1 = id3 * 60.0         # rate * 60.0  (60.0 is now a float constant)
2id1 = id2 + t1          # position = initial + t1

Notice we went from 4 instructions to 2. The temporary t2 and t3 were also merged and eliminated.

The Code Generator translates the optimized TAC into actual target machine instructions. It must make decisions about register allocation — which CPU registers to use for which values.

A sample output for a simple register machine:

1LDF   R2, id3       ; Load 'rate' into floating-point register R2
2MULF  R2, #60.0     ; R2 = R2 * 60.0
3LDF   R1, id2       ; Load 'initial' into R1
4ADDF  R1, R2        ; R1 = R1 + R2
5STF   id1, R1       ; Store R1 back to memory as 'position'

This is the final target program — the machine code that will be executed by the CPU. The compilation of position = initial + rate * 60 is complete.