As I was recently playing with McCarthy's interpreter [1] (and much more that hasn't hit github), I had some thought about a modern Lisp machine, as an extensio

As I was recently playing with McCarthy's interpreter [1] (and much more that hasn't hit github), I had some thought about a modern Lisp machine, as an extension of a RISC-V core [2]. Software is always a big concern and rather than requiring everything be written in Lisp, I'd want to also be able to run regular binaries written in C. This requires a way to safely embed the "impure" world. The obvious way to do this is extend the value domain with a hidden tag bit [3] which is carried around everywhere, but can't be changed or inspected by regular RISC-V instructions and in fact, almost all instructions trap if any operand is tagged. Memory space would be partitioned into a tagged space and untagged. Tagged values can only live in the tagged space and registers (this is important for precise GC). For regular user space code, tagged values can only be created with a `cons` instruction, and accessed with `car`, `replaca`, etc instructions. Having dedicated instructions would allow a hardware read barrier for real-time (or incremental) GC. (Machine mode would be allowed unsafe access for part of the GC and various tasks). TL;DR: adding fast Lisp support to an existing RISC-V core is likely much easier than building a new dedicated architecture from scratch. (set! projects (cons 'RISCV-LISP projects)) [1] https://github.com/tommythorn/lisp https://github.com/tommythorn/lisp [2] https://github.com/tommythorn/yarvi https://github.com/tommythorn/yarvi [3] If you have data cache, it's not hard to implement a cache line as, say, 32 33-bit word line, backed by 33 32-bit memory words.