[1.0] Language Processors
05/06/2021 • 20 minutes to read
Last updated
Was this helpful?
05/06/2021 • 20 minutes to read
Last updated
Was this helpful?
There are two main types of language processors, compilers and interpreters. The compiler's job is to take a source program written in one language -- typically referred to as the source language -- and translate it into another language, typically much lower-level, such as Assembly or Common Intermediate Language - the target language (see fig. 1). One of the main features of a compiler that is often overlooked is the ability to appropriately report any errors that are found during the translation process to the user.
source code -> compiler -> binary code -> executable user-input -> executable -> output The example above shows the process of source code to executable using a compiler, then a user input to output. This output could be text or a whole application.
An interpreter is another type of language processor we'll talk about. However, I won't focus too heavily on interpreters, I'd just like to give you an idea of them. Contrary to a compiler, an interpreter simply takes source code, translates it, then executes it on the spot, instead of generating or emitting an executable to disk.
You may be looking at this saying "now wait a minute, I thought there was no executable with interpreters?", and you're right for thinking that, but this isn't the type of executable you're thinking of, it's an executor, simply put, your translated source code still has to be output somewhere, but where? That's when the executor kicks in, the executor outputs your interpreters' results somewhere. A good example of this would be JavaScript code in the browser.
Note - another great example of executors is with REPLs (Read-Evaluate-Print-Loop), the executor will handle printing your output to the console.
The last example we'll be looking at is slightly more complex. If you've ever used C# then you know that "dll" files are produced alongside your "exe" file, that's because .NET executables are merely a dummy file that initiates the .NET Runtime to Just-in-Time Compile (JIT) your program using a Virtual Machine. Java does the same thing with the Java Virtual Machine (JVM), compiling your source code into what's known as bytecode, and for C# it would be Common Intermediate Language (CIL). The process of compiling these low-level languages into machine code is much much faster because it's known as an "Immediate Representation" and is very close to a one-to-one translation.
If you're confused as to why these languages create yet another layer of abstraction then you're not alone. The reason is cross-platform support, not all platforms/operating systems support the same instruction set, it's the job of the Just-in-Time Compiler and Runtime to handle converting the "Intermediate Representation" into machine code for the computer to execute natively. Languages such as C/C++ oftentimes need to modify their source code to compile for a different platform because not all code is cross-platform when you don't have a Virtual Machine to execute on.