10 ms·

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.

rjsw 1y ago
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 https://github.com/froggey/Mezzano
- imglorp 1y ago
  LMI here https://github.com/dseagrav/ld https://github.com/dseagrav/ld
  - amszmidt 1y ago
    Mostly dead. Current Lisp Machine shenanigans related to MIT/LMI are at https://tumbleweed.nu/lm-3 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.
    - diggan 1y ago
      > 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 :)
      - amszmidt 1y ago
        Current work is at http://github.com/ams/cadr4 http://github.com/ams/cadr4 And of course .. https://tumbleweed.nu/lm-3 https://tumbleweed.nu/lm-3 .
        rjsw 1y ago
        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.
        amszmidt 1y ago
        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.
        rjsw 1y ago
        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?
        therealcamino 1y ago
        At the top of the readme it says "There will be no attempt at making this synthesizable (at this time)!".
        rjsw 1y ago
        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 https://github.com/lisper/cpus-caddr
- eadmund 1y ago
  > What does a Lisp Machine of the future look like? Depends on what one means by that. Dedicated hardware? I doubt that we’ll ever see that again, although of course I could be wrong. A full OS? That’s more likely, but only just. If it had some way to run Windows, macOS or Linux programs (maybe just emulation?) then it might have a chance. As a program? Arguably Emacs is a Lisp Machine for 2025. Provocative question: would a modern Lisp Machine necessarily use Lisp? I think that it probably has to be a language like Lisp, Smalltalk, Forth or Tcl. It’s hard to put into words what these very different languages share that languages such as C, Java and Python lack, but I think that maybe it reduces down to elegant dynamism?
  - amszmidt 1y ago
    > 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.
  - 0xpgm 1y ago
    > Dedicated hardware? I doubt that we’ll ever see that again, although of course I could be wrong. Since we're now building specialized hardware for AI, emergence of languages like Mojo that take advantage of hardware architecture and what I interpret as a renewed interest in FPGAs perhaps specialized hardware is making a comeback. If I understand computing history correctly, chip manufacturers like Intel optimized their chips for C language compilers to take advantage of economies of scale created by C/Unix popularity. This came with the cost of killing off lisp/smalltalk specialized hardware that gave these high level languages decent performance. Alan Kay famously said that people who are serious about their software should make their own hardware.
chillpenguin 1y ago
Smalltalk was the lisp machine of the future. Of course, now even Smalltalk is a thing of the past.
lproven 1y ago
> we need the “lisp machine” of the future Totally agree. Here's my idea: stick a bunch of NVRAM DIMMs into a big server box, along with some ordinary SDRAM. So, say, you get a machine with the first, say, 16GB of RAM is ordinary RAM, and then the 512GB or 1TB of RAM above that in the memory map is persistent RAM. It keeps its contents when the machine is shut off. That is it. No drives at all. No SSD. All its storage is directly in the CPU memory map. Modify Interim or Mezzano to boot off a USB key into RAM and store a resume image in the PMEM part of the memory map, so you can suspend, turn off the power, and resume where you were when the power comes back. https://github.com/froggey/Mezzano https://github.com/froggey/Mezzano https://github.com/mntmn/interim https://github.com/mntmn/interim Now try to crowbar SBCL into this, and as many libraries and frameworks as can be sucked in. All of Medley/Interlisp, and some kind of convertor so SBCL can run Interlisp. You now have an x86-64 LispM, with a whole new architectural model: no files, no disks, no filesystem. It's all just RAM. Workspace at the bottom, disposable. OS and apps higher up where it's nonvolatile. I fleshed this out a bit here: https://archive.fosdem.org/2021/schedule/event/new_type_of_computer/ https://archive.fosdem.org/2021/schedule/event/new_type_of_c... And here... https://www.theregister.com/2024/02/26/starting_over_rebooting_the_os/ https://www.theregister.com/2024/02/26/starting_over_rebooti...

rjsw 1y ago

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 https://github.com/froggey/Mezzano

imglorp 1y ago
LMI here https://github.com/dseagrav/ld https://github.com/dseagrav/ld
- amszmidt 1y ago
  Mostly dead. Current Lisp Machine shenanigans related to MIT/LMI are at https://tumbleweed.nu/lm-3 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.
  - diggan 1y ago
    > 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 :)
    - amszmidt 1y ago
      Current work is at http://github.com/ams/cadr4 http://github.com/ams/cadr4 And of course .. https://tumbleweed.nu/lm-3 https://tumbleweed.nu/lm-3 .
      - rjsw 1y ago
        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.
        amszmidt 1y ago
        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.
        rjsw 1y ago
        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?
        therealcamino 1y ago
        At the top of the readme it says "There will be no attempt at making this synthesizable (at this time)!".
        rjsw 1y ago
        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 https://github.com/lisper/cpus-caddr
eadmund 1y ago
> What does a Lisp Machine of the future look like? Depends on what one means by that. Dedicated hardware? I doubt that we’ll ever see that again, although of course I could be wrong. A full OS? That’s more likely, but only just. If it had some way to run Windows, macOS or Linux programs (maybe just emulation?) then it might have a chance. As a program? Arguably Emacs is a Lisp Machine for 2025. Provocative question: would a modern Lisp Machine necessarily use Lisp? I think that it probably has to be a language like Lisp, Smalltalk, Forth or Tcl. It’s hard to put into words what these very different languages share that languages such as C, Java and Python lack, but I think that maybe it reduces down to elegant dynamism?
- amszmidt 1y ago
  > 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.
- 0xpgm 1y ago
  > Dedicated hardware? I doubt that we’ll ever see that again, although of course I could be wrong. Since we're now building specialized hardware for AI, emergence of languages like Mojo that take advantage of hardware architecture and what I interpret as a renewed interest in FPGAs perhaps specialized hardware is making a comeback. If I understand computing history correctly, chip manufacturers like Intel optimized their chips for C language compilers to take advantage of economies of scale created by C/Unix popularity. This came with the cost of killing off lisp/smalltalk specialized hardware that gave these high level languages decent performance. Alan Kay famously said that people who are serious about their software should make their own hardware.

chillpenguin 1y ago

Smalltalk was the lisp machine of the future. Of course, now even Smalltalk is a thing of the past.

lproven 1y ago

> we need the “lisp machine” of the future Totally agree. Here's my idea: stick a bunch of NVRAM DIMMs into a big server box, along with some ordinary SDRAM. So, say, you get a machine with the first, say, 16GB of RAM is ordinary RAM, and then the 512GB or 1TB of RAM above that in the memory map is persistent RAM. It keeps its contents when the machine is shut off. That is it. No drives at all. No SSD. All its storage is directly in the CPU memory map. Modify Interim or Mezzano to boot off a USB key into RAM and store a resume image in the PMEM part of the memory map, so you can suspend, turn off the power, and resume where you were when the power comes back. https://github.com/froggey/Mezzano https://github.com/froggey/Mezzano https://github.com/mntmn/interim https://github.com/mntmn/interim Now try to crowbar SBCL into this, and as many libraries and frameworks as can be sucked in. All of Medley/Interlisp, and some kind of convertor so SBCL can run Interlisp. You now have an x86-64 LispM, with a whole new architectural model: no files, no disks, no filesystem. It's all just RAM. Workspace at the bottom, disposable. OS and apps higher up where it's nonvolatile. I fleshed this out a bit here: https://archive.fosdem.org/2021/schedule/event/new_type_of_computer/ https://archive.fosdem.org/2021/schedule/event/new_type_of_c... And here... https://www.theregister.com/2024/02/26/starting_over_rebooting_the_os/ https://www.theregister.com/2024/02/26/starting_over_rebooti...