@jbz
"Compiled to microcode"?
Sort of... and sort of not.
Probably meant to say "compiled to machine code", like any other machine and compiler. The machine instructions were quite readable, at least after getting used to them. Mostly a stack machine with 256 registers to buffer the top of stack.
MIcrocode is another matter.
LMI had a microcompiler for a while, which could take a (smallish) lisp function and create a single instruction to execute it. Then you'd create a "defsubst" -- a function that would be open-coded -- to persuade the compiler to emit that instruction.
However, this only saved time if instruction fetch and decode dominated execution in normal machine code. It was kind of tricky. (Their marketing folk sure loved it, though.)
Symbolics never released a microcompiler. The micromachine (for the L-machine, that is) had a much wider microinstruction word (sort of like VLIW stuff?). That meant there was much more parallelism going on for each microinstruction. That meant there was no straightforward microcompiler.
Later, the I-machine series no longer had a writeable control store for microcode. It was all in ROM, and that worked pretty well.
The Sunstone chip, the next Symbolics architecture, was going to be a RISC version of all this with no microcode anyway. It was cancelled the day it taped out for its first S-machine chip, sadly.
(And yes, the architectures of the L-, I-, and S-machines were spelling out LISP. The joke was the P-machine was going to be the "penultimate, pocket, parallel" architecture.)
#lispm