3 ms·
I think about this often. I'm a hardware designer (digital design asic fpga), so in theory I could help here. I don't really know what was special about the l
by DigitalJack 9y ago
I think about this often. I'm a hardware designer (digital design asic fpga), so in theory I could help here. I don't really know what was special about the lisp hardware though... As far as I could tell it was mainly about helping with the type system and getting that to run at a reasonable speed on hardware of the day.
So I've dismissed the idea of a custom processor. It just doesn't seem to have much value vs using ARM or RISC-V or x64.
I've thought about the kernel aspect, but this mainly seems like drudge work. reimplementing stuff that's been a solved problem for a long time with linux. Not to mention drivers, which would be a massive massive effort.
So I sort of settled on the idea of a lisp based userland. That seems at least feasible.
I don't really understand containers well enough to understand what exactly is exposed to a program you are writing. I've heard you can run statically compiled programs without installing a base distribution. So maybe that would be where to start.
- gglitch 9y ago"Lisp-based userland" is how I'm going to describe Emacs from now on.
- zokier 9y agoI would imagine that LISPy CPU would have stuff like CONS/CAR/CDR as primitive instructions, and probably memory management heavily optimized for processing lists.
- msla 9y agoThe original LISP machine, the IBM 704, had CAR and CDR as primitives. And boy, were they primitive: > These names are hold-overs from the original implementation of LISP on the IBM 704. That machine had partial-word instructions to reference the address and decrement parts of a machine location. The a of CAR comes from "address", the d of CDR comes from "decrement". the c and r come from "contents of" and "register". Thus CAR could be read "contents of address part of register". http://www.iwriteiam.nl/HaCAR_CDR.html http://www.iwriteiam.nl/HaCAR_CDR.html