Re: p-code compilers (Scott Amspoker)
31 Jan 1999 01:09:32 -0500

          From comp.compilers

Related articles
[3 earlier articles]
Re: p-code compilers (Derek Ross) (1999-01-23)
Re: p-code compilers (1999-01-25)
Re: p-code compilers (Toon Moene) (1999-01-25)
Re: p-code compilers (Aaron F. Stanton) (1999-01-27)
Re: p-code compilers (1999-01-27)
Re: p-code compilers (Robert Howard) (1999-01-31)
Re: p-code compilers (1999-01-31)
| List of all articles for this month |

From: (Scott Amspoker)
Newsgroups: comp.compilers
Date: 31 Jan 1999 01:09:32 -0500
Organization: Compilers Central
References: 99-01-078 99-01-102
Keywords: interpreter

"Aaron F. Stanton" <> 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 | | |

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.