> Provocative question: would a modern Lisp Machine necessarily use Lisp?
Seeing that not even "Original Gangster" Lisp Machine used Lisp ...
Both the Lambda and CADR are RISCy machines with very little specific to Lisp (the CADR was designed specifically to just run generic VM instructions, one cool hack on the CADR was to run PDP-10 instructions).
By Emacs you definitely mean GNU Emacs -- there are other implementations of Emacs. To most people, what the Lisp Machine was (is?), was a full operating system with editor, compiler, debugger and very easy access to all levels of the system. Lisp .. wasn't the really interesting thing, Smalltalk, Oberon .. share the same idea.
Currently working on an accurate model of the MIT CADR in VHDL, and merging the various System source trees into one that should work for Lambda, and CADR.
Maybe try replacing the ALU with one written directly in Verilog, I suspect this will run a lot faster than building it up from 74181+74182 components.
The current state is _very_ fast in simulation to the point where it is uninteresting (there are other things to figure out) to write something as a behavioral model of the '181/'182.
~100 microcode instructions takes about 0.1 seconds to run.
I was thinking more of a behavioral model of the whole ALU, just so that the FPGA tools can map it onto a collection of the smaller ALUs built into each slice.
What clock speed does your latest design synthesize at?
There was already a design of CADR for FPGAs [1] that does synthesize (and boot), I don't know why amszmidt needed to start again from scratch or if his design is a modification of the earlier one.
A similar comment applies to lm-3. Maybe it is built on a fork of the previous repo, it is hard to tell.
> [...] and notebooks have embedded code in documentation since Mathematica in the 1980's.
Late 80's, very late ... but the concept of "notebooks" predates Mathematica by at least a decade (it was very common to embed structure in source code files with markup).
LET* may be needed if the operations are time-dependent (so if the move-to operation must happen before the delay operation), as LET does the binding in parallel (at least, according to the spec).
While the Lisp Machine does use lists, the benefits of CDR coding were / are quite overblown. The Lisp Machine also used other data structures far heavier than lists.
The Lisp Machine macroinstructions aren't that complicated, it is a basically stack based machine -- the most complicated thing was handling of the function arguments from Lisp (FEF); which has complicated semantics when it comes to handling optional, keywords, and what not arguments.
Not sure where this "analysis" comes from, but the demise of the Lisp Machine has generally been agreed that it had to do more with the speed of technological advances than Common Lisp -- by the time Common Lisp was standardized, for all intents and purposes, all Lisp Machine companies where already defunct.
Common Lisp was definitely not designed with the intention of better performance, the intention was literally to have a _common_ Lisp language that multiple implementations could use and where porting programs would be much easier. One needs to remember that when Common Lisp was first drafted, there where dozens of Lisp dialects -- all of them different.
The list of CPUs is a very large span, some predating Common Lisp (CLtL1 is from 1984, CLtL2 from 1990, and ANSI Common Lisp from 1996) by close to several years (VAX, from 1977).
But other than that, the idea of a not-Unix system does fall into those two buckets ... make it Unix, or rewrite everything. One can see this in Oberon, Smalltalk-78, Mezzano, etc...
> 1. Commit 3ba50ec which Marcan is complaining about was pushed in 2008 and didn't just delete attrib specifically, but all (?) VCS comments indiscriminately. The file was barely touched since
This by itself just looks to me like someone getting rid of the old CVS comments that are messing up the headers. Maybe the problem is that younger people don’t recognize what a cvs header is?
The threading code does seem to be "similar" enough to warrant some investigation, but from the looks no license notice was "removed". Even the threading code in question has never had one, from the initial import from CVS/Subversion.
Making a mountain out of a molehill .... before the molehill is even there?
Seeing that not even "Original Gangster" Lisp Machine used Lisp ...
Both the Lambda and CADR are RISCy machines with very little specific to Lisp (the CADR was designed specifically to just run generic VM instructions, one cool hack on the CADR was to run PDP-10 instructions).
By Emacs you definitely mean GNU Emacs -- there are other implementations of Emacs. To most people, what the Lisp Machine was (is?), was a full operating system with editor, compiler, debugger and very easy access to all levels of the system. Lisp .. wasn't the really interesting thing, Smalltalk, Oberon .. share the same idea.