SBCL on AMD64 has lately started to actually resemble a Lisp system. It still has some major issues, but for example this post was published using my heavily CLOS-based blog software running on SBCL 0.8.15.14.x86-64-again-branch.18 in 64-bit mode. The psychological turning point seems to have been getting SLIME running, after which incremental development of the system has become much less painful.

I must admit that I don't usually use the debugger for anything except taking a quick glance at the backtrace. Even something as basic as inspecting the local variables as done in the following screenshots is something I might do once every few months. It might not actually work for anything more complicated. Getting the debugger to run required only replacing a couple of magic constants and fixing a few bugs in purify I'd missed earlier.

Oh, and wasting too many hours debugging everything from the handcoded assembly for calling to Lisp from C to the debugger internals, until I realized that GCC defaults to -fomit-frame-pointer on AMD64 when compiling with -O1 or higher. Instead of using outdated technology like frame pointers, we now get to grovel through modern DWARF2 data in an obscure ELF section. Extra complexity for practically no benefit, what's not to like! Unfortunately the ABI allows doing this... For now we can explicitly specify -fno-omit-frame-pointer while compiling the runtime. If you find this subject fascinating, see also Eric Schrock's blog entry.

The port has gotten a lot further along in the last month than I expected. Thanks for this at least to Daniel Barlow for writing the AMD64 backend, Nathan Froyd for doing most of the neccessary word-size cleanups to the system while working on the 64-bit Alpha port, and Christophe Rhodes for his amazing remote debugging skills. Also, Kevin Rosenberg has started work on extending the disassembler to understand the AMD64 extensions.