Subject: Re: McCarthy's original proposal for Lisp
From: (Rob Warnock)
Date: Mon, 28 Jul 2008 00:30:22 -0500
Newsgroups: comp.lang.lisp
Message-ID: <>
Robert Maas, <> wrote:
| From: (Pascal J. Bourguignon):
| > Almost all lisp implementations have a LAP.  Well, let's discard
| > ecls and gcl, since their LAP is C itself.
| So CMUCL has LAP? I didn't know that. Looking at 'man cmucl' now ...

Don't look in the man page, look in the CMUCL sources, for things
called "VOP"s. E.g., from "cmucl-19c/src/compiler/x86/arith.lisp":

    (define-vop (signed-byte-32-len)
      (:translate integer-length)
      (:note "inline (signed-byte 32) integer-length")
      (:policy :fast-safe)
      (:args (arg :scs (signed-reg) :target res))
      (:arg-types signed-num)
      (:results (res :scs (any-reg)))
      (:result-types positive-fixnum)
      (:generator 30
	(move res arg)
	(inst cmp res 0)
	(inst jmp :ge POS)
	(inst not res)
	(inst bsr res res)
	(inst jmp :z zero)
	(inst inc res)
	(inst shl res 2)
	(inst jmp done)
	(inst xor res res)

Is that LAP-y enough for you?  ;-}

|  -- Calls to library functions (SIN, ...) are optimized to a direct call
|     to the C library routine (with no number consing.)  On hardware with
|     direct  support  for  such functions, these operations can easily be
|     open-coded.
| Hey!!! CMUCL is a lot more dependent on C than people in this
| thread have admitted!

As Pascal said, no-one in their right minds is going to completely
re-implement the standard "" from scratch on any standard 
operating system. Why should they?!? Totally wasted effort, and
for what?!?  Just use it.

| Looking at the online CMUCL manual, table of
| contents, I see no mention of LAP at all, and no mention of
| "assemb..." except for the disassemble function.

True, they don't expose it to ordinary users, but any user can
certainly add their own VOPs to the compiler, if they like,
even at run-time -- *without* recompiling the whole system!
[I actually had to do that recently, while investigating an
issue in the VOP for the fast-path of (RANDOM {unsigned-byte-32}).
Worked just fine, thank you very much!]

Remember, the source of CMUCL is completely open, so have at it!

|  So it looks like I would need to roll my own executable-writer
| using WRITE-BYTE.

Sure, go ahead, if you want to re-invent all of computer science
since the wheel... ;-}  ;-}

| ...[long, rambling, poking at file formats]...
| OK, confirmed, it's ELF format!!

Look, if you really, really want to write FreeBSD executables,
just look at the code added to "save.lisp" in CMUCL-19d (or later)
for the new ":EXECUTABLE T" option:*checkout*/src/code/save.lisp?root=cmucl
      If nil (the default), save-lisp will save using the traditional
      core-file format.  If true, save-lisp will create an executable
      file that contains the lisp image built in.
      (Not all architectures support this yet.)

It handles all that ELF stuff, including stuffing the heap image
into a new ELF section that the start-up code can "mmap()" back
into memory when you run the result.

Of course, you're probably going to be upset when you discover
that the SAVE-EXECUTABLE function is a call-out to the C-based
run-time library!  ;-}  ;-}  [The stuff in ".../src/lisp/*.[ch]".]

| I should in theory be able to directly construct FreeBSD
| Unix executables

Save yourself some work. (See above.)


Rob Warnock			<>
627 26th Avenue			<URL:>
San Mateo, CA 94403		(650)572-2607