Lars Brinkhoff <lars@...> writes:
> I have no previous experience with SBCL internals, but I'd like to
> hack the assembler. So far I have used the steps in make-host-1.sh to
> verify that my changes load and compile without error. Now, to test
> the assembler, is there a way to assemble short snippets of assembly
> code and see the binary (or hex or whatever) output?
There probably is a way. I'm afraid that, depending on what you're
doing, it's either fairly straightforward or quite hard.
Let's do the straightforward case first, because it's easier :-) The
straightforward case occurs when the assembler that you've just
compiled is binary-compatible with some already-existent sbcl platform
-- in other words, your assembler hacking has been, for instance, to
introduce a peephole-optimization phase, or something similar --
something that doesn't change the target architecture.
In that case, fasls produced by the cross-compiler (the compiler built
as an application in the host lisp during the make-host-1 stage) can
be loaded into a chilled ordinary sbcl (built from similar sources,
but minus your changes). To chill sbcl (essentially, renaming
packages to bootstrap names), load "src/cold/chill.lisp" from the SBCL
source distribution; then fasls produced by TARGET-COMPILE-STEM (or
similar machinery) can be loaded into your sbcl (it'll warn about
COLD-FSET, but that's harmless) and then functions disassemble using
the normal DISASSEMBLE machinery.
The other half of the "straightforward" phase is to assemble a known
snippet; to do that, I'll refer you to
essentially tells you how to write inline assembly. You may wish to
(declare (optimize speed (safety 0))) to minimize noise -- without
that, the system might insert number-of-arguments checks, type checks,
and the like, which would interfere with reading disassembly.
If your changes to the assembler break binary compatibility, things
get trickier. The most fundamental problem is that to do just about
anything sbcl needs to be able to compile calls to functions; if it
can't do that, you have to resort to finding an entry point into the
assembler itself and feeding it raw VOPs; I have no idea how to do
this. If it can compile function calls, to at least a first
approximation, you can follow the second half of the "straightforward"
instructions to produce a fasl; then, unfortunately, you have to get
your hands dirty with the object file format.
The object file format is a stack-based machine, with operations
called FOPs (presumably "Fasl OPerations, not that I'd know :-); the
particular FOP you're looking for is probably FOP-FUN-ENTRY, code 142;
the code object is the fourth argument on the stack at this point.
Dealing with this route is probably somewhat challenging and tedious,
but doable; basically, you need to find your code in amongst all the
other bits and pieces that happen in a fasl.
Does that help?
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)