💾 Archived View for tanelorn.city › ~vidak › old-blog › what-a-lisp-os-is.gemini captured on 2020-09-24 at 01:41:51. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
---
generator: pandoc
title: What a LISP Machine Is
viewport: 'width=device-width, initial-scale=1.0, user-scalable=yes'
---
2020-06-23T15:29:17+08:00
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 (: