18 ms·

There is a long history of CPUs tailored to specific languages: - Lisp/lispm - Ada/iAPX - C/ARM - Java/Jazelle Most don't really take off or go in differen

There is a long history of CPUs tailored to specific languages: - Lisp/lispm - Ada/iAPX - C/ARM - Java/Jazelle Most don't really take off or go in different directions as the language goes out of fashion.

Symmetry 1y ago
Also a fairly interesting Haskell efforts. https://mn416.github.io/reduceron-project/ https://mn416.github.io/reduceron-project/ These range from a few instructions to accelerate certain operations, to marking memory for the garbage collector, to much deeper efforts.
jonathaneunice 1y ago
Also: UCSD p-System, Symbolics Lisp-on-custom hardware, ... Historically their performance is underwhelming. Sometimes competitive on the first iteration, sometimes just mid. But generally they can't iterate quickly (insufficient resources, insufficient product demand) so they are quickly eclipsed by pure software implementations atop COTS hardware. This particular Valley of Disappointment is so routine as to make "let's implement this in hardware!" an evergreen tarpit idea. There are a few stunning exceptions like GPU offload—but they are unicorns.
- noosphr 1y ago
  They were a tar pit in the 1980s and 1990s when Moores law meant a 16x increase in processor speed every 6 years. Right now the only reason why we don't have new generations of these eating the lunch of general purpose CPUs is that you'd need to organize a few billion transistors into something useful. That's something a bit beyond what just about everyone (including Intel now apparently) can manage.
  - jonathaneunice 1y ago
    Sure. The need to organize millions (now 10s to 100s of billions) of transistors to do something useful, the economics and will to bring those to market, the need to coordinate functions baked into hardware with the faster moving and vastly more-plastic software world—oh, and Amdahl's Law. They are the tar pit. Transistor counts skyrocket, but the principles and obstacles have not changed one iota in over 50 years.
    - noosphr 1y ago
      The obstacles have absolutely changed. A processor from 2015 is good enough for most daily tasks in 2025. Try saying that about one from 1985 to 1995. The issue today isn't that by the time you get to market with SOTA manufacturing on a custom 10x design you only have two years before general purpose chips are just as fast. It's getting to the market in the first place.
pjmlp 1y ago
Well, one could argue that modern CPUs are designed as C Machine, even more so that now everyone is adding hardware memory tagging as means to fix C memory corruption issues.
- johnnyjeans 1y ago
  Only if you don't understand the history of C. B was a LCD grouping of assembler macros for a typical register machine, C just added a type system and a couple extra bits of syntax. C isn't novel in the slightest, you're structuring and thinking about your code pretty similar to a certain style of assembly programming on a register machine. And yes, that type of register machine is still the most popular way to design an architecture because it has qualities that end up being fertile middle ground between electrical engineers and programmers. Also there are no languages that reflect what modern CPUs are like, because modern CPUs obfuscate and hide much of how the way they work. Not even assembly is that close to the metal anymore, and it even has undefined behavior these days. There was an attempt to make a more explicit version of the hardware with Itanium, and it was explicitly a failure for much of the same reason than iAPX432 was a failure. So we kept the simpler scalar register machine around, because both compilers and programmers are mostly too stupid to work with that much complexity. C didn't do shit, human mental capacity just failed to evolve fast enough to keep up with our technology. Things like Rust are more the descendant of C than the modern design of a CPU.
  - bee_rider 1y ago
    What do you think a language based on a modern CPU architecture would look like? The big deal is representing the OoO and speculative execution, right? Text files seem a bit too sequential in structure, maybe we can figure out a way to represent the dependency graphs directly.
    - johnnyjeans 1y ago
      I envision an inflected grammar. That sounds crazy I know, but x64 is an inflected language already. The pointer arithmetic you can attach to a register isn't an expression or a distinct group of words, it's a suffix. Part of the word, indistinguishable from it. Someone once did a great job of explaining to me how that mapped to microcode in a shockingly static way and it blew my mind. I see affixes for controlling the branch predictor. Operations should also be inflected in a contextual way, making their relationship to other operations explicit, giving you control over how things are pipelined. Maybe take some inspiration from afro-asiatic languages, use kind of consonantal root system. The end result would look nothing like any other programming language and would die in obscurity, to be honest. But holy shit it would be really fucking cool.

Symmetry 1y ago

Also a fairly interesting Haskell efforts. https://mn416.github.io/reduceron-project/ https://mn416.github.io/reduceron-project/ These range from a few instructions to accelerate certain operations, to marking memory for the garbage collector, to much deeper efforts.

jonathaneunice 1y ago

Also: UCSD p-System, Symbolics Lisp-on-custom hardware, ... Historically their performance is underwhelming. Sometimes competitive on the first iteration, sometimes just mid. But generally they can't iterate quickly (insufficient resources, insufficient product demand) so they are quickly eclipsed by pure software implementations atop COTS hardware. This particular Valley of Disappointment is so routine as to make "let's implement this in hardware!" an evergreen tarpit idea. There are a few stunning exceptions like GPU offload—but they are unicorns.

noosphr 1y ago
They were a tar pit in the 1980s and 1990s when Moores law meant a 16x increase in processor speed every 6 years. Right now the only reason why we don't have new generations of these eating the lunch of general purpose CPUs is that you'd need to organize a few billion transistors into something useful. That's something a bit beyond what just about everyone (including Intel now apparently) can manage.
- jonathaneunice 1y ago
  Sure. The need to organize millions (now 10s to 100s of billions) of transistors to do something useful, the economics and will to bring those to market, the need to coordinate functions baked into hardware with the faster moving and vastly more-plastic software world—oh, and Amdahl's Law. They are the tar pit. Transistor counts skyrocket, but the principles and obstacles have not changed one iota in over 50 years.
  - noosphr 1y ago
    The obstacles have absolutely changed. A processor from 2015 is good enough for most daily tasks in 2025. Try saying that about one from 1985 to 1995. The issue today isn't that by the time you get to market with SOTA manufacturing on a custom 10x design you only have two years before general purpose chips are just as fast. It's getting to the market in the first place.

pjmlp 1y ago

Well, one could argue that modern CPUs are designed as C Machine, even more so that now everyone is adding hardware memory tagging as means to fix C memory corruption issues.

johnnyjeans 1y ago
Only if you don't understand the history of C. B was a LCD grouping of assembler macros for a typical register machine, C just added a type system and a couple extra bits of syntax. C isn't novel in the slightest, you're structuring and thinking about your code pretty similar to a certain style of assembly programming on a register machine. And yes, that type of register machine is still the most popular way to design an architecture because it has qualities that end up being fertile middle ground between electrical engineers and programmers. Also there are no languages that reflect what modern CPUs are like, because modern CPUs obfuscate and hide much of how the way they work. Not even assembly is that close to the metal anymore, and it even has undefined behavior these days. There was an attempt to make a more explicit version of the hardware with Itanium, and it was explicitly a failure for much of the same reason than iAPX432 was a failure. So we kept the simpler scalar register machine around, because both compilers and programmers are mostly too stupid to work with that much complexity. C didn't do shit, human mental capacity just failed to evolve fast enough to keep up with our technology. Things like Rust are more the descendant of C than the modern design of a CPU.
- bee_rider 1y ago
  What do you think a language based on a modern CPU architecture would look like? The big deal is representing the OoO and speculative execution, right? Text files seem a bit too sequential in structure, maybe we can figure out a way to represent the dependency graphs directly.
  - johnnyjeans 1y ago
    I envision an inflected grammar. That sounds crazy I know, but x64 is an inflected language already. The pointer arithmetic you can attach to a register isn't an expression or a distinct group of words, it's a suffix. Part of the word, indistinguishable from it. Someone once did a great job of explaining to me how that mapped to microcode in a shockingly static way and it blew my mind. I see affixes for controlling the branch predictor. Operations should also be inflected in a contextual way, making their relationship to other operations explicit, giving you control over how things are pipelined. Maybe take some inspiration from afro-asiatic languages, use kind of consonantal root system. The end result would look nothing like any other programming language and would die in obscurity, to be honest. But holy shit it would be really fucking cool.