Here's a novice question:
Does a lisp compiler exist? I know emacs can byte-compile lisp code,
and some lisp interpreters can optimize lisp code, but is there a
*real* lisp compiler in existence.
I assume there is, since emacs is written in lisp, and it's been
compiled.
From: Jeff Dalton
Subject: Re: Lisp compiler?
Date:
Message-ID: <1325@skye.ed.ac.uk>
In article <····@bingvaxu.cc.binghamton.edu> ···@cornella.cit.cornell.edu writes:
>Here's a novice question:
>Does a lisp compiler exist? I know emacs can byte-compile lisp code,
>and some lisp interpreters can optimize lisp code, but is there a
>*real* lisp compiler in existence.
Yes, there are quite a few of them. Most Lisp systems have both an
interpreter and a compiler, but some have only a compiler (and some
only an interpreter). Compilation to byte-codes is often used on
machines on which the byte codes can be microcoded or to get a very
portable implementation that nonetheless provides more efficient
execution than would an interpreter.
Most of the Lisps I have used, however, have a "real compiler", ie one
that compiles Lisp into machine code.
An interesting intermediate technique is to compile Lisp into C and
then have the C compiler generate the machine code. This sort of
compiler can be quite portable, but compilation tends to be slow, and
certain optimizations are difficult to perform. Kyoto Common Lisp is
a system of this sort, and I once produced a similar compiler for
Franz Lisp. I believe there is also at least one Scheme->C compiler.
>I assume there is, since emacs is written in lisp, and it's been
>compiled.
GNU Emacs is written in C and Lisp. The Lisp is byte-compiled by
Emacs and the byte codes are interpreted by a C routine. However,
some versions of Emacs have been written completely in Lisp, generally
to go with Lisp systems that have a real compiler.
Lisp compilers have traditionally been written in Lisp, and, these
days, it is common to write Lisp systems almost entirely in Lisp.
(Some existing Lisp system is used to start things off, but soon
the system is able to compile new versions of itself.)
Jeff Dalton, JANET: ········@uk.ac.ed
AI Applications Institute, ARPA: ·················@nsfnet-relay.ac.uk
Edinburgh University. UUCP: ...!ukc!ed.ac.uk!J.Dalton
From: alan geller
Subject: Re: LISP compiler?
Date:
Message-ID: <611@pyuxf.UUCP>
In article <·····@mimsy.umd.edu>, ·····@tove.umd.edu (Wayne Folta) writes:
> "
> "Most of the LISPs I have used, however, have a "real compiler", ie one
> "that compiles LISP into machine code.
> "
> I have a novice question concerning this. My LISP (Apple ACL) will compile
> LISP down to (apparently) machine code. I can see it when I use the
> disassemble function. However, it appears that the compiled code does
> calls to the LISP kernel. Thus, the code is compiled, but not what us
> rookies would call "real compiled", i.e. stand-alone executable files.
>
> I wonder if this is a common C-programmer misconecption. When we think of
> "compile" we mean "compile to a standalone executable", while in LISP it
> could mean "compile to machine code that still depends on the LISP kernel
> at run time." Is this true? [In ACL, you compile your routines, then you
> create a new top-level loop, replacing LISP's, then you use the Standalone
> Application Generator to create a standalone application. In version
> 1.2.2, it looks like you get all of LISP in the bargain, as the minimum
> executable size thus generated is at least 700K (as I remember).]
>
> So, maybe questions about "[real] LISP compilers" are different from what
> LISP experts think they are? (Shades of the "real multitasking" debates
> in the Macintosh groups :-).)
>
> Wayne Folta (·····@tove.umd.edu 128.8.128.42)
This is, indeed, a C-programmer misconception. When you compile and bind
a 'C' program, you also will wind up including a substantial amount of
run-time support code: the 'C' library functions, glue routines for calling
the operating system (ToolBox on the Mac), etc.
It's true that applications generated from ACL are much bigger than an
equivalent application written in 'C' (for small applications); this is
because the ACL run-time support code does much more than the 'C' run-time.
For instance, you get a complete garbage-collected storage management
facility, as opposed to glue into _NewHandle and _NewPointer. You also
get all of the Common Lisp standard functions, including eval and apply,
which is to say you get a Lisp interpreter in your (compiled Lisp) application.
In ACL, you also get Object Lisp support, as well as all of the standard
pre-defined Object Lisp classes, which is to say you get the FRED editor
(emacs, to those of you who aren't familiar with ACL).
Obviously, you're normal 'C' application doesn't get any of this from its
run-time support code. For a small application, or even a medium-sized
one, you may use only a little bit of it, in which case all of that code
is essentically wasted space. For a large application that wound up using
more of the ACL run-time support, you might actually wind up with a smaller
application than you would if you rewrote it in 'C', and you would certainly
save enormously in development time.
As an aside, the ACL group at Apple does realize that most applications don't
need all of the code that gets included, and they are working on ways to
avoid including support that you don't use.
Anyway, the bottom line is that the ACL compiler, like most modern Lisp
compilers, really DOES compile your code into native machine code that
executes quite quickly (as an aside, including all of the extra support stuff
is mostly a problem for memory usage and disk usage; it won't directly
impact performance, although the increased memory usage does have an effect).
Alan Geller
Regal Data Systems
...!{princeton,rutgers}!bellcore!pyuxf!asg
Nobody at Bellcore listens to me; nobody at Regal does either.
My ideas and comments are my own.
In article <····@hplabsz.HPL.HP.COM> ·····@hplabs.hp.com (Niels Mayer) writes:
>I think the biggest problem with lisp is that it lets you be sloppy with
>memory management... most big lisp systems I've worked with generate
>garbage in low-level modules that must eventually be garbage collected. If
>you try to optimize this by rewriting your modules to be "cons-free", the
>code becomes so spaghetti-like that you might as well be writing it in C.
>How can compilation solve the problem of lisp's memory inefficiencies?
>
I think that you are overgeneralizing your experience. I have 2 suggestions:
(1) Change your coding style so that your declarations are compiled
statically [i.e. write your code in a *clean* style which does not cons].
[I don't buy your spagetti argument].
(2) Get a runtime system which is written not to cons. Demanding better
runtime libraries from your suppliers is a worthwhile occupation.
By the way, what do you mean by Lisp (MacLisp, InterLisp, Scheme,
CommonLisp, Franz...)?
-Ken Dickey ····@mrloog.WT.TEK.COM
In article <····@hplabsz.HPL.HP.COM> ·····@hplabsz.HPL.HP.COM (Niels
Mayer) writes:
> In article <····@internal.Apple.COM> ·····@apple.com (Paul Snively)
writes:
> >Your description of what Macintosh Allegro Common Lisp does is
completely
> >accurate, obviously, which is a fancy way of saying that the current
> >version(s) of MACL don't have what amounts to a "smart linker;" that
is,
> >unused code from your application is NOT currently stripped out
(although
> >strictly development-related things like the compiler itself are). A
> >future version of MACL WILL do a treewalking dead-code stripper,
reducing
> >application sizes tremendously.
>
> So what does MACL's fancy dead-code stripper do when your program happens
> to call 'eval' or 'apply'?
It depends upon what the arguments to either of these functions are. For
EVAL, I'd expect it to throw up its hands in despair, like MacScheme does.
Or perhaps it just needs to know if the expression can be "found" in the
current environment (i.e. (EVAL (READ)) wouldn't work).
__________________________________________________________________________
Just because I work for Apple Computer, Inc. doesn't mean that they
believe what I believe or vice-versa.
__________________________________________________________________________
C++ -- The language in which only friends can access your private members.
__________________________________________________________________________