Learn
4.2.3–4 | COMPILER AND INTERPRETER
01 | WHY DOES HIGH-LEVEL CODE NEED HELP?
Programmers write source code in a high-level language. The processor ultimately executes machine instructions, so a suitable translation or execution system is needed.
The two approaches in this lesson are a compiler and an interpreter. Both allow high-level programs to run, but they organise translation and execution differently.
An assembler is different: it translates assembly language into machine code. A compiler or interpreter works with high-level code in the syllabus model.
02 | THE COMPILER: TRANSLATE BEFORE EXECUTION
A compiler translates the whole source program before the resulting program is executed. In the syllabus model, successful compilation produces an executable file.
Programmer’s high-level instructions
↓ Compile the program
Translated program for the target system
↓ Run after successful compilation
Produced during execution
The compiler can analyse the source and report errors found across it. Compilation does not mean the program’s calculations have already been carried out.
Once a suitable executable has been produced, it can be run again without recompiling unchanged source. If the source changes, it must be compiled again to create an updated executable.
03 | THE INTERPRETER: TRANSLATE AND EXECUTE AS IT GOES
An interpreter translates and executes code line by line, according to the syllabus’s simplified description.
Take the next instruction to execute
↓ Translate / interpret
Carry out that statement’s operation
↓ Continue, or stop at an error
Follow the program’s control flow
It does not first produce a separate standalone executable in this model. The interpreter is needed when the source program is run.
“Line by line” does not mean every source line executes once from top to bottom. Loops repeat statements, conditions can skip them, and function calls change the execution sequence.
04 | DIFFERENT ERROR REPORTING
In the syllabus model, a compiler provides an error report for the whole source when translation errors are detected. The programmer corrects them and compiles again.
An interpreter stops execution when it finds an error and reports that problem. The programmer corrects it and reruns the program; a later problem may then be encountered.
| Compiler model | Interpreter model |
|---|---|
| Analyse the source before running the resulting executable | Translate and execute statements as the program runs |
| Report detected translation errors across the source | Report an encountered error and stop at that point |
| Correct source and compile again | Correct source and rerun |
A compiler may be unable to analyse later code reliably after some errors. Neither approach guarantees the detection of every logic error.
05 | WORKED ERROR EXAMPLE
Use this invented teaching language. PRINT displays text; DIVIDE evaluates a calculation. This is pseudocode, not runnable code for a named language.
1 PRINT "Start" 2 DIVIDE 8 BY 0 3 PRINT "Finished"
In a simple interpreter model, line 1 displays Start. At line 2, the invalid division is encountered, an error is reported and execution stops. Line 3 is not reached unless the program is corrected or the error is handled.
A runtime error is different from a translation error. A compiler may flag this obvious constant division, but compilation in general does not prove that a program can never divide by zero. If a divisor comes from user input, the fault may occur only when the executable runs.
This example illustrates stopping at an execution error. A real interpreter may also check syntax before executing any statements, so do not use this example to claim every interpreter always displays output before every type of error.
06 | THREE TYPES OF FAULT
| Fault type | Meaning | Example |
|---|---|---|
| Syntax error | Code violates the language’s grammar | A required bracket or keyword is missing |
| Runtime error | A problem occurs during execution | A calculation attempts division by zero |
| Logic error | The program runs but does the wrong thing | Use subtraction when the task requires addition |
Compilers and interpreters can report problems they detect. Testing is still needed to check behaviour and results.
For example, total = price - quantity may be syntactically valid, but it is wrong if the intended calculation is price multiplied by quantity.
07 | RUNNING THE PROGRAM AGAIN
Compiled model: after successful compilation, the executable can run repeatedly without repeating that translation. This can make execution efficient, although compilation itself takes time.
Interpreted model: the interpreter remains part of execution each time the program runs. Repeated interpretation can add overhead.
Important limit: real implementations often combine approaches, including bytecode, caching or just-in-time compilation. The syllabus comparison is a simplified model, not a rule that every interpreted program is slower than every compiled one.
08 | DEVELOPMENT AND DEBUGGING
An interpreter can support quick experimentation because a programmer can change source and run it without a separate executable-building step. Stopping at an encountered error can help identify the point reached.
A compiler can report several detected source errors before the program runs, letting the programmer correct them together. Compiled programs can also be debugged using suitable tools.
Do not say compiled programs cannot be debugged. Debugging depends on the tools and program structure as well as the translation approach.
The next lesson explores IDE features that help with editing, testing and debugging.
09 | DISTRIBUTION AND COMPATIBILITY
A compiled executable can often be distributed without distributing the original source or requiring the end user to install the compiler. It must still match the target system and may need supporting libraries.
In the interpreted model, the user needs a suitable interpreter or runtime and access to the code to be executed. That code can often be used on different systems if compatible support is available.
A compiled executable is not automatically portable across processor architectures or operating systems. High-level source may need recompilation for another target.
Not distributing source is also not a guarantee of secrecy: an executable can still be inspected or reverse-engineered.
10 | ADVANTAGES AND DISADVANTAGES
| Point | Compiler model | Interpreter model |
|---|---|---|
| Translation | Whole program before execution | Translate and execute as it goes |
| Output | Separate executable after successful compilation | No separate standalone executable in this model |
| Errors | Report detected source errors before executable runs | Stop at an encountered execution error |
| Repeated runs | Run translated executable without recompiling unchanged source | Interpreter involved on each run |
| Development | Changes require a new compilation step | Can support quick changes and reruns |
| Distribution | Suitable executable may run without the compiler | Suitable interpreter/runtime required |
| Typical trade-off | Translation takes time; resulting execution can be efficient | Convenient development; interpretation can add overhead |
Exam-style explanation: compilation translates the program before execution, so unchanged code does not need to be translated again each time its executable runs. Interpretation translates and executes as it goes, which can support quick testing but introduces work during execution.
11 | CHOOSE FOR THE CONTEXT
Experimenting with a short script: an interpreted workflow can suit frequent small changes and quick feedback.
Distributing a program for a known target: a compiled executable can be useful when users should run it without installing the source-language compiler.
Justify the choice through requirements such as development speed, target compatibility and repeated execution. A language may have several implementations, so avoid treating every language as permanently restricted to one approach.
12 | COMMON MISTAKES
- The compiler executes every calculation during translation: it produces code; execution produces the program’s behaviour.
- Compilation finds every error: runtime and logic faults can remain.
- The interpreter always executes source in numerical line order: control flow includes loops, conditions and functions.
- An executable requires the compiler every time it runs: a successfully built executable can run without recompiling unchanged source.
- No compiler means no dependencies: an executable may still need libraries or a runtime.
- Every interpreter behaves identically: real implementations can include preliminary checks and compilation stages.
- A compiler and assembler translate the same source language: the assembler works with assembly.