Assemblers, compilers and interpreters
Introduction
We have already seen that processors can only run machine code instructions. If a program is written in a high level language, or indeed an assembly language, then it has to be translated into machine code instructions before the processor can run it. There are three types of translators: assemblers, compilers and interpreters.
Assembler
An assembler is the type of translator that converts assembly programs into machine code instructions. We saw in a previous section what part of an assembly program might look like. It is made up of 'mnemonics'. These help the programmer remember instructions.
ADD #344A
DEC IY
CALL Page
LD B, #1195
Although it may not appear so at first, these mnemonics are quite close to machine code. Each of these assembly program instructions in general can be converted to just one machine code instruction by the assembler so in general, these types of programs run very quickly compared to compiled or interpreted programs.
Compiler
Programs written in some high level languages are 'compiled' to get them into object code, which the processor can then use. A compiler is a type of translator, which takes an entire program after it is finished (the source code) and converts it into object code in one complete go. Unlike assemblers, a single keyword in a compiled program will get converted into many machine code instructions. If there are any problems with the code, the compiler will report these problems at the end of the compilation process. If the programmer makes any corrections, then the whole program has to be re-compiled again. Once compiled with no errors, the object code can then be run by the processor.
Interestingly, the object code is what you would buy in a shop when you buy a game, for example. Once you have the object code, it will run without the compiler. The compiler's job is finished once it has translated the code. You can therefore put the object code (but not the original source code) on a DVD and sell it. If anyone tries to view the object code to see how the program was written, they won't get very far! All they will see is a lot of ones and zeros. Getting it back to the original source code (called 'reverse engineering') is very difficult to do.
Interpreter
Programs written in some high level languages are 'interpreted' rather than compiled. The key difference here is that the first line of the source code is translated and then run by the processor, and then the second line is translated and run by the processor, and then the third and so on, until the program has finished. (Compilers turn all of the source code into object code in one go first and then run it). Unlike assemblers, a single keyword in an interpreted program will get converted into many machine code instructions.
Interpretation produces programs, which run much slower than compiled programs. You also have to have the interpreter program in RAM at the same time as the object code you are producing as it is always needed in the translation process. (In compiled programs, you only need the compiler program in RAM whilst you are converting the source code into object code - after it has finished, you can close the compiler program down and just run the object code on its own).
A key reason for using interpreted programming languages rather than faster compiled languages comes from the fact that as soon as an interpreter finds an error, it stops! That means the programmer can see exactly where there is a problem in the program, correct it, and then they can continue from that point onwards. With compiled programs, you get all the error messages at the end, sometimes they are not easy to understand or pinpoint where exactly the error is in the code and you then have to recompile all the code after each error has been corrected.
So interpreters huge benefit over compilers is that they are really good for developing programs and 'debugging' them.