Comment by snazz
6 hours ago
I’ve read this article every time it’s gotten posted here and it’s always gone a little over my head. I was able to follow how he used 8 x86_64 registers for the VM’s stack slots and how the VM instructions were implemented. How the padding and alignments of each version of the instructions was calculated is impressive and I can imagine how much of a chore it would be to figure out with a normal assembler.
Using SBCL as a macro-assembler is extremely cool, and then allowing CL code to call into the VM is where it really blows my mind.
Obviously it’s been over a decade since this article was written. For someone less familiar with SBCL internals (or CL in general), would something like AsmJit or Iced be a good way to achieve similar things?
> Using SBCL as a macro-assembler is extremely cool, and then allowing CL code to call into the VM is where it really blows my mind.
Absolutely. I think TFA is hooking into the actual code emitter used by SBCL's evaluator-compiler, since it's not actually primitive, but implemented in Lisp and loaded into the image itself.
My guess at context: from the earliest days of Lisp, I think there was an expectation that Lisp systems would expose as much of their internals as possible... including their internal JIT, which is being plugged into here. I think the name for it was the "LISP Assembly Program" (LAP).
Try pair reading it with a good thinking LLM like GPT 5.5 or Claude Opus. I found it help me a lot.
I have started learning SBCL internal from the beginning of this year with the help of GPT, and I really want to contribute to SBCL compiler someday in future.