|Difference between Interpreter and DR firstname.lastname@example.org (Greg Simon) (1996-10-16)|
|Difference between Interpreter and DR email@example.com (Stephen J Bevan) (1996-10-18)|
|Re: Difference between Interpreter and DR firstname.lastname@example.org (Christian Smith) (1996-10-18)|
|Re: Difference between Interpreter and DR email@example.com (1996-10-20)|
|Re: Difference between Interpreter and DR firstname.lastname@example.org (1996-10-25)|
|From:||email@example.com (David Keppel)|
|Date:||20 Oct 1996 16:55:15 -0400|
|Organization:||Computer Science & Engineering, U of Washington, Seattle|
Greg Simon <firstname.lastname@example.org> wrote:
>I'm confused about the difference between an interpreter and a DR
As our moderator points out, there's various ways to look at it, and
the answer depends on your view.
The purpose of the tool (interpreter/compiler) is to take a program
represented in some form and execute it. That implies translation from
the input form into zero or more intermediate forms that are finally
executed by an "engine"; the "engine" may itself be either software
Likewise, the notion of "runtime" can be fudged a bit: the "running"
time potentially starts as soon as some part of the program is created
and potentially lasts until the last of it is deleted. In short, when
a translator is busy folding constants, is it translating the program,
or executing it?
People often use a term in the general sense but have a specific model
in mind. Probably the most common specific model is that "engine" is
hardware that executes an instruction set and that "runtime" starts when
there is an action to explicitly invoke a code fragment.
In the Shade paper (blowing my own horn again!) we used the terms
"decode-and-dispatch interpreter" for tools that process the input
code form one token at a time and discard all intermediate forms before
executing the next token; "predecode interpreter" for tools that produce
an intermediate form and then save that form for reuse; "static compiler"
for tools that produce a form as output but do not execute the program
all the way to the final desired result; and "dynamic compiler" for tools
that produce machine code as the intermediate form and then execute that
Shade reads SPARC machine code and produces and executes SPARC machine
code (there were also internal versions that read other input forms).
Thus, it appears to be a "dynamic compiler". However, Shade can run Shade
(can run Shade can run Shade ...) so any invocation might actually be
producing an intermediate form that gets interpreted rather than machine
code -- thus, depending on your view, a single executable (Shade) might
be simultaneously running the same code as both a dynamic compiler and
as a predecode interpreter!
If you really want to get into it, some of the theory of reflective
computing is pretty deep in this area.
For further reading, I'd see (in addition to the previously-mentioned
Mimic paper by Cathy May, a must-read; does anybody know how to get
in touch with her?):
A Bob Cmelik
%A David Keppel
%T Shade: A Fast Instruction-Set Simulator for Execution Profiling
%J Proceedings of the 1994 ACM SIGMETRICS Conference
on the Measurement and Modeling of Computer Systems
%D May 1994
There's some longer stuff described under the Shade Web page at
and more about interpretatin and compilation as applied to instruction
set simulation under
;-D on ( You're confused because it's confusing ) Pardo
[Haven't heard from her since she went back to IBM from Yale close to 15
years ago. -John]
Return to the
Search the comp.compilers archives again.