Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
Interpreter (computing)
(section)
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
=== Efficiency === The main disadvantage of interpreters is that an interpreted program typically runs more slowly than if it had been [[compiler|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.<ref name="FOLDOC">{{FOLDOC|Interpreter}}</ref><ref>{{Cite web |title=Compilers vs. interpreters: explanation and differences |url=https://www.ionos.com/digitalguide/websites/web-development/compilers-vs-interpreters/ |access-date=2022-09-16 |website=IONOS Digital Guide |language=en}}</ref> Interpreting code is slower than running the compiled code because the interpreter must analyze each [[statement (computer science)|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 (program lifecycle phase)|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]].<ref name="FOLDOC" /> 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 [[Lisp (programming language)|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.{{citation needed|date=January 2013}} Many interpreters do not execute the source code as it stands but convert it into some more compact internal form. Many [[BASIC]] interpreters replace [[keyword (computer programming)|keyword]]s with single [[byte]] [[Token threading|tokens]] which can be used to find the instruction in a [[jump table]].<ref name="FOLDOC" /> A few interpreters, such as the [[PBASIC]] interpreter, achieve even higher levels of program compaction by using a bit-oriented rather than a byte-oriented program memory structure, where commands tokens occupy perhaps 5 bits, nominally "16-bit" constants are stored in a [[variable-length code]] requiring 3, 6, 10, or 18 bits, and address operands include a "bit offset". Many BASIC interpreters can store and read back their own tokenized internal representation. {| class="wikitable collapsible collapsed" style="float:right; text-align:left;" |- ! Toy [[C (programming language)|C]] expression interpreter |- | <syntaxhighlight lang="C"> // data types for abstract syntax tree enum _kind { kVar, kConst, kSum, kDiff, kMult, kDiv, kPlus, kMinus, kNot }; struct _variable { int *memory; }; struct _constant { int value; }; struct _unaryOperation { struct _node *right; }; struct _binaryOperation { struct _node *left, *right; }; struct _node { enum _kind kind; union _expression { struct _variable variable; struct _constant constant; struct _binaryOperation binary; struct _unaryOperation unary; } e; }; // interpreter procedure int executeIntExpression(const struct _node *n) { int leftValue, rightValue; switch (n->kind) { case kVar: return *n->e.variable.memory; case kConst: return n->e.constant.value; case kSum: case kDiff: case kMult: case kDiv: leftValue = executeIntExpression(n->e.binary.left); rightValue = executeIntExpression(n->e.binary.right); switch (n->kind) { case kSum: return leftValue + rightValue; case kDiff: return leftValue - rightValue; case kMult: return leftValue * rightValue; case kDiv: if (rightValue == 0) exception("division by zero"); // doesn't return return leftValue / rightValue; } case kPlus: case kMinus: case kNot: rightValue = executeIntExpression(n->e.unary.right); switch (n->kind) { case kPlus: return + rightValue; case kMinus: return - rightValue; case kNot: return ! rightValue; } default: exception("internal error: illegal expression kind"); } } </syntaxhighlight> |} An interpreter might well use the same [[lexical analysis|lexical analyzer]] and [[parser]] as the compiler and then interpret the resulting [[abstract syntax tree]]. Example data type definitions for the latter, and a toy interpreter for syntax trees obtained from [[C (programming language)|C]] expressions are shown in the box.
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)