العربية
中国
Français
Deutsch
Ελληνική
हिन्दी
Italiano
日本語
Português
Русский
EspañolINTERPRETER (COMPUTING)
In computer science, an 'interpreter' is a computer program that executes, or performs, instructions written in a computer programming language. Interpretation is one of the two major ways in which a programming language can be implemented, the other being compilation.
The term ''interpreter'' may refer to a program that executes source code that has already been translated to some intermediate form, or it may refer to the program that performs both the translation and execution (e.g., many BASIC implementations).
An interpreter needs to be able to analyze, or parse, instructions written in the source language. It also needs to represent any program state, such as variables or data structures, that a program may create. It needs to be able to move around in the source code when instructed to do so by control flow constructs such as loops or conditionals. Finally, it usually needs to interact with an environment, such as by doing input/output with a terminal or other user interface device.
Any language can be implemented via an interpreter or compiler; there is no such thing as an "interpreted language" or "compiled language", only interpreted and compiled implementations of a language. Indeed, a single program may contain parts that are implemented via interpreter and a compiler, e.g., some Lisp systems. Nonetheless, certain languages are best known for having particular kinds of implementations, and because of this are often termed "compiled" or "interpreted" languages (although technically these terms are more accurately reserved for implementations).
Many "interpreters" today include some element of compilation as well, such as a bytecode compiler, as found in Perl and Python. In such an arrangement, source code is compiled to a more efficient intermediate form, which is then interpreted.
The main disadvantage of interpreters is that when a program is interpreted, it runs slower 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. 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 (e.g., 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.
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.
Just-in-time compilation, or JIT, refers to a technique where bytecode is compiled to native machine code at runtime; giving the high execution speed of running native code at the cost of increased startup-time as the bytecode is compiled. It has gained attention in recent years, which further blurs the distinction between interpreters, byte-code interpreters and compilation. JIT is available for both the .NET and Java platforms. The JIT technique is a few decades old, appearing in languages such as Smalltalk in the 1980s.
''There is an example of a simple program and interpreter in the Literate programming article.'' See also: ''Lisp in Small Pieces''
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 along the top edge of the card. The IBM 550 Numeric Interpreter and IBM 557 Alphabetic Interpreter are typical examples from 1930 and 1954, respectively.
★ partial evaluation
★ interpreted languages
★ compiled languages
★ dynamic compilation including the section on incremental compilation.
★ Threaded code, a compact form of code that depends on a simple interpreter.
★ Metacircular Interpreter
★ IBM Card Interpreters page at Columbia University
The term ''interpreter'' may refer to a program that executes source code that has already been translated to some intermediate form, or it may refer to the program that performs both the translation and execution (e.g., many BASIC implementations).
| Contents |
| Structure of an interpreter |
| Interpreted vs compiled languages |
| Efficiency |
| Bytecode interpreter |
| Just-in-time compilation |
| Example of a simple interpreter |
| Punched card interpreter |
| See also |
| External links |
Structure of an interpreter
An interpreter needs to be able to analyze, or parse, instructions written in the source language. It also needs to represent any program state, such as variables or data structures, that a program may create. It needs to be able to move around in the source code when instructed to do so by control flow constructs such as loops or conditionals. Finally, it usually needs to interact with an environment, such as by doing input/output with a terminal or other user interface device.
Interpreted vs compiled languages
Any language can be implemented via an interpreter or compiler; there is no such thing as an "interpreted language" or "compiled language", only interpreted and compiled implementations of a language. Indeed, a single program may contain parts that are implemented via interpreter and a compiler, e.g., some Lisp systems. Nonetheless, certain languages are best known for having particular kinds of implementations, and because of this are often termed "compiled" or "interpreted" languages (although technically these terms are more accurately reserved for implementations).
Many "interpreters" today include some element of compilation as well, such as a bytecode compiler, as found in Perl and Python. In such an arrangement, source code is compiled to a more efficient intermediate form, which is then interpreted.
Efficiency
The main disadvantage of interpreters is that when a program is interpreted, it runs slower 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. 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 (e.g., 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.
Bytecode interpreter
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.
Just-in-time compilation
Just-in-time compilation, or JIT, refers to a technique where bytecode is compiled to native machine code at runtime; giving the high execution speed of running native code at the cost of increased startup-time as the bytecode is compiled. It has gained attention in recent years, which further blurs the distinction between interpreters, byte-code interpreters and compilation. JIT is available for both the .NET and Java platforms. The JIT technique is a few decades old, appearing in languages such as Smalltalk in the 1980s.
Example of a simple interpreter
''There is an example of a simple program and interpreter in the Literate programming article.'' See also: ''Lisp in Small Pieces''
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 along the top edge of the card. The IBM 550 Numeric Interpreter and IBM 557 Alphabetic Interpreter are typical examples from 1930 and 1954, respectively.
See also
★ partial evaluation
★ interpreted languages
★ compiled languages
★ dynamic compilation including the section on incremental compilation.
★ Threaded code, a compact form of code that depends on a simple interpreter.
★ Metacircular Interpreter
External links
★ IBM Card Interpreters page at Columbia University
This article provided by Wikipedia. To edit the contents of this article, click here for original source.
psst.. try this: add to faves
