Developing your own special-purpose hardware is easier than ever these days. There are numerous open-source off-the-shelf FGPAs that are mature and fast.
One of the biggest issues is that a FPGA design running at 50-100 MHz (compare to the contemporaneous Cray-1 80MHz), with little memory that can be used as cache, gets blown out of the water by a +3GHz CPU with megabytes of on die cache. In terms of just being a "Lisp Machine", it only makes sense as retro-computing. Even a CADR, 3600 etc. simulator running on a fast x86-64 CPU would be (a lot) faster.
Aren't we loosing the focus by looking at the Lisp Machines only from "HW" point of view? They were "ported" on Alpha, and I can run them today on a x86-64 VM.
I think we're overwhelmed by nostalgia and this stops us from looking at what's important: software. We are missing the software pieces that made the Lisp Machines. We don't have those and this is more important than not having a CL CPU.
I would hate to have a Lisp Machine made with today's custom hardware and all the C/C++/Java/Python guys come and ask: what was the fuss was all about? Where's that IDE from 25 years ago you so proudly preached?
Well, we do have a rather early fully legal 1981 copy of the system, and one or more illicit but no one seems to care copies of much later Symbolics systems (don't know if those included source, though). So that in part an issue of software archaeology, when we can also ask most if not all of the people involved about details.
And I fully agree the focus should be on the software, as I hope I made clear in other comments in this topic.
What do they cost in single unit quantities, or rather, what does a development board that I can stick GiBs of hopefully ECC DRAM cost? And the development tools?
I know I can do this with small scale ones, including some of the tools, on sub-$100/$200 boards with not a lot of memory (the research lowRISC has prompted me to do has been fascinating). If the answer to the above is 6 figures, the intersection of those who can afford it and those who are inclined to do it would be small.
Maybe not 0, then again, at what speed could you get a synchronous microcoded CPU working? Aren't we still talking wayway below +3GHz, like the 50-100MHz I just cited? Is 200MHz possible?
I've read of one that uses magic (and no doubt $$$ in tools) to translate your sync design into an faster async one in the middle of their magic FPGAs, but even then I don't recall the potential speed breaking past a GHz if that. Although that was a while ago, 1-2 Moore's Law doublings ^_^.
Flip side, are the FPGA companies going to open up their kimonos to allow a lot more people to design in their increasingly inexpensive (Moore's Law) parts?
I'm not saying it is economically competitive. (It is possible pay over $25k for a really high end FPGA) And if you are just synthesizing a general purpose synchronous CPU you definitely not going to get a lot of bang-for-the-buck, because you are going against the grain of what an FPGA can provide. In that instance you're just vetting your design until you convert it over to a mask-programmable "equivalent", or do a full-custom design. The interesting things about an FPGA would be to use its inherent parallelism, fine grain programmability, and the reprogramability to run circles around something constrained by a von Neumann bottleneck in the cache hierarchy.
As to clock speeds, here's part of the abstract to a white paper that might interest you:
"A clock rate higher than 500 MHz can be supported
on a mid-speed grade 7 series device with almost
100% of the logic slices, more than 90% of the DSP48
slices, and 70% of the block RAMs utilized. This
requires the designer to follow some rather simple
design rules that cover both algorithmic and
implementation aspects. These rules are reviewed in
the paper."
...but clock speed isn't necessarily a super interesting factor if your data bus is 2048 bits wide, with a pipline 100 stages deep, comparing to say 64 bits wide and 10 stages deep on a CPU. Again, this is not to say that anyone should try implementing a Lisp machine on an FPGA to try to take market share away from Intel.
Developing your own special-purpose hardware is easier than ever these days. There are numerous open-source off-the-shelf FGPAs that are mature and fast.