|[3 earlier articles]|
|Re: p-code compilers email@example.com (Derek Ross) (1999-01-23)|
|Re: p-code compilers firstname.lastname@example.org (1999-01-25)|
|Re: p-code compilers email@example.com (Toon Moene) (1999-01-25)|
|Re: p-code compilers firstname.lastname@example.org (Aaron F. Stanton) (1999-01-27)|
|Re: p-code compilers email@example.com (1999-01-27)|
|Re: p-code compilers firstname.lastname@example.org (Robert Howard) (1999-01-31)|
|Re: p-code compilers email@example.com (1999-01-31)|
|From:||firstname.lastname@example.org (Scott Amspoker)|
|Date:||31 Jan 1999 01:09:32 -0500|
"Aaron F. Stanton" <email@example.com> wrote:
>I'd like to throw an additional wrench into the fray if I could:
>[various observations snipped]
Having spent that last 15 years of my career implementing
interpreters, I see many subtle shades of gray in the debate (a debate
that I normally find tiresome).
I'm well aware of the various popular distinctions between compiler,
translator, and interpreter but I'll toss in my own ideas about it.
Part of the problem is that the definitions change from person to
person depending on their particular area of interest.
For someone developing a language processor, I would have to say that
the distinction has a lot to do with the "distance" between the input
and output. A compiler translates something subjectively high level
to something subjectively at least a couple of levels lower. A garden
variety translator will produce a target code that is more or less at
the same level of abstraction.
An interpreter *implies* no translation at all but is almost certain
to convert the source code to a more efficient internal format
although not subjectively much lower level. Conceptually, the source
code is directly executed. Some might argue that an interpreter is
distinguished by being able to convert the internal code back to
something resembling the original source (as some kind of litmus test
of the level of the internal format). IMHO, that may be a common
characteristic of interpreters but certainly not a requirement. The
important thing is that it at least provides the illusion of direct
To the user of a language processor, the distinction has more to do
with the execution mode of the generated code. If it is executed
directly by a CPU, then it is "compiled", otherwise it's interpreted.
I prefer to use "native" to indicate execution by the CPU.
Is Pascal-P compiled or interpreted? There is certainly some
distancing involved and the generated output is much lower level than
the source. However, it is ultimately executed by an interpreter.
How about "non-native compiler"?
C-front - translator.
Fortran-to-C - There's a lot of distancing but not a big jump to lower
levels - translator.
Java-to-bytecode - non-native compiler.
JIT compiler - poor man's native compiler.
Scott Amspoker |
Return to the
Search the comp.compilers archives again.