Because of historic compatibility reasons, I sort of ended up rewriting a subset of #Microblaze-compatible core for synthesising on tight corners inside Lattice's ICE40/ECP5 #FPGA:s.

It's in #Verilog with some #LiterateProgramming preprocessing. Userspace (and I/O+interrupt support) only. Explicit support for combining code and data bus, optionally for 8-bit memory access (as in HyperRAM), or for synthesising instruction memory as block RAM, optionally with a secondary debug interface. Explicit support for resetting the core without resetting the whole FPGA. AXI-like, Wishbone-compliant, and serial I/O support, and I/O-mappable interrupt support. The register file can be pared down. Arithmetics can be divided up into chunks of a parametrically specified size, all the way down to bit-serial if need be, and slow-but-smol microcoded multiplication and division are optionally available. Some optional extensions for fixed-point transcendental calculations were originally planned, but right now, only binary logarithms and CORDIC are ready.

The original commercial interest in it is likely to go away in the near future. Would there be interest in a GPL release of this sort of thing?

This is not at all the sort of context that MicroBlaze was originally designed for, even in the Xilinx world, and I'm not sure that the specific backwards compatibility reasons exist outside this particular niche (=> I would probably not be doing maintenance work on the core after release without a good $€parate r€a$on), but if you have a use case that might match something like these criteria, please let me know.

(Obligatory LBNL: only deterministic automation was used in writing this code. GenAI has not touched any part of it.)

I have uploaded a new paper to the arXiv, “Counting number-conserving cellular automata with radius 1“ (https://arxiv.org/abs/2605.31157).

The text is both a semi-brute-force calculation of the number of one-dimensional cellular automata with radius 1 and up to seven states, and an exercise in literate programming.

I call this a “semi-brute-force” calculation because, while it relies on my theory of one-dimensional number-conserving automata to speed up the calculation, there still remains an enormous number of individual cases that need to be computed and added up. It is by no means fast. The algorithm is also very specialised and works only for radius 1.

And literate programming means that the source code is a mixture of LaTeX and Haskell code, so that it (a) can be directly compiled by the Haskell compiler and (b) in the generated PDF, I can see each source code fragment together with the mathematical explanation what it does and why it does it. I did this in order to be (almost) absolutely sure that the program does what it was intended to do. The literate programming method works, but it is still quite an effort.

I do not think there is a journal that publishes such a text, but at least it is now in the arXiv.

#CellularAutomata #NumberConservation #LiterateProgramming #EnumerativeCombinatorics #Mathematics

Knitr support in Overleaf
#literateprogramming

https://docs.overleaf.com/integrations-and-add-ons/r-code-knitr

I recently got back to my work on literate #GRASP, and I think things finally started to look good. I implemented a new document representation (the previous one was built from cons-cells and multiple hacks), and I have some working tests that are capable of rendering this representation to "unicode-art" strings, and I'm currently working on a new parser that would work well with that representation.

I still have a long way to go before I get a running system, and I don't think it's a very good literature, but if you're a #Scheme maniac or a fan of #LiterateProgramming and you don't find the #Java runtime environment too repulsive, I invite you to follow the work and provide your feedback:

https://github.com/panicz/grasp/blob/main/literate/grasp.org

Currently, when exported to pdf, the document has about 100 pages, and it mainly describes language extensions that were developed for Kawa Scheme to develop GRASP. I think it might be a delight to people who enjoy studying language extensions, but unfortunately the part about the architecture and implementation of GRASP has yet to be developed.

(the document is written in #Emacs #OrgMode using its #noweb component for literate programming. I recommend reading it from Emacs rather than from its github preview)

Been working towards getting stitching working in #ReTangled. It's complicated because codeblocks can be embedded in other codeblocks so the stitcher has to keep track of a lot of information about the source document to make sense of where everything goes.

#LiterateProgramming