interpreter

programming A program which executes other programs. This

is in contrast to a compiler which does not execute its

input program (the "source code") but translates it into

executable "machine code" (also called "object code")

which is output to a file for later execution. It may be

possible to execute the same source code either directly by an

interpreter or by compiling it and then executing the machinecode produced.

It 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 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 analyse 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 index into a jumptable. An interpreter might well use the same lexicalanalyser and parser as the compiler and then interpret the

resulting abstract syntax tree.

There is thus 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 "byte-code" which is a highly compressed and

optimised representation of the Lisp source but is not machine

code (and therefore not tied to any particular hardware).

This "compiled" code is then executed (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 byte-code

interpreter.

See also partial evaluation.

(1995-01-30)