This is a project to create a WASM backend for SBCL. WASM as it exists seems not to be powerful enough to support SBCL as a host compiled directly to it in the same way that you would compile to the x86-64 instruction set on, say, Ubuntu. This is due to the interconnected issues of garbage collection, virtual memory, control stack and signal handling.
To work around these issues, we’ll reach back in time to when CMUCL compiled to a microcoded machine (project Spice), the PERQ. The PERQ was then abstracted as a virtual machine and that was used to port to various architectures. Since Spice lisp did run on a virtual machine, it shouldn’t be hard to create an emulator for it in CL and compile and load Spice lisp onto it. We should then be able to create an SBCL port using the pathway: Spice lisp -> CMUCL -> SBCL.
Once we have (Spice) lisp running on vm, it should be an easy task to mody the underlying instruction set of the VM. The modified instruction set has the following (competing design goals): (it will be a later phase goal to optimize it for performance, but to the extent that #2 is achieved, it should be possible to reach near native WASM performance, wile augmenting WASM sufficiently to handle garbage collect)
- Be as close to SBCL primitives as possible
- Be as close to WASM as possible
- require as little change from PERQ as possible.
From the above design objectives, the following task fall out naturally:
Lap code can be found here: rutgers-top-clisp/upsala/*.lap
Move sbcl-wasm specific code to its own directory
Definitions in the following files should be refactored into different, better named files: sbcl-wasm-compile1.lisp sbcl-wasm-compile2.lisp, sbcl-wasm-compile3.lisp sbcl-wasm-env-access.lisp
Also, make scheme primitives a parameter for the virtual machine.
Should corespond to the ‘macro’ codes of the laid out in: Internal Design of CMU Common Lisp on the IBM RT PC: doc/cmucl-rt.pdf
paip/lisp/init500-lisp-boot.lisp
Ensure that both Scheme and primitive lisp run.
Steps: first to earliest CMUCL, latest CMUCL, earliest SBCL, latest SBCL
The major challenges of this is supporting the interelated issues of SBCL’s memory management expectations, interupts and garbage collection.
Initial target will be node, so we’ll be able to use WASM javascript interop to access the network and fs.