THE LISP MACHINE · WHAT IT IS
A Lisp Machine is a whole computer — a processor, main memory, a disk, a screen, a keyboard and mouse, and a network — whose processor and memory are built around the Lisp language. Even its microcode is written as Lisp data, for a microassembler written in Lisp.
This page goes through it a layer at a time, from the hardware up. How it runs follows one boot, and what the system does once it is up: its memory, its processes, its interrupts and its keyboard.
“Everything on the Lisp Machine is written in Lisp, including all system programs; there is never any need to program in machine language.”
— the Lisp Machine Manual, its introduction.
01 / THE IDEA
Lisp, from the instruction set
to the windows on the screen.
The Lisp Machine was built at the MIT Artificial Intelligence Laboratory to relieve the problems of running large Lisp programs on time-sharing systems. It is a personal computer: whoever uses one has its processor and its memory to themselves for the whole session.
Everything on it is Lisp. Not only the programs a user writes: the window system, the editor, the compiler, the network and the access to files — what another computer calls its operating system — are Lisp programs in the same memory as the user’s, and are changed the same way, by loading new definitions of their functions.
The hardware is built for it. Every Lisp pointer carries a data type as well as an address, and the instruction set is made for compiled Lisp: the translation between Lisp and it is, in MIT’s manual’s words, very simple, and many Lisp functions, such as get and assq, are single instructions of their own.
02 / THE LAYERS
Five layers, each brought up by the one below it. The band is the Lisp world the machine boots into, and the Lisp system is that world, running.
A processor, main memory, a disk, a display, a keyboard and a mouse, and a network interface. The CADR’s processor is a 32-bit one on two boards of its own: one carries the data paths, the other the control memory. Everything else is on the two buses beside it.
The disk holds the microcode and the Lisp world. The screen is a bitmap, one bit a pixel: the picture is exactly what the software has written into the frame buffer.
A small program in read-only memory, and the first thing the processor runs when it starts. It knows nothing of Lisp, bands or virtual memory.
It tests the hardware a bit at a time, clears the processor’s memories, finds the current microcode on the disk and loads it into the control store, and then hands the machine over to it. Which microcode a machine runs is written on its disk, not in its PROM.
The processor’s own instructions are microinstructions, 48 bits each on the CADR and 64 on QUUX, kept in a writable memory, the control store, of 16K of them. The microcode is the program written in them, loaded from the disk at every boot.
It carries out the instructions the Lisp compiler produces, the 16-bit macroinstructions, fetching each and dispatching on its opcode to the microinstructions that do its work.
A band is a saved image of a whole Lisp world: every function, object and window, as they were in memory when it was saved. MIT’s bands are the disk partitions named LOD1, LOD2 and on; disk-save writes one.
Loading a large system from its files takes a long time, so it is loaded once, saved in a band, and every boot starts from there.
One Lisp world in one address space. The processes and their scheduler, the window system, the editor, the Inspector, the network, the file access and the compiler are all programs in it; the System key and a letter selects one (how it runs).
A change to the system is loaded into a running world as a patch, new function definitions over the old, and saved in a new band.
03 / WHY MICROCODE
An instruction for Lisp does much more than an addition does. A function call sets up a frame and its arguments before the function’s first instruction runs; a read of memory may meet an invisible pointer, a word that says the value is somewhere else, and follow it; and many Lisp functions are instructions by themselves, written by hand in microcode.
The CADR’s processor is a general one, designed for convenient emulation of complex instruction sets, and on it the microcode interprets the Lisp instruction set. The microcode’s main loop fetches a macroinstruction, dispatches on its opcode to the microcode that does it, and comes back for the next.
The microcode does more than run instructions. It takes page faults and reads pages from the disk, it answers the devices’ interrupts, and it switches the processor from one stack group, one computation’s saved state, to another. How it runs says what each of these is.
Because it is loaded at boot, the microcode can change without the hardware changing. MIT kept it apart from the Lisp world on the disk, in partitions of its own named MCR1, MCR2 and on, so that it could be changed without generating a new system.
04 / TWO MACHINES
Everything above holds for both. What differs is in the details of each layer.
The Lisp Machine built at MIT’s Artificial Intelligence Laboratory around 1978: the machine the Lisp Machine system was written for. Its clock is its display’s frame, it gets its files and the time from a host on the network, and it runs MIT’s microcode and system, and muir-sys’s releases for it.
Inside the CADRThe CADR evolved: changed where a change pays for itself, and everything it does not change is the CADR’s. Its boot PROM has addresses of its own, its disk has a GPT partition table, its clock is an interval timer, and it reads files from folders of its host through a file device. It runs microcode and a system written for it by muir-sys.
What QUUX changes05 / READ MORE