I’ve been working on a specialised processor for Haskell called Ouros as part of my PhD study (see the HAFLANG project). Recently, I got it running on an FPGA, with a Haskell program communicating with the outside world through UART.
Ouros is a graph reduction processor with automatic fine-grained threading and garbage collection implemented in hardware. For this demo, I added a simple IO interface based on AXI4-Lite, so Haskell programs can perform IO directly without a software runtime or host OS.
There are still quite a few limitations as discussed in the blog post; currently it should still be seen as a toy. But I think having Haskell as a bare-metal programming language could be an interesting platform for further experiments.
The hardware implementation, compiler, simulator, and Vivado project are all open-source, with links and reproduction instructions in the blog post.
This looks really interesting, I’ll have to take a closer look at the details, but I was surprised not to see any references to the Reduceron or the Heron reimplementation. How does this compare to their architecture?
Thanks for asking.
You are definitely right that I should talk about Reduceron and Heron, especially when Heron is also developed in HAFLANG
We can ignore the difference in source language (Haskell vs. Flite; Ouros supports Haskell through piggybacking MicroHs). There are some subtle differences in graph reduction:
Reduceron & Heron use template instantiation, when applying a function, they tend to create the whole function body in one go; Ouros is combinator-based, this process is lazier, the function body tends to “gradually unroll” when it’s needed.
Reduceron & Heron put the program (templates) in a read-only memory, which prevents some useful updates and sharing from happening; Ouros puts “updatable” applications on the heap, and can thus achieve full laziness.
Architecture-wise, Ouros achives pipelining with potentially multiple threads, while Reduceron and Heron are sequential single-cycle machines.
