pardo@june.cs.washington.edu (David Keppel) (07/17/88)
In article <23944@bu-cs.BU.EDU> bzs@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. 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. ;-D on ( Me and my big segment ) Pardo
bzs@bu-cs.BU.EDU (Barry Shein) (07/17/88)
[don't take any of this as contentious but I think there's a disagreement here] From: pardo@june.cs.washington.edu (David Keppel) >In article <23944@bu-cs.BU.EDU> bzs@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
mike@arizona.edu (Mike Coffin) (07/18/88)
From article <23955@bu-cs.BU.EDU>, by bzs@bu-cs.BU.EDU (Barry Shein): > 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.) No need to make an exception for T; it generates native machine code. Also no need to call Scheme "more or less lisp"; it *is* a lisp. The invention of Common Lisp did not suddenly "unlispify" all previous lisps. -- Mike Coffin mike@arizona.edu Univ. of Ariz. Dept. of Comp. Sci. {allegra,cmcl2,ihnp4}!arizona!mike Tucson, AZ 85721 (602)621-4252
pardo@june.cs.washington.edu (David Keppel) (07/18/88)
bzs@bu-cs.BU.EDU (Barry Shein) writes: >pardo writes: >>[ Most lisps don't generate their own machine code on the fly ] >[ many examples to the contrary ] Ok, how's this for a sweeping generalization: I'm dead wrong. Sorry, guys, but I do sometimes clutter the net needlessly. I apologize for my disinformation. ;-D on ( Oooh, did I just break netiquette, apologizing ?-) Pardo
djones@megatest.UUCP (Dave Jones) (07/18/88)
From article <5314@june.cs.washington.edu>, by pardo@june.cs.washington.edu (David Keppel):
> ;-D on ( Oooh, did I just break netiquette, apologizing ?-) Pardo
Don't worry. The practice is very unlikey to catch on. We can
just consider this to be an isolated incident.
-- Dave J.ok@quintus.uucp (Richard A. O'Keefe) (07/19/88)
>From: pardo@june.cs.washington.edu (David Keppel) >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. (1) There are a couple of commercial Prolog systems which generate native code. In the interests of higher performance for large programs on small (4-8Mbyte) machines, Quintus Prolog is _not_ one of them, but that is another (and perhaps more interesting) story. (2) All the commercial Prolog systems that I know of offer an interface to some other language (Lisp, C, or Pop). So even the systems which use pseudocode rather than native code aren't off the code-modifying hook: if you want to be able to load C code at run time you still have to make additional parts of your address space executable. (But once a region of the address space has turned into code, it need never be changed again.) (3) VMS, SunOS 4.0, and I believe Apollo's AEGIS support dynamic extension of programs by mapping *shareable* library code into a program's address space (System V.3 on a 386 sort of kludges this in too). Would anyone care to explain what architectural features are needed for efficient dynamically mapped shared code? Is position independent code essential, or only better? What popular architectures couldn't do it? If SPARC can do it, is there anything about RISCs which makes it easier/ harder?