←back to thread

The Medley Interlisp Project: Reviving a Historical Software System [pdf]

(interlisp.org)
117 points pamoroso | 1 comments | 29 Jun 25 14:45 UTC | HN request time: 0.001s | source
Show context
jshaqaw ◴[29 Jun 25 18:35 UTC] No.44415275[source]▶
Retro lisp machines are cool. Kudos to the team. Love it.

That said… we need the “lisp machine” of the future more than we need a recreation.

replies(3): >>44416054 #>>44425374 #>>44433544 #
rjsw ◴[29 Jun 25 20:16 UTC] No.44416054[source]▶
What does a Lisp Machine of the future look like?

There is Mezzano [1] as well as the Interlisp project described in the linked paper and another project resurrecting the LMI software.

[1] https://github.com/froggey/Mezzano

replies(2): >>44418876 #>>44422962 #
imglorp ◴[30 Jun 25 03:05 UTC] No.44418876[source]▶
LMI here https://github.com/dseagrav/ld
replies(1): >>44419825 #
amszmidt ◴[30 Jun 25 05:44 UTC] No.44419825{3}[source]▶
Mostly dead. Current Lisp Machine shenanigans related to MIT/LMI are at https://tumbleweed.nu/lm-3 ...

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.

replies(1): >>44421732 #
diggan ◴[30 Jun 25 10:57 UTC] No.44421732{4}[source]▶
> Currently working on an accurate model of the MIT CADR in VHDL

Sounds extremely interesting, any links/feeds one could follow the progress at?

The dream of running lisp on hardware made for lisp lives on, against all odds :)

replies(1): >>44423105 #
amszmidt ◴[30 Jun 25 13:34 UTC] No.44423105{5}[source]▶
Current work is at http://github.com/ams/cadr4

And of course .. https://tumbleweed.nu/lm-3 .

replies(1): >>44423437 #
rjsw ◴[30 Jun 25 14:04 UTC] No.44423437{6}[source]▶
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.
replies(1): >>44423701 #
amszmidt ◴[30 Jun 25 14:24 UTC] No.44423701{7}[source]▶
From what I see -- that is not the case.

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.

replies(1): >>44428846 #
rjsw ◴[30 Jun 25 23:02 UTC] No.44428846{8}[source]▶
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?

replies(1): >>44429917 #
therealcamino ◴[01 Jul 25 02:07 UTC] No.44429917{9}[source]▶
At the top of the readme it says "There will be no attempt at making this synthesizable (at this time)!".
replies(1): >>44442675 #
1. rjsw ◴[02 Jul 25 12:00 UTC] No.44442675{10}[source]▶
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.

[1] https://github.com/lisper/cpus-caddr