Porting

Bootstrapping

Unlike most free software, SBCL can't bootstrap itself directly from the gcc suite. Most of SBCL is written in Lisp, so it requires an existing ANSI Common Lisp executable as a host for initial bootstrapping. For most people, the problem is simply solvable by downloading a precompiled SBCL binary and using that (either directly or as a bootstrap host to build a more recent version from source). If your needs are more exotic, see below or try asking on the mailing lists, since more options may be possible.

Since SBCL 0.7.5, with Christophe Rhodes' work to port to OpenMCL, SBCL's bootstrapping is expressed entirely in reasonably portable ANSI Common Lisp (modulo a few fiddly bits like dependence on IEEE arithmetic) so the bootstrap host need only be an ANSI Common Lisp, not necessarily SBCL or a close relative. Possible hosts include:

• SBCL Itself
• CMU Common Lisp
• OpenMCL, depending on the version (0.14.1 works)
• CLISP, depending on the version (2.33.2 has worked in the past)
• Other CLs have not been tried or are not sufficiently ANSI compliant (GCL).

Also note that cross-compilation is straightforward, so if you have access to any CPU/OS combination which runs one of the "works" choices above it should be possible to bootstrap an SBCL for your target. (See the platform support page for information on which existing platforms SBCL runs on.)

Ongoing Ports

As of January 2007, the following ports are ongoing:

• Alastair Bridgewater's port to Microsoft Windows has been merged into the CVS repository, but some of the facilities available under UNIX Operating Systems (such as serve-event) are not supported under That Other Operating System.
• Nathan Froyd has an almost-complete 64-bit port to the Alpha; while SBCL is already supported on the Alpha, it acts as though it were running on hardware with a 32-bit word size, rather than the expected 64-bit word.

Other Ports

In increasing order of estimated difficulty, the following ports are possible:

• Porting to another UNIX-y OS, or extending SBCL's coverage of an existing operating system to an existing processor port (e.g. Solaris on x86-64, NetBSD on Sparc, Irix on MIPS, etc.)
• Porting to a CPU supported by CMUCL but not by SBCL (the only remaining such architecture seems to be HPPA, where we have a dormant Linux/HPPA port with many bugs.)
• Porting to a non-UNIX OS.
• Extending an existing port to a 64-bit variant of that CPU (e.g. 64-bit PowerPC, MIPS, SPARC, Alpha, or x86).
• Porting to a new CPU from scratch.

All of these except the first are probably between a man-month and a man-year for someone who already knows what he's doing. For someone learning compilers or assembler or Lisp implementation fundamentals or SBCL implementation idiosyncrasies or whatever as he goes, it might take longer.

Porting to a reasonable Unix-y OS should take about a man-week (consensus of Bill Newman and Dan Barlow after porting to OpenBSD and LinuxPPC). Expect the iffy parts to be getting mmap() to work right (finding absolute memory locations which can safely be reserved for SBCL, and also possibly working around bugs in mmap() itself) and figuring out how to extract the necessary register-level information from sigcontexts. (Note that POSIX SA_SIGINFO-style signal handling is part of the definition of "reasonable", since the nightmarish CMU CL code which tried to work somehow under any old signals implementation no matter how weird is gone in SBCL, and good riddance.)

SBCL has been ported to various CPU architectures by reusing the work done for CMU CL. It should be possible to port it to new CPU architectures, but it would be a lot of work: implementing all the CPU-dependent parts of the compiler backend for the new CPU. If you're interested in any CPU porting work, useful information might be found on the SBCL Internals CLiki pages. You also might find help on the sbcl-devel mailing list or (since the last ports to new CPU architectures were done before the SBCL fork from CMU CL) on the cmucl-imp mailing list.

Porting work to Microsoft Windows and to 64-bit architectures are ongoing. Please read the mailing lists for more information about their current status.