Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!sharkey!cfctech!teemc!mibte!gamma!towernet!pyuxp!pyuxd!pyuxf!asg
From: asg@pyuxf.UUCP (alan geller)
Newsgroups: comp.lang.lisp
Subject: Re: LISP compiler?
Keywords: lisp compiler
Message-ID: <611@pyuxf.UUCP>
Date: 8 Nov 89 21:56:53 GMT
References: <2606@bingvaxu.cc.binghamton.edu> <1325@skye.ed.ac.uk> <20585@mimsy.umd.edu>
Distribution: usa
Organization: Bellcore, Livingston, NJ
Lines: 67

In article <20585@mimsy.umd.edu>, folta@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          (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.