Some quick notes on my own methods, that are very welcome for optimization.
* How did you get started hacking SBCL?
+ I think trying to know your compiler under the hood makes you write
better code. Also sbcl's many feature like compiling to machine code
makes it complete.
SBCL is the leading platform to do misc hacks on :)
* Can I avoid knowing much about the bootstrapping process and still
learn a lot about how the compiler works. For example, how (+ 1 2) is
compiled into assembly?
SBCL recompiles itself very straight-forward. I say that meaning that
you have stages where you can do tests inbetween.
How much you need to know would depend on what type of hacking is done.
+ To port to a new arch/os a minimal knowledge is needed to bootstrap
hacking attemps. Atleast know that we build and "assemble" an
cold-core that is cold-booted to further inject itself with CL and
finally dump itself as an finished product.
Setup for Cross-compiling (look at wiki) is also good, to learn what
+ To explore the FOP enging minimal knowledge of the build process is
Here you could just take a copy of fop.lisp and load.lisp and change
the package to be able to load them into any sbcl without interfering
with sbcl's own
+ Dig around in the git archive, some patches are very clean with
complete interfaces in on how to implement things. Those makes up great
* Was the Internals wiki helpful for first-timers? for me it gives a
high-level understanding of what SBCL is up to, but it doesn't teach me
function names or what files to seek out.
Somewhat, it seems little outdated if I may say so. But some section
has nice detail-level descriptions.
* Are there good pet projects for beginners to work on?
Sooner or later you would end up using gdb, so I guess that can be a
Try on a fresh sbcl build: "gdb -x /tmp/z --args ./src/runtime/sbcl
And in the /tmp/z you can put your sbcl things, to start out put:
That would let the sbcl-runtime do its thing and if you Continue, it
gives control to lisp function cold-init ( src/cold-init.lisp ).
To try out VOP hacking, that is enough to see if your VOP assembles
At the cold-init function you can put in test forms that triggers the
Using "si" in gdb to single-step if the code branches, lookup the new
entry-point in output/cold-core.map
Watch out: If you go down in cold-init you will see GC being
initiated. After that the core is "scrambled" and cold-core.map isn't
Also dont put any breakpoints after gc has initiated.
+ Look for isolated things, like that FASL loader (where hacking could
be contained to src/code/fop.lisp, src/code/load.lisp,
src/compile/dump.lisp and little of genesis.lisp ).
* Does most development happen through the REPL on an active SBCL
instance? I can imagine there is a lot of restarting for some types of
+ Alot of stuff is probably reloadable in sbcl. Havn't figured that
out yet. But I guess doing a port involves around 200-400 builds from
* What's the best way you have found to search the mailing list to avoid
+ IRC is quicker when you are stuck :)
* How ugly is the source compared to OpenMCL, a fast Scheme
implementation, a commercial lisp implementation, and GCC?
+ Dont know about the others, but SBCL is the standard that I try to
follow when it comes to design, code-documentation etc..
* Has anyone attempted to port to Java bytecode or some other
unconventional assembly-like language?
+ Also LLVM or maybe S/390 would be interesting to hear if it is
feasible to port to.
* Are there portions of the compilation process that are currently
obviously suitable for optimization via machine learning algorithms?
+ I guess the thing that produces "IR1" and converts to "IR2" is
itself a big chapter. Luckily we can look at "IR2" using trace-files
to know if the compiler is behaving.