interpreter
An interpreter is a computer program that apparently executes a sequence of instructions directly, the format of the instructions being specified. The interpreter reads in one or more source files , analyzes them and then executes them instruction by instruction by translating them into machine code that a computer system can execute directly. Interpreters are noticeably slower than compilers , but generally provide better error analysis.
Interpreters are used in both programming languages and computer programs.
use
programming
When programming, an interpreter is almost always part of software development .
In their pure form, compilers - in contrast to interpreters - translate the instructions from the source files in one or more passes into machine code for a previously defined target system and thus create an executable computer program . However, there is already a distinction between compiler-compiler and interpreter-compiler, just as there is also interpreter-interpreter and compiler-interpreter.
"Any good software engineer will tell you that a compiler and an interpreter are interchangeable."
"Any good software developer will tell you that compilers and interpreters are interchangeable."
If the last stage is an interpreter, the source file is translated while the program is running .
Programming languages that do not compile the source text, but always interpret an input or a source file, are also referred to as "interpreter language " or script language . Classic interpreter languages are e.g. B. BASIC like GW-BASIC , Tcl or JavaScript . For some other programming languages, a programmer can choose between interpreter and compiler. In some programming languages, a bytecode is also generated as an intermediate code , which has already been optimized, but once again requires an interpreter on the target system for execution. There are also externally developed compilers for what are actually pure interpreter languages.
Computer programs
Scripts for command line interpreters , such as batch files or Unix shell scripts, are also executed by an interpreter. So that the script does not have to be specified as a command line parameter , there is the so-called shebang on Unix-like systems and shells - the script uses the shell to call the appropriate interpreter itself, so to speak.
Computer programs are also referred to as interpreters as soon as the code cannot or should not be executed directly by the computer system. This is u. a. This is also the case with emulators , which analyze and rewrite machine code for other computer systems and execute it in an interpreted manner for the computer system on which they are currently running. However, this does not include virtual machines , since they execute large parts of the machine code of the guest system directly on the host system without being interpreted. Also game engines can be interpreter when the actual game data, usually as bytecode , on the respective platform running interpreted.
properties
Interpreters are mostly available in the machine language of the target processor, but they can also be available in an interpreter language themselves. The biggest disadvantage is the lower execution speed compared to a compiler. This is due to the fact that the compiler can take the time during the compilation process to optimize the code so that it is executed faster on the respective target system. Such optimizations are time-consuming, however, so that an interpreter usually carries out a direct conversion to machine code, which is, however, again slower than the optimized code by the compiler.
Interpreted code is roughly five to 20 times slower than compiled code.
In addition to better error analysis, the advantages of interpreted code include independence from a previously defined computer architecture - because interpreted code runs on every system on which there is an interpreter for it.
Speed increases
A compromise solution is a just-in-time compiler (JIT compiler) in which the program is only translated into machine code at runtime , but directly. The translated code is then executed directly by the processor. Due to the intermediate storage of the machine code, program parts run through several times only have to be translated once. The JIT compiler also enables the binary code to be optimized. However, JIT compilers can only run on a certain computer architecture because they generate machine code for this architecture and require far more memory than pure interpreters.
Intermediate code
Another intermediate stage is bytecode interpreters. The source text is translated (in advance or at runtime) into a simple intermediate code, which is then executed by an interpreter - often referred to as a virtual machine. This is e.g. This is the case , for example, with Java through the Java Virtual Machine (JVM). It corresponds to the compiler-interpreter concept, as the intermediate code has already been partially optimized (source code → compiler → intermediate code as bytecode → interpreter → execution on the target system).
In the 1980s in particular, the intermediate stage was used to convert commands into easier decodable tokens at the time of input , which were then converted back into plain text during the (list) output. In addition to the increase in speed, the compression of the source code was a weighty argument. In principle, it was also possible to use native-speaking keywords if the data exchange was carried out on the basis of the tokenized source program.
Mixed forms
Since JIT code is not automatically faster than interpreted code, some runtime environments use a hybrid form. One example of this is the JVM. The JIT compiler is used in parallel with the interpreter, whereby the faster execution path "wins".
Interpreter languages
Interpreter languages are often programming languages whose main or first implementation is an interpreter, as the opposite of a programming language that uses a compiler (compiler language). Basically, a programming language is not tied to one type of implementation and there are mixed forms of the two opposing approaches.
However, there are also programming languages that have been designed with later implementation in mind; this can still be seen well in some older languages. Because of the low performance of early computers, interpreters had to be kept as simple and small as possible in order not to consume too much computing time and memory. Compilers, on the other hand, could consume a lot of computing time and also a lot of RAM because they were no longer active when the program was running. Therefore, languages that should be interpreted have been designed so that they can be easily analyzed and executed. Whereas languages that were supposed to be compiled could also contain constructs that were laborious to analyze and process. Today this only plays a role in the very rarest of cases when designing a programming language.
Various implementations exist for some languages. The Scheme language stands out here, for which there is a vast number of implementations based on many different concepts. Here is another example: The programming language C is very much designed to be compiled. But there are still interpreters like the CINT and the Ch for this language, even though C is often cited as a prime example of a language that is not an "interpreter language" but a "compiler language".
APL , BASIC , Forth , Perl , Python , Ruby , PHP and many others are known as interpreter languages . The scripting languages are sometimes mentioned as a sub or related category of the interpreter languages .
Well-known programming languages that are usually translated into bytecode are Java , C # , Perl and Python.
For some languages (such as Smalltalk ) there are interpreters, bytecode interpreters, JIT compilers or compilers in other languages (e.g. to C or .NET ), depending on the provider .
The transition between pure interpreters and pure compilers is fluid.
Individual evidence
- ^ A b Alfred V. Aho, Monica S. Lam, Ravi Sethi, Jeffrey D. Ullman: Compiler: Principles, Techniques and Tools . Pearson Deutschland GmbH, 2008, ISBN 978-3-8273-7097-6 , p. 1253 ( limited preview in Google Book Search).
- ^ Julius T. Tou: Software Engineering . Proceedings of the Third Symposium on Computer and Information Sciences held in Miami Beach, Florida, December, 1969. Academic Press, New York, London 1970, ISBN 978-0-323-15744-5 , pp. 288 (English, limited preview in Google Book search).
- ↑ What is an interpreter? “XOVI. Retrieved May 29, 2019 .
- ↑ a b Michael Bürger: Interpretersprachen. Retrieved May 29, 2019 .
- ^ A b David A. Watt: Compiler Construction . 9th International Conference, CC 2000. In: Lecture Notes in Computer Science, Volume 1781 . Springer-Verlag, Berlin, Heidelberg, New York 2000, ISBN 978-3-540-67263-0 , pp. 300 (English, limited preview in Google Book Search).
- ↑ R. Nageswara Rao, Kogent Solutions Inc .: Core Java: An Integrated Approach . Covers Concepts, Programs and Interview Questions. Dreamtech Press, New Delhi 2008, ISBN 978-81-7722-836-6 , pp. 664 (English, limited preview in Google Book search).
- ^ Christian Wagenknecht, Michael Hielscher: Formal languages, abstract automata and compilers . Textbook and workbook for basic studies and advanced training. Springer-Verlag, 2009, ISBN 3-8348-0624-2 ( limited preview in Google book search).