What are compilers, translators, interpreters, and assemblers?

Translators, compilers, interpreters and assemblers are all software programming tools that convert code into another type of code, but each term has specific meaning. All of the above work in some way towards getting a high-level programming language translated into machine code that the central processing unit (CPU) can understand. Examples of CPUs include those made by Intel (e.g., x86), AMD (e.g., Athlon APU), NXP (e.g., PowerPC), and many others. It’s important to note that all translators, compilers, interpreters and assemblers are programs themselves.

Translators
The most general term for a software code converting tool is “translator.” A translator, in software programming terms, is a generic term that could refer to a compiler, assembler, or interpreter; anything that converts higher level code into another high-level code (e.g., Basic, C++, Fortran, Java) or lower-level (i.e., a language that the processor can understand), such as assembly language or machine code. If you don’t know what the tool actually does other than that it accomplishes some level of code conversion to a specific target language, then you can safely call it a translator.

Compilers
Compilers convert high-level language code to machine (object) code in one session. Compilers can take a while, because they have to translate high-level code to lower-level machine language all at once and then save the executable object code to memory. A compiler creates machine code that runs on a processor with a specific Instruction Set Architecture (ISA), which is processor-dependent. For example, you cannot compile code for an x86 and run it on a MIPS architecture without a special compiler. Compilers are also platform-dependent. That is, a compiler can convert C++, for example, to machine code that’s targeted at a platform that is running the Linux OS. A cross-compiler, however, can generate code for a platform other than the one it runs on itself.

A cross-compiler running on a Windows machine, for instance, could generate code that runs on a specific Windows operating system or a Linux (operating system) platform. Source-to-source compilers translate one program, or code, to another of a different language (e.g., from Java to C). Choosing a compiler then, means that first you need to know the ISA, operating system, and the programming language that you plan to use. Compilers often come as a package with other tools, and each processor manufacturer will have at least one compiler or a package of software development tools (that includes a compiler). Often the software tools (including compiler) are free; after all, a CPU is completely useless without software to run on it. Compilers will report errors after compiling has finished.

Interpreters
Another way to get code to run on your processor is to use an interpreter, which is not the same as a compiler. An interpreter translates code like a compiler but reads the code and immediately executes on that code, and therefore is initially faster than a compiler. Thus, interpreters are often used in software development tools as debugging tools, as they can execute a single in of code at a time. Compilers translate code all at once and the processor then executes upon the machine language that the compiler produced. If changes are made to the code after compilation, the changed code will need to be compiled and added to the compiled code (or perhaps the entire program will need to be re-compiled.) But an interpreter, although skipping the step of compilation of the entire program to start, is much slower to execute than the same program that’s been completely compiled.

Interpreters, however, have usefulness in areas where speed doesn’t matter (e.g., debugging and training) and it is possible to take the entire interpreter and use it on another ISA, which makes it more portable than a compiler when working between hardware architectures. There are several types of interpreters: the syntax-directed interpreter (i.e., the Abstract Syntax Tree (AST) interpreter), bytecode interpreter, and threaded interpreter (not to be confused with concurrent processing threads), Just-in-Time (a kind of hybrid interpreter/compiler), and a few others. Instructions on how to build an interpreter can be found on the web.[i] Some examples of programming languages that use interpreters are Python, Ruby, Perl, and PHP.

Assemblers
An assembler translates a program written in assembly language into machine language and is effectively a compiler for the assembly language, but can also be used interactively like an interpreter. Assembly language is a low-level programming language. Low-level programming languages are less like human language in that they are more difficult to understand at a glance; you have to study assembly code carefully in order to follow the intent of execution and in most cases, assembly code has many more lines of code to represent the same functions being executed as a higher-level language. An assembler converts assembly language code into machine code (also known as object code), an even lower-level language that the processor can directly understand.

Assembly language code is more often used with 8-bit processors and becomes increasingly unwieldy as the processor’s instruction set path becomes wider (e.g., 16-bit, 32-bit, and 64-bit). It is not impossible for people to read machine code, the strings of ones and zeros that digital devices (including processors) use to communicate, but it’s likely only read by people in cases of computer forensics or brute-force hacking. Assembly language is the next level up from machine code, and is quite useful in extreme cases of debugging code to determine exactly what’s going on in a problematic execution, for instance. Sometimes compilers will “optimize” code in unforeseen ways that affect outcomes to the bafflement of the developer or programmer such that it’s necessary to carefully follow the step-by-step action of the processor in assembly code, much like a hunter tracking prey or a detective following clues.

[i] “Let’s Build a Simple Interpreter”, https://ruslanspivak.com/lsbasi-part1