5 ms·

Opening up the topic: is there any work, nowadays, on making a CPU custom-made for one language, implementing in hardware some of its mechanisms? Or at least FP

by aredox 2y ago

Opening up the topic: is there any work, nowadays, on making a CPU custom-made for one language, implementing in hardware some of its mechanisms? Or at least FPGA implementations? Apart from CHERI extensions, and a few research papers on hardware-accelerated garbage collection (which I find super cool, and wonder why it isn't getting into actual production, given e.g. how stable Java GC is and how many huge companies use Java. Or maybe offloading it to an FPGA? The same way we have GPUs and TPUs for certain classes of computation?).

adrianmsmith 2y ago
I heard (but don't know any details) that Apple M series processors have special instructions which are useful for objc_msgsend and other functions called frequently by Objective-C.
alexisread 2y ago
Greenarrays comes to mind, it's a Forth-oriented chip: https://news.ycombinator.com/item?id=23142322 https://news.ycombinator.com/item?id=23142322 The article doesn't really mention transputers, which were existent at the time and were remarkably similar in vision, with parallel multiprocessing, hardware network links, the Occam language, a ground-up Helios OS, and custom graphics card (Blossom, which would lead to the VGA standard). Having a 3-element hardware stack somewhat restricts the use of languages on it - I imagine that Occam is similar to Forth in operation?
- aredox 2y ago
  Oh, thanks, I had forgotten about those crazy forthers (forthists? forthians?)!
  - aeonik 2y ago
    Goth -> Gothic Therefore Forth -> Forthic
    - Y_Y 2y ago
      North -> Norsemen Forth -> Forsemen (The less gendered "Fordlander" is also acceptable)
  - aeonik 2y ago
    Also, Forthsider, from the Firth of Forth?
- ssrc 2y ago
  Occam looks like a concurrent Pascal, not like a Forth. The transputer had a 3-element hardware stack but it was used more like a cache for the workspace (kind of the memory stack). You can still find around the manual "Transputer Instruction Set - a compiler writer's guide" that explains how you would do that (section 5.3 Expression Evaluation). Apart from Occam, there where C, C++ and Fortran compilers. Targeting the transputer is not more difficult than any other stack machine (like the JVM, the .Net CLR, CPython or Pascal p-code). The weird/interesting thing about the transputer is that it is also an operating system: two task queues (high/low priority), preemptive scheduling and communication through channels (that can be one of the 4 serial ports or memory based).
mepian 2y ago
Azul was actually selling servers with hardware-accelerated GC and other interesting features for Java: https://www.azul.com/newsroom/azul-systems-to-unveil-industrys-most-scalable-platform-for-business-java-applications/ https://www.azul.com/newsroom/azul-systems-to-unveil-industr...
- dfox 2y ago
  Then they found a way how to (ab)use amd64 MMU to do more or less the same thing that they had custom CPU architecture for (ie. GC barriers in hardware).
  - rbanffy 2y ago
    A real shame. When they figured that out, their innovative hardware was doomed.
rjsw 2y ago
There is JOP [1] for Java. [1] https://www.jopdesign.com/ https://www.jopdesign.com/
llm_trw 2y ago
There are projects for this, but right now Moore's law is still shuffling along well enough that by the time you'd get to market general processors will still be better, remembering that you need on the order of $1b to design a modern CPU. Once it's truly dead pushing more features into silicon will the be only way we can get speedups and this will become a major research area again.
- aredox 2y ago
  We could argue the same about highly parallel computations, yet discrete GPU cards exist. I am also old enough to remember the same thing attempted for physics in games, PhysX, which had its own cards (PPU) built by ASUS and a couple others. There is also hardware acceleration for many audio and video codecs. "GC as a codec" doesn't strike me as something crazy: both are upgraded from time to time, but both are stable enough that hardware implementations are relevant over several years. Android phones would certainly benefit from it!
  - cmrdporcupine 2y ago
    I think "do this matrix math and draw these polygons Really Really Fast" is specialized enough that GPUs are on the whole compelling as specialized hardware. That and this is a massive huge market which can benefit from economies of scale and Moore's law itself. Accelerating a particular language runtime is a different story. TBH people don't seem to have a problem generally with "throwing cycles away" and adopting languages like Python which have a pretty slow execution story. There's clearly not much of an economic advantage in optimization for processor throughput, otherwise more stuff would be getting [re]written in systems languages like C/C++/Rust/Zig etc, which would be a lot cheaper than developing custom hardware. And frankly most of the stuff that gets funding and people seem to get excited about in our industry right now... doesn't need much CPU. It's mostly just glue languages waiting on I/O. Apart from the ML/LLM hype right now, which relies heavily on... GPUs. I have a book here somewhere on the Linn Rekursiv hardware. Custom OO system in hardware in the 80s. Up there with Lisp machines as exotic and interesting "paths not taken".
    - 2y ago
rbanffy 2y ago
I remember someone mentioning an attempt to make all message passing in Smalltalk asynchronous running on separate threads, but I don't think anyone built a massively multithreaded CPU for that (besides, not that many messages are in flight at any given time, at least not on a desktop).
- jdougan 2y ago
  Could have meant RoarVM. https://github.com/smarr/RoarVM https://github.com/smarr/RoarVM
sillywalk 2y ago
They're not mainstream, but IBM's mainframes since Z14 have something called the Guarded Storage Facility which provides hardware assisted Java Garbage Collection[0], and Oracle's M8 has some hardware acceleration for Java "Streams"[1]. [0] https://www.ibm.com/support/pages/pause-less-garbage-collection-java-ibm-z https://www.ibm.com/support/pages/pause-less-garbage-collect... [1] https://www.oracle.com/a/ocom/docs/sparc-t8-m8-server-architecture.pdf https://www.oracle.com/a/ocom/docs/sparc-t8-m8-server-archit...
samatman 2y ago
This approach got a bad reputation by the late 1980s, thanks to some spectacular failures like the iAPX 432. The death of the Lisp Machine market wasn't spectacular in the same way, but they weren't a commercial success either, and contributed to the sentiment that tailoring the hardware for specific languages wasn't the way forward. You'll still find people making the case that we have continued to specialize computer hardware for a specific language, that language being C. They kind of have a point. I see it as more symbiotic than that: C caught on in large part because its abstract machine was a good fit for real hardware†, and that real hardware is the way it is because it's a Pareto-optimal way to do computation. Fact is that most languages don't have a semantics which could be accelerated much in hardware. Take Java for an example: it's possible to implement the JVM as a chip, but then you have a stack machine, and you can't JIT it onto a register architecture. What we do now is make the chip as fast as we can at doing the basic things a computer needs to do, and only that (this is the essence of RISC). That offloads making programs fast to compilers, which can do a better job of it if the instructions they're working with are very basic, and have a (reasonably) predictable duration and behavior. Itanium was the last serious attempt to disprove that thesis, and also failed rather spectacularly. The Mill is the latest contender, and well, I wish them luck. That may not be the final word though, people should keep trying the "language on a chip" approach, and some still are. I have a hunch that Erlang semantics might be a good target for hardware-specific acceleration, there should be some degrees of freedom available from knowing that data is only shared between processes via a strict ABI. And just because implementing garbage collectors in hardware didn't really pay off in the 1980s doesn't mean that it's physically impossible to have a win with that approach. I'm just sketching out why you don't see that kind of thing much these days. † C has been described as a "portable assembly language" and that has become steadily less true. That would be a stronger reading of my statement than I intended.
- twoodfin 2y ago
  If you told an alien visitor from Vega—or a computer architect with a time machine from 1980—that an Nvidia GPU was built to be a language on a chip, I wonder what they’d infer about the nature of that language? I don’t think they’d describe CUDA. Something more APL-like, I’d imagine. EDIT: Maybe … https://dl.acm.org/doi/pdf/10.1145/319838.319870 https://dl.acm.org/doi/pdf/10.1145/319838.319870

by aredox 2y ago

adrianmsmith 2y ago

I heard (but don't know any details) that Apple M series processors have special instructions which are useful for objc_msgsend and other functions called frequently by Objective-C.

alexisread 2y ago

Greenarrays comes to mind, it's a Forth-oriented chip: https://news.ycombinator.com/item?id=23142322 https://news.ycombinator.com/item?id=23142322 The article doesn't really mention transputers, which were existent at the time and were remarkably similar in vision, with parallel multiprocessing, hardware network links, the Occam language, a ground-up Helios OS, and custom graphics card (Blossom, which would lead to the VGA standard). Having a 3-element hardware stack somewhat restricts the use of languages on it - I imagine that Occam is similar to Forth in operation?

aredox 2y ago
Oh, thanks, I had forgotten about those crazy forthers (forthists? forthians?)!
- aeonik 2y ago
  Goth -> Gothic Therefore Forth -> Forthic
  - Y_Y 2y ago
    North -> Norsemen Forth -> Forsemen (The less gendered "Fordlander" is also acceptable)
- aeonik 2y ago
  Also, Forthsider, from the Firth of Forth?
ssrc 2y ago
Occam looks like a concurrent Pascal, not like a Forth. The transputer had a 3-element hardware stack but it was used more like a cache for the workspace (kind of the memory stack). You can still find around the manual "Transputer Instruction Set - a compiler writer's guide" that explains how you would do that (section 5.3 Expression Evaluation). Apart from Occam, there where C, C++ and Fortran compilers. Targeting the transputer is not more difficult than any other stack machine (like the JVM, the .Net CLR, CPython or Pascal p-code). The weird/interesting thing about the transputer is that it is also an operating system: two task queues (high/low priority), preemptive scheduling and communication through channels (that can be one of the 4 serial ports or memory based).

mepian 2y ago

Azul was actually selling servers with hardware-accelerated GC and other interesting features for Java: https://www.azul.com/newsroom/azul-systems-to-unveil-industrys-most-scalable-platform-for-business-java-applications/ https://www.azul.com/newsroom/azul-systems-to-unveil-industr...

dfox 2y ago
Then they found a way how to (ab)use amd64 MMU to do more or less the same thing that they had custom CPU architecture for (ie. GC barriers in hardware).
- rbanffy 2y ago
  A real shame. When they figured that out, their innovative hardware was doomed.

rjsw 2y ago

There is JOP [1] for Java. [1] https://www.jopdesign.com/ https://www.jopdesign.com/

llm_trw 2y ago

There are projects for this, but right now Moore's law is still shuffling along well enough that by the time you'd get to market general processors will still be better, remembering that you need on the order of $1b to design a modern CPU. Once it's truly dead pushing more features into silicon will the be only way we can get speedups and this will become a major research area again.

aredox 2y ago
We could argue the same about highly parallel computations, yet discrete GPU cards exist. I am also old enough to remember the same thing attempted for physics in games, PhysX, which had its own cards (PPU) built by ASUS and a couple others. There is also hardware acceleration for many audio and video codecs. "GC as a codec" doesn't strike me as something crazy: both are upgraded from time to time, but both are stable enough that hardware implementations are relevant over several years. Android phones would certainly benefit from it!
- cmrdporcupine 2y ago
  I think "do this matrix math and draw these polygons Really Really Fast" is specialized enough that GPUs are on the whole compelling as specialized hardware. That and this is a massive huge market which can benefit from economies of scale and Moore's law itself. Accelerating a particular language runtime is a different story. TBH people don't seem to have a problem generally with "throwing cycles away" and adopting languages like Python which have a pretty slow execution story. There's clearly not much of an economic advantage in optimization for processor throughput, otherwise more stuff would be getting [re]written in systems languages like C/C++/Rust/Zig etc, which would be a lot cheaper than developing custom hardware. And frankly most of the stuff that gets funding and people seem to get excited about in our industry right now... doesn't need much CPU. It's mostly just glue languages waiting on I/O. Apart from the ML/LLM hype right now, which relies heavily on... GPUs. I have a book here somewhere on the Linn Rekursiv hardware. Custom OO system in hardware in the 80s. Up there with Lisp machines as exotic and interesting "paths not taken".
  - 2y ago

rbanffy 2y ago

I remember someone mentioning an attempt to make all message passing in Smalltalk asynchronous running on separate threads, but I don't think anyone built a massively multithreaded CPU for that (besides, not that many messages are in flight at any given time, at least not on a desktop).

jdougan 2y ago
Could have meant RoarVM. https://github.com/smarr/RoarVM https://github.com/smarr/RoarVM

sillywalk 2y ago

They're not mainstream, but IBM's mainframes since Z14 have something called the Guarded Storage Facility which provides hardware assisted Java Garbage Collection[0], and Oracle's M8 has some hardware acceleration for Java "Streams"[1]. [0] https://www.ibm.com/support/pages/pause-less-garbage-collection-java-ibm-z https://www.ibm.com/support/pages/pause-less-garbage-collect... [1] https://www.oracle.com/a/ocom/docs/sparc-t8-m8-server-architecture.pdf https://www.oracle.com/a/ocom/docs/sparc-t8-m8-server-archit...

samatman 2y ago

This approach got a bad reputation by the late 1980s, thanks to some spectacular failures like the iAPX 432. The death of the Lisp Machine market wasn't spectacular in the same way, but they weren't a commercial success either, and contributed to the sentiment that tailoring the hardware for specific languages wasn't the way forward. You'll still find people making the case that we have continued to specialize computer hardware for a specific language, that language being C. They kind of have a point. I see it as more symbiotic than that: C caught on in large part because its abstract machine was a good fit for real hardware†, and that real hardware is the way it is because it's a Pareto-optimal way to do computation. Fact is that most languages don't have a semantics which could be accelerated much in hardware. Take Java for an example: it's possible to implement the JVM as a chip, but then you have a stack machine, and you can't JIT it onto a register architecture. What we do now is make the chip as fast as we can at doing the basic things a computer needs to do, and only that (this is the essence of RISC). That offloads making programs fast to compilers, which can do a better job of it if the instructions they're working with are very basic, and have a (reasonably) predictable duration and behavior. Itanium was the last serious attempt to disprove that thesis, and also failed rather spectacularly. The Mill is the latest contender, and well, I wish them luck. That may not be the final word though, people should keep trying the "language on a chip" approach, and some still are. I have a hunch that Erlang semantics might be a good target for hardware-specific acceleration, there should be some degrees of freedom available from knowing that data is only shared between processes via a strict ABI. And just because implementing garbage collectors in hardware didn't really pay off in the 1980s doesn't mean that it's physically impossible to have a win with that approach. I'm just sketching out why you don't see that kind of thing much these days. † C has been described as a "portable assembly language" and that has become steadily less true. That would be a stronger reading of my statement than I intended.

twoodfin 2y ago
If you told an alien visitor from Vega—or a computer architect with a time machine from 1980—that an Nvidia GPU was built to be a language on a chip, I wonder what they’d infer about the nature of that language? I don’t think they’d describe CUDA. Something more APL-like, I’d imagine. EDIT: Maybe … https://dl.acm.org/doi/pdf/10.1145/319838.319870 https://dl.acm.org/doi/pdf/10.1145/319838.319870