Design of LISP-based Processors
or, Scheme: A Dielectric LISP
or, Finite Memories Considered Harmful
or, Lambda: The Ultimate Opcode https://dspace.mit.edu/bitstream/handle/1721.1/5731/AIM-514.pdf?sequence=2&isAllowed=y
Scheme on a chip! The "Project History" section of this paper is hilarious.
@acousticmirror @hugoestr @IngaLovinde Lisp machines existed, were sold commercially. They had built-in hardware garbage collectors and tagged pointers, so what is normally associated with "dynamic languages being slow" was in fact plenty fast because the hardware itself handled it. Were even the world leader in 3d graphics for a while.
Watch this glorious mulleted dude (enby?) drinking wine and demonstrating the software for the future we didn't get (and once had) https://www.youtube.com/watch?v=8RSQ6gATnQU
@acousticmirror @hugoestr @IngaLovinde However, there is a tagged variant of RISC-V, made for the wrong reasons (a broken security model), but contracting with some of the old lisp machine experts to build it.
It would be possible to also have this as a co-processor, not unlike your GPU. In fact, the Symbolics Ivory was exactly like this.
Imagine if you had a "dynamic languages accelerator" chip on your computer!
@acousticmirror @hugoestr @IngaLovinde This is partly why I tend to push back on the anti-meme that "statically typed languages are faster" necessarily. Ahead-of-time checking for errors and speed optimization are two different things, conventionally using the same design on current architectures, but it doesn't have to be this way.
today, every part of my machines is a closed source mysteryware, and cannot be touched, lest i want to be left with an expensive brick
The main problem is that Symbolics' stuff was proprietary, so you could debug it and change it at any level, but it wasn't "yours".
The closest experience you'll get to this these days is Emacs + Guile + Guix. But it doesn't go as far as it would be good to go.
@csepp @cwebber @meena @hugoestr @IngaLovinde Lisp Machines also came from a culture that was somewhat backward-looking. They were single-user machines, designed for the individual, unique, talented Lisp hacker. They weren't meant for the kind of collective, distributed development that Unix culture championed in the 80's. And that's what gave us the Libre Software movement and Linux, not Symbolics.
@meena @cwebber @acousticmirror @hugoestr @IngaLovinde Genera had a C compiler, so it's totally doable. With something like CHERI you could probably even use existing assembly, especially since assembly nowadays is really only used to performance critical inner loops and low level fiddling, neither of which needs to manipulate capabilities.
@cwebber @acousticmirror @hugoestr @IngaLovinde Which tagged variant, CHERI? 🤔
I was actually thinking when I sent the Reduceron link that... maybe hardwiring things like GC isn't the best idea? Something like CHERI with linear capabilites would let you enforce the memory model of a Lisp while letting you use any combination of memory management models.
@ArneBab @acousticmirror @hugoestr @IngaLovinde And... done more right, since it embraced the emacsness in its heart rather than with the embedded python approach Blender did (which is still damn impressive, part of the reason Blender is awesome is that it's kind of emacs'ish... just not emacs'ish enough :))
@cwebber @acousticmirror @hugoestr @IngaLovinde most likely if lisp machine somehow won out over the x86, it would have converged on a similar design: a very different fast ISA hidden away in the hardware, with the x86 or scheme ISA essentially being built in software on top of it with no resemblance to the modern underlying hardware.
@cwebber @acousticmirror @hugoestr @IngaLovinde so like x86 specifically has a low number of registers and a stack that nominally would be living in memory or at least resident in cache. modern x86 processors have massive register files and use a neat trick called register renaming to break up false data dependencies and sometimes treat stack locations as registers iirc
@cwebber @acousticmirror @hugoestr @IngaLovinde i imagine something similar would be needed to flatten out s-expressions into a sequential data structure, because linked lists are extremely not cache friendly. it isn't too hard to imagine, and one you have that a modern high performance lisp machine probably doesn't need a whole lot more
@cwebber @acousticmirror @hugoestr @IngaLovinde there's limits to how much you can pack into hardware though, because your die space and power envelope are precious resources. stuff gets moved out of hardware all the time as systems get faster and it's a net gain. i think GC would eventually end up in software for this reason. most programs today are written in GC'd languages not Crust++ afterall
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!