I feel like I’m confident enough to attempt building a LISP machine on top of a raspberry pi.
I just finished studying the MIT CADR hardware LISP machine, and I think I can build a really low level LISP machine using the memos for that machine, and the Symbolics 3600 series patents.
Part of me wonders—-does EMACS depend very strictly on a bigger operating system? Perhaps creating a LISP machine that could simply boot into EMACS could be a goal. I seem to remember quite a bit of EMACS depends on quite a bit of, say, the UNIX operating system environment. Surely someone has had this exact train of thought before: set up EMACS /as/ an operating system.
Doing this would be really convenient because then you could simply run anything and everything EMACS could. Massive software libraries easily accessible.
Anyway a lot of my confusion about hardware LISP machines has been cleared up now—-I was overcomplicating my understanding of what they are. They have an instruction register, a program counter, and cache like amd64 von Neumann machines.
But instead of being register-driven machines, they are stack machines. The CADR, for instance, does away with the need for any serious registers for computation, in place of two massive banks of fast scratchpad memory. Which is luxurious! The main scratchpad, ‘A’, is a whopping 1K of 32 bit word space—-in 1979.
There are 4 main categories of instructions in the CADR. It’s a little like the PDP-8 in that these ‘categories’ are really just /the/ instructions, and each of the four of them have numerous ‘fields’ which tell the ALU, or the program counter what you want to do: ALU, DISPATCH, BYTE, and JUMP.
Anyway, writing a really low-level LISP virtual machine for the raspberry pi would only require translating LISP machine instructions into ARM64 instructions, and I imagine I’d either bank loads of the ARM registers together into scratchpads, etc.
In other news, here are some interesting facts about LISP operating systems:
- they don’t have a ‘kernel’, the main issue that plagues UNIX land: LISP OSs are just enormous banks of functions that all flow and cord into each other. There is, speaking in absolute terms, no such thing as a userland/kernel context switch. Nothing ever gets halted when you write to disk or otherwise use I/O.
- LISP operating systems only have one address space, and the properties of the objects and functions, their capabilities, are what keep things secure.
- all memory is treated the same, really. Disk space / main memory is not an interesting distinction for LISPers with their operating system. The main memory of a computer (read: the RAM) is effectively just an enormous cache for the non-volatile memory.
What is the upshot of all this? LISP cares not for all these bizarre distinctions and dichotomies in the UNIX/C/PDP-11 land.
There’s also the really cool shit, like, really, really dazzling space age behaviour with LISP operating systems: instant and seamless modification of the operating system, like in EMACS, even to the point of being able to edit your hardware processor’s micro-code, on the fly. Which still gives me shivers: such stuff would be like an anthropomorphic UNIX person who ascended into immortality.
Anyway this all sounds like magic/heresy, but it’s because all we really have is C and the von Neumann computer processor architecture. Which is really, really poor and uninspired.
LISP says: we are here to evaluate symbols, not execute statements. Our machines are not merely interested in numbers, but also abstractions with human-laden meaning.
Hope you find this little blog post interesting (: