Design of LISP-based Processors
or, Scheme: A Dielectric LISP
or, Finite Memories Considered Harmful
or, Lambda: The Ultimate Opcode dspace.mit.edu/bitstream/handl

Scheme on a chip! The "Project History" section of this paper is hilarious.

@cwebber

Oh, yes, they were smoking some powerful stuff at MIT back in the 70s. I myself found it hard to believe, but research papers (the AI Memo you link to, specifically) leave little doubt: things got dangerously close to a hardware #SchemeMachine.

@acousticmirror @cwebber "the world if" meme about the shining futuristic city, but it's "the world if we had hardware scheme machines instead of x86"

@IngaLovinde @cwebber Oh yeah. This whole idea that the free market will provide for, er, competition and diversity. That gave us x86 and gray boxes everywhere. I doubt a Scheme Machine would have been a commercial success, but it would have been great if it really existed somewhere somehow...

Follow

@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) youtube.com/watch?v=8RSQ6gATnQ

@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.

@acousticmirror @hugoestr @IngaLovinde Symbolics lisp machines were the most powerful graphics development machines at the time and the graphics drivers were written *in lisp*.

@cwebber @acousticmirror @hugoestr @IngaLovinde more over, if i recall correctly: every part of the machine was programmed in a Lisp, and could be inspected / debugged.

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

@meena @acousticmirror @hugoestr @IngaLovinde That's right!

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.

@cwebber @meena @acousticmirror @hugoestr @IngaLovinde
AFAIK it was also incredibly expensive and cheaper general purpose CPUs were developing at a much faster pace. When Symbolics wrote their emulator for the Alpha ISA it ran faster than their fastest bespoke CPUs.

@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.

@acousticmirror @cwebber @meena @hugoestr @IngaLovinde
My kinda cynical response would be "well if Lisp is so great they should have just patched multi-user functionality in". 🙃

Btw compiler tech becoming better was AFAIK another reason that they lost the (price to) performance war.

@csepp @cwebber @acousticmirror @hugoestr @IngaLovinde can somebody explain to me, why a Lisp machine developed today couldn't also be a General Purpose CPU?

that is: it's got a C compiler, who's target is the Machine Lisp it's built on?

@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 @hugoestr @IngaLovinde Nala Ginrut is running this LambdaChip project. It's not really a dedicated #SchemeMachine, or #SchemeOnAChip, it's more like a SBC running embedded Scheme (#Guile, I believe).

lambdachip.com/index/

@acousticmirror @hugoestr @IngaLovinde It's running Guile?!!!

I mean, not shocking if it's Nala but I hadn't heard of this

@cwebber @hugoestr @IngaLovinde The board itself is called the Alonzo Board 😉 . Sadly, it seems like the COVID-derived supply crunch has put a temporary stop on his operations.

@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.

@cwebber @hugoestr @IngaLovinde Yeah, that's a classic demo. (And the software was at least a couple of decades ahead of its time.) I think a #SchemeMachine would be very similar, except maybe for the mullet.

@cwebber
"scripts embedded in the objects, reusable for different parts" — that sounds like blender, just several decades earlier!

@acousticmirror @hugoestr @IngaLovinde

@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 :))

@ArneBab @cwebber @hugoestr @IngaLovinde Oh, yes. A Blender where everything, from the GUI to the actual objects and design elements can be examined, changed, re-evaluated... Amazing stuff.

(Also, hackers should be allowed to drink wine at their workstations as a matter of principle.)

@cwebber @acousticmirror @hugoestr @IngaLovinde Yeah, I worked in the CS lab at PARC where they made Lisp machines and the old timers shook their heads in grief when we talked about modern (for then) dev environments.

@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

@aeva @cwebber @acousticmirror @hugoestr because GC'd languages are much more convenient than C, and Rust is too young?

@IngaLovinde @cwebber @acousticmirror @hugoestr not everyone can use rust. cis people need to program too 🤷‍♀️

@cwebber @acousticmirror @hugoestr @IngaLovinde the lisp machines vs x86 debate is a distraction though because neither architecture is well suited for modern hardware. if we lived in a benevolent world we'd have llvm machines 😏

Sign in to participate in the conversation
Octodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!