> For the complete documentation index, see [llms.txt](https://waifushork.gitbook.io/fundamentals-on-building-customizable-compilers/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://waifushork.gitbook.io/fundamentals-on-building-customizable-compilers/introduction/1.0-language-processors.md). # \[1.0] Language Processors 05/06/2021 • 20 minutes to read ## Compilers 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.
(Figure 1)
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. ## Interpreters 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. ![(Figure 2)](https://2672771087-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MZIKsr7SRbZdC9diYtD%2F-MZzjnKPPgXjU7TMrmFo%2F-MZzn4qaqNVSdLtOfxwo%2FExample%20Two\(1\).png?alt=media\&token=f2890b20-135a-45b6-89b2-2677f6455a29) 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. ## Hybrid Compilers 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. ![(Figure 3)](https://2672771087-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MZIKsr7SRbZdC9diYtD%2F-MZzjnKPPgXjU7TMrmFo%2F-MZzmuvqFCRzPar-pUBq%2FExample%20Three.png?alt=media\&token=8d1f5612-4691-4c98-982c-cf80b1cbfa8c) 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.