4 ms·
Yep. And nary a tear is shed these days over the death of the so-called superior Lisp machines.
by ezekiel68 2y ago
Yep. And nary a tear is shed these days over the death of the so-called superior Lisp machines.
- rwmj 2y agoMaybe not in any position to do anything about it, but I'm quite sad :-/
- lioeters 2y agoI was gonna say, I do shed a tear now and then dreaming of Lisp machines and the future that could have been.
- gpderetta 2y agoThe Spirit of the Machine still lives in some form in emacs.
- OhMeadhbh 2y agoMeh. Lisp machines still exist. They're just simulated in various Lisp's runtime environments. It turns out that a RISC machine running a Lisp interpreter or an executable compiled from Lisp source tends to perform better than a tagged/cdr Lisp Machine w/ hardware GC. That being said... I've wanted to implement an old Explorer using an FPGA for a while. Maybe if I just mention it here, someone will get inspired and do it before I can get to it.
- hayley-patton 2y agoLisp machines didn't have hardware GC, though they had hardware support for read/write barriers.
- lispm 2y agoKind of. A lot of the GC support in the Symbolics 3600 architecture is on the Microcode level (current CPUs usually don't have such operations in Microcode). The word size of the CPU is 36bit. The CPU operations don't deal with the type and gc tags on the instruction level, this is done on the Microcode level. Things like "invisible pointers" are also dealt on the Microcode level. Ephemeral GC, concentrates on garbage collecting objects in RAM: For example every memory page has a page tag, which marks it modified or not. The ephemeral GC uses this to scan only over changed pages in memory. The virtual memory subsystem keeps a table of swapped-out pages pointing to ephemeral pages. The EGC can then use this information...