Re: Compiler or interpreter?

glen herrmannsfeldt <>
Thu, 17 Jun 2010 20:12:22 +0000 (UTC)

          From comp.compilers

Related articles
Compiler or interpreter? (glen herrmannsfeldt) (2010-06-13)
Re: Compiler or interpreter? (2010-06-15)
Re: Compiler or interpreter? (glen herrmannsfeldt) (2010-06-16)
Re: Compiler or interpreter? (glen herrmannsfeldt) (2010-06-17)
Re: Compiler or interpreter? (BGB / cr88192) (2010-06-18)
Re: Compiler or interpreter? (Paul Biggar) (2010-06-18)
Re: Compiler or interpreter? (Al Kossow) (2010-06-18)
Re: Compiler or interpreter? (glen herrmannsfeldt) (2010-06-18)
Re: Compiler or interpreter? (BGB / cr88192) (2010-06-19)
Re: Compiler or interpreter? (glen herrmannsfeldt) (2010-06-19)
[1 later articles]
| List of all articles for this month |

From: glen herrmannsfeldt <>
Newsgroups: comp.compilers
Date: Thu, 17 Jun 2010 20:12:22 +0000 (UTC)
Organization: NNTP Server
References: 10-06-032 10-06-035
Keywords: code, interpreter
Posted-Date: 18 Jun 2010 01:38:22 EDT

Anton Ertl <> wrote:
> glen herrmannsfeldt <> writes:
>>More specific to the above mentioned discussion, is that many of
>>the early DEC systems used threaded code. Does threaded code
>>count as compiler or interpreter?


> What you are probably thinking of when you write "true compiler" is a
> native code compiler, which generates machine code for a real machine
> (possibly indirectly through an assembler, linker, and loader).

Well, it is those posting to the PDP-11 newsgroup that are asking
about a "true compiler." I thought that this would be a better place
to find the answer, though.

Also, I note that you are the author of the quote from my previous
post. Thanks.

> The line I draw between interpreted intermediate code and native code
> is this: If the CPU executes the code directly, it is native code,
> otherwise it is interpreted code. Two tests for the difference are:

> * If the program counter of the CPU points to the code during
> execution, it is native code.

> * If CPUs with memory protection require execute permission, not just
> read permission, to execute the code, it is native code.

This makes it a little more complicated. In the case of direct
threaded code, the code that loads the addresses and branches to the
specified routines needs execute permission. (Unless a processor
included such in hardware, which would be interesting.)

> In particular, "subroutine-threaded code", which consists mainly of a
> sequence of native calls to routines of the run-time system, where
> each routine returns to the caller, is a form of native code.

I think I agree with this one. I am not sure what the DEC compilers
from years ago generated, though.

> In contrast, direct-threaded code, where the program consists of a
> sequence of addresses of run-time routines, and each run-time routine
> ends by dispatching to the run-time routine specified by the next
> address, is an interpreted intermediate code (although not necessarily
> slower than subroutine-threaded code).

It would seem that this distinction might be important on
some processors, though. It requires the ability to do an indirect
branch to an address supplied by the "data segment" of the program.

On that other hand, one could use a table of offsets into a table
of addresses, such that the actual addresses were from the "code
segment." I haven't looked in detail at the protections that
some processors now have against executing data, but I would think
that this distinction might become important.


-- glen
[On the PDP-11 we all used direct threaded code. If R5 had the
address of the next thing to do, JMP @(R5)+ would dispatch to the
routine and bump the pointer. -John]

Post a followup to this message

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