Translation Software

A high-level program cannot be run directly by the processor — it must be translated. An interpreter does this in a particular way:

An interpreter analyses and executes the source code one statement at a time, while the program is running. It does not produce a complete translated (object) file that is stored for later.

Working through a program, the interpreter:

1. reads the next statement of the source code;
2. analyses (translates) it;
3. executes it immediately;
4. moves on to the next statement.

Because nothing is saved, the program must be re-translated every time it is run, and the source code is needed each time.

Why this is useful (and where it is weak):

Interpreter	Effect
Stops at the first error and reports it	great for debugging — fast edit/run cycle
No recompilation needed after an edit	quick feedback while developing
Re-translates every run	generally slower to run than compiled code
Source code must be supplied	the program is not a standalone executable

Contrast this with a compiler, which translates the entire program in advance into an object/executable file that is saved and can be run many times without re-translating.

When a compiler translates a program, it works through four stages in a fixed order. The pipeline below shows the flow from source code to optimised object code:

1. Lexical analysis. The source is read and broken into tokens (keywords, identifiers, operators, constants). Whitespace and comments are removed, and identifiers/constants are recorded in the symbol table. No grammar checking happens here.

2. Syntax analysis (parsing). The stream of tokens is checked against the grammar (syntax) rules of the language. A parse tree is built to show the structure, and any syntax errors (e.g. a missing bracket) are detected and reported.

3. Code generation. The parsed program is turned into equivalent object (machine) code.

4. Optimisation. The object code is improved so the program runs faster and/or uses less memory/storage, without changing what it does.

To check whether a program is correctly formed, the compiler needs a precise description of the language's grammar — the rules for how valid statements are built. Two notations are used.

Backus-Naur Form (BNF) is a text-based notation:

• A rule defines a non-terminal (in angle brackets) using `::=`.
• `|` separates alternatives.
• A rule can be recursive — it refers to itself — which lets it describe items of any length, ending at a base case.

A classic example, defining an unsigned integer of any length:

``` ::= 0|1|2|3|4|5|6|7|8|9 ::= | ```

The second rule says an unsigned integer is either a single digit (the base case) or a digit followed by another unsigned integer (the recursive case) — so 4, 40 and 407 are all valid.

A syntax diagram is the graphical equivalent of BNF: the same rules drawn as boxes joined by directed paths, where choices are branches and repetition/recursion is shown as a loop. Here is `` as a diagram — the loop back lets you take more digits:

Validating a string means walking it symbol by symbol against the rule (or tracing a path through the diagram). For example, against ` ::= | `, the string `k7` is valid (letter then one digit) but `kk7` is invalid (two letters at the start).

Infix notation is the usual way we write expressions, with the operator between the operands, e.g. `(3 + 4) * 5`. Infix needs brackets and precedence rules to fix the order of operations.

Reverse Polish Notation (RPN), also called postfix, puts each operator after its operands:

$(3 + 4) * 5 \;\;\rightarrow\;\; 3\;\;4\;\;+\;\;5\;\;*$

The big advantage: RPN needs no brackets and is unambiguous, so it can be evaluated easily with a stack.

Evaluating RPN with a stack — scan the expression left to right:

• if you read an operand (number), push it onto the stack;
• if you read an operator, pop the top two values, apply the operator, and push the result;
• when the input is finished, the single value left on the stack is the answer.

*Trace of `3 4 + 5 ` (top of stack shown on the right):

Read	Action	Stack
3	push 3	3
4	push 4	3, 4
+	pop 4 and 3 → 3+4=7, push 7	7
5	push 5	7, 5
*	pop 5 and 7 → 7*5=35, push 35	35

Result = 35. ✓ (It matches the infix value of `(3 + 4) * 5`.)

Order matters for − and ÷. The first value popped is the right operand. For `6 2 -` you compute 6 − 2 = 4, not 2 − 6. (For + and * the order makes no difference.)

Both translate high-level code, but they suit different situations.

	Interpreter	Compiler
When translation happens	line by line, at run time	whole program, in advance
Output	none stored (re-translated each run)	a saved object/executable file
Errors	stops and reports at the first error	reports errors after compiling
Speed of running	generally slower	generally faster
Best for	writing & debugging	distributing the finished program

During development an interpreter shines: you can edit a statement and run again without recompiling the whole program, and errors are reported as soon as they are reached, giving a fast debug cycle.

For distribution a compiler is better: the program is translated once into a standalone executable that runs quickly and repeatedly without re-translation, and because only the compiled code is shared, the source code stays hidden.

This is why some development tools provide both — interpret while building, compile when finished.