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.

Even more important than the AiWinter, actually, was Moore's Law, which (not for the first nor last time in history) made the price/performance of the Symbolics LispMachine worse than that of general purpose CPU systems at an very quickly increasing rate.

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.

Checkout Movitz http://common-lisp.net/project/movitz/ - But the reason why there are so many ForthLanguage flavors for that purpose is probably because Forth is damn close to hardware while Lithp is far away from it. That's why there were LispMachines after all.

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.

How do you get from "OS Kit" to "Raw BIOS"? And the usual point of a HAL is for ease of programming and/or portability, not for performance. Are you sure that Windoze uses HAL in a way that gives better performance than without? That seems very odd.

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.

Forth lacks any form of memory management, save a simple dictionary space pointer. Everything from [0,p) is allocated, and [p,ADDRESS_MAX) is free. It literally is as simple as that.
Forth lacks macros, and therefore, doesn't need to implement a macro processor. Forth uses ImmediateWords? instead, which are just as powerful, if somewhat harder to use, and a whole lot simpler to implement.
Forth lacks a reader. Again, it relies on immediate words for forward parsing while compiling. Same mechanism; no need for separating macros and reader macros.
Forth lacks any distinction between interpretation and compilation. When you define a word in Forth, it's compiled. Always. There simply is no choice in the matter. This eliminates the need to support both interpreted and compiled forms of a (defun) form.
Forth uses a very simple token parser for is lexer, and has no parser to speak of otherwise. Hence, there is no such thing as a Forth analog to (read). You can read a string and evaluate it, but that's not really the same thing. There is no structured, internal representation of data or code.
Forth is typeless -- more accurately it supports one, and only one, system-wide type: the cell. The cell is usually the same number of bits as the widest value the underlying processor can work with comfortably. Any form of Lisp I can think of, in the meanwhile, has a range of different types to support.
Etc...

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

I did not recall that this innovation originated with LispMachine; do you have a citation? I remember that the PDP 11, for instance, used this technique to simulate floating point if the optional expensive FPU wasn't installed, and I thought it predated the PDP 11 by a good bit.
- The link above. Of course, that could just be the SmugLispWeenies trying to take credit for hardware innovations as well... :) :) :) :) :)
- The link above uses the word "novel", which sounds like they mean "invented", but apparently doesn't mean that, since they also say using microprogramming was "novel", and I know for a fact that they didn't invent that. Here's a reference that says it goes back as far as 1951, in fact: http://research.microsoft.com/~gbell/Computer_Structures_Principles_and_Examples/csp0106.htm -- a bit earlier than I would have guessed, but for sure Burroughs used microprogramming in the 1960s, for instance.

It may be that LispMachinesAreComingBack

CategoryProgrammingLanguage (since the point was to support Lisp)