Robert Maas, <jaycx2.3.calrobert@spamgourmet.com.remove> wrote:
+---------------
| From: p...@informatimago.com (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)
POS
(inst bsr res res)
(inst jmp :z zero)
(inst inc res)
(inst shl res 2)
(inst jmp done)
ZERO
(inst xor res res)
DONE))
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 "libc.so" 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:
http://common-lisp.net/cgi-bin/viewcvs.cgi/*checkout*/src/code/save.lisp?root=cmucl
...
:executable
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
-----
Rob Warnock <rpw3@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607