BrassTacks (wpc)

Had a number of thoughts with respect to the Lisp Machine; some triggered by reading the recently posted HTML version of the Lisp Machine Manual (Chineual).

People seem to be navigating to this from Google. If you want to comment, go to the post in the Blog area.

For those of you Googling for Lisp Machine Keyboard, there are better sites for information; the original CONS and CADR Lisp Machines used keyboards apparently designed by Tom Knight an older and newer “space cadet version.” Symbolics introduced its own variations: and old and a new variation. As far as implications in 2007, the unfortunate thing is that USB HID Spec and HID Usage Tables do not explicitly allow for the additional modifier “bucky bits” such as Super and Hyper. It explicitly allows for left and right Ctrl, Shift, Alt, and GUI. GUI makes a passable Super, and there are enough function keys around to make up for the assorted magic keys (“Terminal”, “Network”, Square, etc.), and I think there is enough slop in the USB to even sneak in modifiers (such as using Menu for Hyper), as long as a de facto standard emerges and the software is flexible enough to abide by it.

Given the body of code and hardware represented by the CADR project code and simulators, what can be replaced to make a reasonable substitute with modern performance? I tried to sketch out an architecture diagram, but couldn’t figure out how to structure it. The CADR system had a number of components, let’s begin with a simple list

• hardware processor (this is what executes the microcode)
• microcode (this includes the instructions to execute the higher-level stack machine code, as well as interrupt service routines for the ChaosNET, initialization for cold boot, probably some other things like mouse and keyboard, probably a number of type-dispatched Lispy primitives)
• hardware interfaces to support hard disk, chaosnet, video screen, keyboard, mouse, strapping to other machines for bring-up
• low-level OS code to support such things as stack groups, process primitives, I/O operations (not at all sure about this part?), Lisp primitives (?), virtual memory?, garbage collector? dumping worlds?
• what supports idiosyncratic architectural stuff, such as CDR-coding, locatives?
• mid-level OS code to support things like network protocols, I/O abstractions, flavors, file system interaction (not at all sure about this either)
• the defsystem, tags, patch support
• windowing code, Zwei, inspector, Zmail (some of this is applications-level, some is toolkit level)
• compiler for Zetalisp to stack-machine code, with some calls to microcode?
• Note: a lot of the Lispy code probably depends on Mac/Zetalisp’isms, such as defaulting to base-8, use of forward slash ‘/’ as escape, single characters for =, characters as small integers, funcalling arrays, other funky stuff

Some ideas for how you might port this to a typical low-cost 2006 computer

Port Lisp code to a Common Lisp running on a Unix-flavor OS: what has to be done?

• need to rip out various dependencies on the low-level idiosyncracies (i.e. stuff which depends on structure layouts, interrupt stuff, process groups, probably anything using without-interrupts) Problem: this might be just about everything!
• probably need emulation of Flavors, or porting (semi-automatic translation?) over all that stuff to CLOS
• provide networking, keyboard, video, mouse; this probably isn’t too bad actually: simple framebuffer window
• provide some file system emulation (how much just works with a native non-versioned UNIXy filesystem?)

Emulate microcoded environment on something written in high-level language (e.g., Common Lisp.) I think this is the Meroko and Nevermore approach.

• Execute stack-based code, trapping microcoded operations
• How much of the data would be based on native CL objects, how much would be based on a flat memory space of integers?
• How to bridge the gap between HW interrupts and the microcode environment?

Emulate microcoded environment with something running almost on bare metal

• native code interpreter for the stack code? Isn’t this one of the emulator projects, with everything else provided in software? (How is this really different from a Common Lisp-based emulator, as long as it is compiled to native code?)
• native code garbage collector for low-level primitives?
• flat, unprotected memory space?
• periodic clock interrupt? Note that the CADR software pervasively assumes a single processor where interrupts can be disabled with a (without-interrupts) form, and probably assumes a pretty strong memory consistency model.
• Some low-level OS kit implementation of hard drive access, VGA framebuffer, mouse, keyboard, Ethernet interface (maybe a TCP/IP stack as well, but maybe just low-level Ethernet packets encapsulating Chaos packets?)
• need to replace low-level I/O primitives, interrupt structure to match typical PC
• Network server looking for low-level Chaos packets, willing to respond in-kind, providing file server, time server, gateways, etc.

Emulate hardware environment in software (this is the usim/chaosd approach)

• (slowly) emulate microcode instructions
• trap bus accesses to memory and I/O