Lisp Machine

Lisp-based computers developed at MIT and Xerox. The MIT line went commercial with SymbolicsMachine, LispMachinesIncorporated (LMI), and later TexasInstrumentsExplorer which subsumed LMI. Commodity hardware (MooresLaw) and better compiler techniques erased the cost/benefit ratio for a special purpose LispMachine.

There is an emulator for the CADR (MITs second generation LispMachine) at http://www.heeltoe.com/retro/cadr/

See http://pt.withington.org/publications/LispM.html

Lisp Machine Manual version 1.4 Jan 1984, 1 PDF file per chapter, see directory http://www.bitsavers.org/pdf/mit/cadr/chinual_6thEd_Jan84/

"A Few Things I Know About Lisp Machines" -- extensive notes by someone who bought one post-2000 to see what they were all about. http://fare.tunes.org/LispM.html


"Lisp Machine" is a generic term. A Lisp Machine is a computer whose operating system and applications are written in Lisp. There were commercial vendors which offered such systems. Lisp Machines have been developed for AI programming in the mid 70s, because machines at that time were not powerful enough for complex AI software. It lead to the first workstations with megapixel screen, networking, large memory, multiple processes, mouse, graphical user interface, etc. Often Lisp Machines have hardware support for special facilities needed by Lisp - like Garbage Collection. The commercial Lisp Machines were setting standards for interactive programming environments.

Xerox' InterLisp D systems were one branch. Cool machines.

At roughly the same time, the MIT AI Lab created a Lisp machine for their AI research. These systems later were commercialized by companies such as Symbolics, Lisp Machines Inc. and Texas Instruments . These companies created their own machines.

With the "AiWinter", commercial Lisp Machines disappeared. Emulators of Xerox and Symbolics systems are still available.


Here's a whacky question: If there's so many bootable ForthLanguage flavors out there (EnthForth being the most memorable example) how come there aren't any bootable LispLanguage floppies? Having a Lisp run on bare hardware with shadow blocks would be a pretty sweet deal. -- MikeGodfrey (who wants to write one but wouldn't know where to start)

PS: Are there any LispLanguage implementations out there written using raw x86 BIOS calls? Finding a free, tiny one of those would be a great step toward making a lispy operating system.

PPS: Sorry if I've posted this on the wrong topic.

MzScheme uses the OS Kit to run on bare hardware as its own OS.

Whoa!! You are kidding, of course. Raw BIOS to build your OS on?!? Talk about pokey! There's a reason Windoze uses a Hardware Abstraction Layer to get some performance out of the underlying machine metalics.

The x86 BIOS is extremely crusty and slow these days. Nothing big uses it for anything other than to load a bootloader off the disk that can get the machine into protected mode as fast as possible. Once in protected mode calling the BIOS becomes rather a chore. The "OS Kit" mentioned above talks to the raw hardware, not the raw BIOS. There is a big difference.


The reason there are tons of ForthLanguage implementations is because Forth is easy to write. The standard for Forth is diminutive compared to CommonLisp. It's even simpler than Scheme's. It is entirely possible to implement a small Lisp-alike that runs on bare hardware. But, it will always be far more complex to write than the equivalent Forth language.

One of the biggest challenges is to write a good performance garbage collector. There are tons available to re-use, but now you need a static or dynamic linker when building your language's core. Forth does away with this, since it's dictionary management is inherently LIFO. It's MUCH simpler. You can implement Forth's dictionary management words in 15 minutes in raw x86 machine language (not even assembler). You'll need a student body at a high-visibility school like MIT to get a decent GC implementation.

This is not to slam Lisp, however. CommonLisp is, to me, very fun to code in, even though I haven't done a whole lot of it yet.

--SamuelFalvo?

First, what you say is true of CommonLisp, but there's nothing (well, nothing but lack of CopiousFreeTime) preventing someone from creating a Lisp dialect that can be as simple to implement as a simple Forth implementation. Such a dialect, however, would of necessity be close to the hardware, and wouldn't have garbage collection, types, and other things we tend to take for granted.

Second, when I was toying with RubyLanguage a few years ago, and had to deal with their system for dealing with different versions of Ruby (which advanced fast enough that it conflicted with Debian's package system), it occurred to me that language ecosystems are literally their own operating system environments--they just piggy-back on other systems. (Later I learned about PythonLanguage and Pip, which only reinforces my conclusions.) I have thought about how interesting it would be to write a LinuxKernel using CommonLisp...but that would involve writing a scheduler, functionality for disk access, ways to keep track of processes, etc (and would involve more of this CopiousFreeTime I keep hearing about). People like to bemoan the fact that there doesn't seem to be much research in developing Operating Systems, but there's a good reason this doesn't happen: developing a new operating system is hard! (That, and such bemoaning ignores the fact that research and new things happen more often than we realize; it's just hard to see, because it's in the background of our typical computer use.)

In any case, I don't think your observations on CommonLisp are a slam at all: when JohnMcCarthy started developing LispLanguage, he chose garbage collection, because he wanted to work with differential equations in an elegant manner. It is a choice that has advanced memory management in ways he couldn't have imagined at the time! And it is a choice that has benefited all of us greatly, even if it makes it more difficult (but not impossible) to write CommonLisp and friends "close to the metal".

--Alpheus


Several LispMachine innovations have found their way into general-purpose microprocessors. One is software instruction emulation (where an unsupported machine instruction causes a processor exception; so that the OS can emulate the instruction in SW), see http://pt.withington.org/publications/LispM.html


It may be that LispMachinesAreComingBack


CategoryProgrammingLanguage (since the point was to support Lisp)


EditText of this page (last edited September 10, 2013) or FindPage with title or text search