The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Phil Budne <>
Subject: Re: [TUHS] Compilation "vs" byte-code interpretation, was Re: Looking back to 1981 - what pascal was popular on what unix?
Date: Sun, 30 Jan 2022 20:41:11 -0500	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

> Is there consistency here?

There's a wide spectrum of strategies used for implementation of
languages, and no perfect and universally agreed on taxonomy.

	(And in networking, where there is an "International Standard"
	taxonomy, both the original ARPAnet, and the modern Internet
	don't fit into the (ISO) model!)

At ends of the spectrum you might get people to agree on the "pure
interpreter", which intreprets source code DIRECTLY, and the "native
code compiler", which generates instructions for the instruction set
of a physical computer (typically the one the compiler is running on,
with the term "cross compiler" used when the target architecture is
different than the one the compiler is running on).

I don't doubt this has been brought up many times in the "comp.compilers"

To bring the discussion back to "Unix Heritage":

The earliest Unix shells were pure interpreters
(and for all I know, most still are).

Some BASIC language systems have been pure interpreters, but it gets
murky fast; Some interpretive systems have converted source code to
tokens in memory, or even saved to disk.

Beyond pure interpreters, most interpreters perform some kind of
compilation into some alternate representation of the program often
starting (with and sometimes (LISP), ending) with a tree.  Often, the
tree is traversed to a prefix or postfix "polish" form, which might,
or might not be written out (as a byte code, or other intermediate

The earliest Unix language systems (TMG and B) on both the PDP-7 and
PDP-11 are interesting in that they output "word code" that is
assembled by as, and loaded with ld to produce "regular" executable
files which contain interpreters.

The earliest (PDP-7) Unix compilers, TMG and B both generated code for
(stack-oriented, postfix) pseudo machines (which happened to have
opcode fields the same size and position as the PDP-7 itself).

Since PDP-11 pointers can be a full 16-bit word, PDP-11 TMG and B
generate a stream of 16-bit postfix code (with pointers to interpreter
and "native code" support routines).  TMG contains an interpreter
loop, but the B interpreter is "threaded code" using machine register
r3 for the interpreter program counter, and each interpreter opcode
routine ends with "jmp *(r3)+"

I haven't examined Sixth Edition "bas" (written in assembler) closely
enough to say what kind of internal representation (if any) it uses.
"bc" generates postfix "dc" code using a yacc parser, and "sno"
appears to recursively eval a tree.

Seventh Edition awk looks to recursively execute a tree generated by a
yacc parser.

Compilers on older/smaller systems were sometimes divided into
multiple passes and wrote intermediate representations to disk, and
such output _could_ have been interpreted.

Language processors which output source code for another language (on
heritage Unix; struct, ratfor, and cfront for early C++) are usually
called preprocessors.

So...  Interpreters and preprocessors may perform much the same work
as compilers in their front ends, may or may not be identified as

Java (and UCSD Pascal?) have compilers (to virtual machine code)
and an interpreter (for the virtual machine code).

Clear as mud?

  parent reply	other threads:[~2022-01-31  1:41 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-28 23:07 [TUHS] " Will Senn
2022-01-28 23:18 ` Dan Cross
2022-01-28 23:31   ` Will Senn
2022-01-29  0:03     ` Rob Pike
2022-01-29  0:40     ` Will Senn
2022-01-29 19:05       ` John Cowan
2022-01-29 19:36         ` arnold
2022-01-29 19:59 ` Clem Cole
2022-01-29 20:02   ` Jon Steinhart
2022-01-29 20:13   ` Bakul Shah
2022-01-29 20:30     ` Clem Cole
2022-01-29 20:34     ` Larry McVoy
2022-01-29 21:03       ` Al Kossow
2022-01-29 21:38         ` Larry McVoy
2022-01-29 22:06       ` Bakul Shah
2022-01-29 22:48         ` GREEN
2022-01-30  3:27           ` Larry McVoy
2022-01-30 16:57   ` David Barto
2022-01-30 18:07     ` [TUHS] Compilation "vs" byte-code interpretation, was " Dan Stromberg
2022-01-30 20:09       ` David Barto
2022-01-31  7:59         ` WEB
2022-01-30 22:51       ` Dan Cross
2022-01-30 23:57         ` Dan Stromberg
2022-01-31  0:23         ` Nemo Nusquam
2022-01-31  0:45           ` Steve Nickolas
2022-01-31 17:16             ` Paul Winalski
2022-01-31 20:00               ` Erik E. Fair
2022-01-31 22:45               ` Steve Nickolas
2022-02-02  4:53               ` Adam Thornton
2022-01-31  1:41       ` Phil Budne [this message]
2022-02-07  3:04   ` [TUHS] " Rob Gingell
     [not found] <>
2022-01-30 20:09 ` [TUHS] Compilation "vs" byte-code interpretation, was " silas poulson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).