Programmed code generation: Native vs. Pcode

[Barry Shein]

[don't take any of this as contentious but I think there's a disagreement here]

From: pardo at june.cs.washington.edu (David Keppel)
>In article <23944 at bu-cs.BU.EDU> bzs at bu-cs.BU.EDU (Barry Shein) writes:
>>Did I miss something critical here? Most lisp systems generate and
>>execute there own machine code.
>
>Many Lisp (Prolog, Smalltalk, ...) systems generate a pseudocode
>rather than native instructions.  The p-code is run by an an
>interpreter rather than the hardware.  Thus, as far as the hardware is
>concerned, it is only the interpreter and NOT the p-code that is being
>executed.

Prolog and Smalltalk are not Lisp, the similarities are abstract and
most of the implementations of the former tend towards experimental
while many mature Lisp production environments exist (note: this is
not a criticism, I wouldn't be shocked to hear one or two prologs
exist that have a true compiler, I'm just saying it's pretty much
irrelevant to my point.)

Name three Lisps that people on this list are likely to have heard of
which generate a "p-code" and not some form of machine language from
their compiler. I can't think of one (unless you're referring to T or
Scheme which are more or less lisp, a lot closer than Prolog or
Smalltalk anyhow.)  I don't think I'd count Gnu Emacs' lisp, but
consider it mentioned. It wasn't intended as a general purpose lisp
although it's almost certainly the most used production lisp today.

>A number of more sophisticated Lisp systems DO generate native code
>for themselves (as opposed to Lisp systems where you compile an
>program to native code and once you start it, you can't load any more
>compiled code).  These systems, however, are typically targeted for
>particular machines (e.g., InterLisp for Xerox Dandylions) and thus it
>is "safe" to make assumptions about the target hardware.

Interlisp originally ran on PDP-10's, although I'd admit that the 1100
series machines are microcoded to look a lot like a PDP-10.  Of course
all lisp-machine lisps tend towards one architecture, that was sort of
the whole point. Symbolics, LMI, Xerox and TI.

Franz Lisp generates direct machine code for several machines (I know
of Vax, 68K and NS32K compilers, I have one of each of those here.) I
believe there was a 3B2 version and probably several others (there
must be a celerity version for running Macsyma.)

KCL (Kyoto common lisp) generates C code which is compiled by the
system's native C compiler. Most of the port work (if any) is in
accommodating differences in object formats and dynamic loading (and a
very few machine coded routines.) I'd call that direct machine code,
even if another program is used as a backend (cc) to finish it up.

Lucid and Allegro Common Lisp both generate machine code as far as I
know for several architectures, at least Vax, 68K, Celerity
(proprietary) and certainly several others.

There are some PC lisps I don't know much about.

Maclisp was definitely locked into the PDP-10 and is ancient history
now.

I don't know about Spice Lisp, not sure if it ever ventured off the
10, ancient history anyhow as far as I've heard. Hedrick used it to
produce a very nice Common Lisp for the '20 which was definitely
locked into that architecture.

Betz's xlisp, last I checked, didn't have a compiler.

PSL (Portable Standard Lisp from U. Utah) generates direct machine
code from an abstract LAP code back-end translator and works on
several architectures (at least Vax, 68K and 370.)

NIL generates machine code but is completely locked into the VAX
(mostly a Macsyma delivery vehicle I believe.)

Have I missed any major lisps? Probably a few, but they really are
enumerable if one sticks to some criteria of popularity, no need to
develop sweeping generalizations (by either of us.)

	-Barry Shein, Boston University