Lisp-based computers developed at MIT and Xerox. The MIT line went commercial with Symbolics Machine, Lisp Machines Incorporated (LMI), and later Texas Instruments Explorer which subsumed LMI. Commodity hardware (Moores Law) and better compiler techniques erased the cost/benefit ratio for a special purpose Lisp Machine.
There is an emulator for the CADR (MITs second generation Lisp Machine) at www.heeltoe.com 
Lisp Machine Manual version 1.4 Jan 1984, 1 PDF file per chapter, see directory www.bitsavers.org
"A Few Things I Know About Lisp Machines" -- extensive notes by someone who bought one post-2000 to see what they were all about. fare.tunes.org
"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' Inter Lisp 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 "Ai Winter", commercial Lisp Machines disappeared. Emulators of Xerox and Symbolics systems are still available.
Even more important than the Ai Winter, actually, was Moore's Law, which (not for the first nor last time in history) made the price/performance of the Symbolics Lisp Machine 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 Forth Language flavors out there (Enth Forth being the most memorable example) how come there aren't any bootable Lisp Language floppies? Having a Lisp run on bare hardware with shadow blocks would be a pretty sweet deal. -- Mike Godfrey (who wants to write one but wouldn't know where to start)
PS: Are there any Lisp Language 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 common-lisp.net - But the reason why there are so many Forth Language 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 Lisp Machines after all.
Mz Scheme 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 Forth Language implementations is because Forth is easy to write. The standard for Forth is diminutive compared to Common Lisp. 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 Immediate Words 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. Common Lisp is, to me, very fun to code in, even though I haven't done a whole lot of it yet.
First, what you say is true of Common Lisp, but there's nothing (well, nothing but lack of Copious Free Time) 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 Ruby Language 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 Python Language and Pip, which only reinforces my conclusions.) I have thought about how interesting it would be to write a Linux Kernel using Common Lisp...but that would involve writing a scheduler, functionality for disk access, ways to keep track of processes, etc (and would involve more of this Copious Free Time 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 Common Lisp are a slam at all: when John Mc Carthy started developing Lisp Language, 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 Common Lisp and friends "close to the metal".
--Alpheus
Several Lisp Machine 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 pt.withington.org
I did not recall that this innovation originated with Lisp Machine; 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 Smug Lisp Weenies 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: research.microsoft.com -- a bit earlier than I would have guessed, but for sure Burroughs used microprogramming in the 1960s, for instance.
It may be that Lisp Machines Are Coming Back
Category Programming Language (since the point was to support Lisp)
See original on c2.com