The MIT CONS computer and its commercial descendants at Symbolics and LMI was not a parallel architecture. It was a fairly conventional uniprocessor CPU which happened to have a register and instruction architecture that provided some hardware acceleration for typical "LISP" tasks (specifically tagged pointers: the "pointer" value had a bit telling the CPU whether to load the value as-is or indirect through it to load the next value).

As for why they were expensive: they were small market pre-VLSI minicomputers being sold in the late 70's and early 80's. They competed most directly with machines like the MicroVAX, and weren't particularly expensive for that market, AFAIK. Assembling and testing a few thousand ICs into a single computer is just inherently expensive.

Well, I suppose that the conjunction of a lower demand and a more complex processor (which executed Lisp directly) is a good reason for them to be expensive. The complexity is a problem in the beginning, and if the demand had been higher the prices would lowered, but... I think the main reason of the failure was due to the business side and not the technical merits, unfortunately history shows that technological success has more to do with business skills (i.e., ms) than with the technology (i.e., Lisp Machines, 80's Apples...)

Well, given that Sun workstations started running commercial Lisps at some "reasonable speed" around this time, that pretty much doomed Symbolics/LMI/TI's efforts. The cost differential between the specialized hardware (ca $100K) and the commodity workstations (ca $10-20K) was just too much.

When you think about it at another level, there's not enough difference between a decent Lisp compiler producing 68K instructions for the Lisp primivites on the Sun workstation, and the microcode in the Lisp machine running micro-instructions implementing Lisp primitives. So the commodity hardware won out, as it usually does.

>> (which executed Lisp directly)

Uh, the machine's architectures were probably designed to be more amenable to Lisp-esque features (e.g., garbage collection, tagged types at runtime, native pair operations, etc); I suspect the machines didn't execute Lisp directly for the same reason that an x86 doesn't execute C directly...

The microarchitecture really implemented Lisp primitives like cons, car, cdr, array ref as opcodes, etc. That's about as close to executing Lisp directly as you can get.

That's how it's commonly explained, but it's not really correct. The bitsavers.org folks have a copy of the original Lisp Machine paper:

http://www.bitsavers.org/pdf/mit/cons/TheLispMachine_Nov74.p...

The pointer/register format was very LISP-friendly, but the actual instructions are much more conventional. The trick is that instead of having to test the tag bits with separate instructions, the "load" instruction equivalent does it in hardware.

Well, if you look on pages 13-14 of the manual you referenced, you'll find instruction codes for PCAR, PCDR, SCDR, SCDDR, NCONS, CONS, LIST (alloc), CxxxR, CxxxXR, GET, GETL, ASSQ, ASSOC, etc. Seems like Lisp primitive instructions to me.

Keep in mind that "car" and "cdr" were opcodes stolen from processors that existed way before lisp machine :)

Well, evidently the processors worked with binary instructions, but these were based on primitive Lisp operations. There's more information in http://hdl.handle.net/1721.1/5731 and quoting from the wikipedia http://en.wikipedia.org/wiki/Lisp_machine

  These machines had hardware support for various primitive
  Lisp operations (data type testing, CDR coding) and also
  hardware support for incremental garbage collection. They
  ran large Lisp programs very efficiently.

The cost of lisp machines also include much of the cost of developing the lisp machine environment. That probably cost more than the software that came with suns, apollos, etc and the workstations had more volume, so their comparable cost per machine was significantly less.