Interpreter (computing)
From Wikipedia, the free encyclopedia
In computer science, an interpreter normally means a computer program that executes, i.e. performs, instructions written in a programming language. An interpreter may be a program that either
- executes the source code directly
- translates source code into some efficient intermediate representation (code) and immediately executes this
- explicitly executes stored precompiled code[1] made by a compiler which is part of the interpreter system
Perl, Python, MATLAB, and Ruby are examples of type 2, while UCSD Pascal and Java are type 3: Source programs are compiled ahead of time and stored as machine independent code, which is then linked at run-time and executed by an interpreter and/or compiler (for JIT systems). Some systems, such as Smalltalk, and others, may also combine 2 and 3.
While interpretation and compilation are the two principal means by which programming languages are implemented, these are not fully distinct categories, one of the reasons being that most interpreting systems also perform some translation work, just like compilers. The terms "interpreted language" or "compiled language" merely mean that the canonical implementation of that language is an interpreter or a compiler; a high level language is basically an abstraction which is (ideally) independent of particular implementations.
Contents |
[edit] Bytecode interpreters
There is a spectrum of possibilities between interpreting and compiling, depending on the amount of analysis performed before the program is executed. For example, Emacs Lisp is compiled to bytecode, which is a highly compressed and optimized representation of the Lisp source, but is not machine code (and therefore not tied to any particular hardware). This "compiled" code is then interpreted by a bytecode interpreter (itself written in C). The compiled code in this case is machine code for a virtual machine, which is implemented not in hardware, but in the bytecode interpreter. The same approach is used with the Forth code used in Open Firmware systems: the source language is compiled into "F code" (a bytecode), which is then interpreted by a virtual machine.
Control tables - that do not themselves necessarily ever need to pass through a compilation phase - dictate appropriate algorithmic control flow via customized interpreters in similar fashion to bytecode interpreters.
[edit] Efficiency
The main disadvantage of interpreters is that when a program is interpreted, it typically runs more slowly than if it had been compiled. The difference in speeds could be tiny or great; often an order of magnitude and sometimes more. It generally takes longer to run a program under an interpreter than to run the compiled code but it can take less time to interpret it than the total time required to compile and run it. This is especially important when prototyping and testing code when an edit-interpret-debug cycle can often be much shorter than an edit-compile-run-debug cycle.
Interpreting code is slower than running the compiled code because the interpreter must analyze each statement in the program each time it is executed and then perform the desired action, whereas the compiled code just performs the action within a fixed context determined by the compilation. This run-time analysis is known as "interpretive overhead". Access to variables is also slower in an interpreter because the mapping of identifiers to storage locations must be done repeatedly at run-time rather than at compile time.
There are various compromises between the development speed when using an interpreter and the execution speed when using a compiler. Some systems (such as some LISPs) allow interpreted and compiled code to call each other and to share variables. This means that once a routine has been tested and debugged under the interpreter it can be compiled and thus benefit from faster execution while other routines are being developed. Many interpreters do not execute the source code as it stands but convert it into some more compact internal form. For example, some BASIC interpreters replace keywords with single byte tokens which can be used to find the instruction in a jump table. An interpreter might well use the same lexical analyzer and parser as the compiler and then interpret the resulting abstract syntax tree.
[edit] Advantages and disadvantages of using interpreters
Programmers usually write programs in high level code which the CPU cannot execute. So this source code has to be converted into machine code. This conversion is done by a compiler or an interpreter. A compiler makes the conversion just once, while an interpreter typically converts it every time a program is executed (or in some languages like early versions of BASIC, every time a single instruction is executed).
[edit] Development cycle
During programs development the programmer makes frequent changes to source code. A compiler needs to make a compilation of the altered source files, and link the whole binary code before the program can be executed. An interpreter usually just needs to translate to an intermediate representation or not translate at all, thus requiring less time before the changes can be tested.
This often makes interpreted languages generally easier to learn and find bugs and correct problems. Thus simple interpreted languages tend to have a friendlier environment for beginners.
[edit] Distribution
A compiler converts source code into binary instruction for a specific processor's architecture, thus making it less portable. This conversion is made just once, on the developer's environment, and after that the same binary can be distributed to the user's machines where it can be executed without further translation.
An interpreted program can be distributed as source code. It needs to be translated in each final machine, which takes more time but makes the program distribution independent to the machine's architecture.
[edit] Execution environment
An interpreter will make source translations during runtime. This means every line has to be converted each time the program runs. This process slows down the program execution and is a major disadvantage of interpreters over compilers. Another main disadvantage of interpreter is that it must be present on the machine as additional software to run the program.
[edit] Abstract Syntax Tree interpreters
In the spectrum between interpreting and compiling, another approach is transforming the source code into an optimized Abstract Syntax Tree (AST) then executing the program following this tree structure.[2] In this approach, each sentence needs to be parsed just once. As an advantage over bytecode, the AST keeps the global program structure and relations between statements (which is lost in a bytecode representation), and provides a more compact representation.[3]
Thus, AST has been proposed as a better intermediate format for Just-in-time compilers than bytecode. Also, it allows to perform better analysis during runtime. An AST-based Java interpreter has been proved to be faster than a similar bytecode-based interpreter,[4] due to the more powerful optimizations allowed by having the complete structure of the program, as well as higher level typing, available during execution.
[edit] Just-in-time compilation
Further blurring the distinction between interpreters, byte-code interpreters and compilation is just-in-time compilation (or JIT), a technique in which the intermediate representation is compiled to native machine code at runtime. This confers the efficiency of running native code, at the cost of startup time and increased memory use when the bytecode or AST is first compiled. Adaptive optimization is a complementary technique in which the interpreter profiles the running program and compiles its most frequently-executed parts into native code. Both techniques are a few decades old, appearing in languages such as Smalltalk in the 1980s.
Just-in-time compilation has gained mainstream attention amongst language implementers in recent years, with Java, Python and the .NET Framework all now including JITs.
[edit] Punched card interpreter
The term "interpreter" often referred to a piece of unit record equipment that could read punched cards and print the characters in human-readable form on the card. The IBM 550 Numeric Interpreter and IBM 557 Alphabetic Interpreter are typical examples from 1930 and 1954, respectively.
[edit] Another definition of interpreter
Instead of producing a target program as a translation, an interpreter performs the operation implied by the source program. For an assignment statement, for example, an interpreter might build a tree and then carry out the operation at the node as it "walks" the tree.
| Interpreters are frequently used to execute command languages, since each operator executed in command language is usually an invocation of a complex routine such as an editor or compiler. |
[edit] See also
- Command line interpreter
- Interpreted languages
- Compiled languages
- Dynamic compilation
- Partial evaluation
- Metacircular Interpreter
[edit] Notes and references
- ^ In this sense, the CPU is also an interpreter, of machine instructions.
- ^ AST intermediate representations, Lambda the Ultimate forum
- ^ A Tree-Based Alternative to Java Byte-Codes, Thomas Kistler, Michael Franz
- ^ Trees Versus Bytes, BComp Honours thesis by Kade Hansson
[edit] External links
- DrPubaGump A tiny interpreter written in Scheme, which provides to interpret PUBA-GUMP (a subset of BASIC) in Scheme
- IBM Card Interpreters page at Columbia University
This article was originally based on material from the Free On-line Dictionary of Computing, which is licensed under the GFDL.
