It doesn't look especially specific to me - slightly hack the structure in https://github.com/libtom/libtommath to make sense to your garbage collector and you're pretty much done. That somewhat punts on the testing question but I doubt add/mul/bitops from that library are buggy.
I'd be interested in a review / survey of different options, and the strategy for testing. Basically the tests should "argue" that the code is correct, and documentation / blog posts also count!
(I'm honestly not sure how hard it is to make a correct big num library. But I think the original article in this series said there were probably bugs, so I'm guessing it's not trivial)
To give a flavor, we publish test results and and coverage numbers like this [1], and any new library should be consistent with this:
Our GC runtime has less than 5000 lines of hand-written C++ now, so any solution should be in proportion to that. That is, we probably wouldn't take on 3000 lines of code just for big nums.
So we favor correctness over performance. Hopefully there would be little perf loss in the small int case, but it's OK if the big int case is slow. It's the rarer case for sure.
It's a shell, not a Fortran competitor!
---
As far as the grant, we pay in 2500 euro or 5000 euro increments, and I don't try to parse "effort spent" any more than that. I care about the result, not if it's easy for a particular person :)
For example earlier this year we had a contributor Justin who worked on the pretty printer, with Wadler's algorithm (which I was unfamiliar with).
[1] our unit test coverage is reported at 83% or so, but we favor "exterior" tests, so it's really close to 95% or 99%. Also of course line coverage isn't really a way to measure correctness per se.
I believe it's used by a bunch of places that don't really bother with attribution, what with it being marked public domain. It's notable for being extremely well documented and for the (initial at least) emphasis on simplicity.
It's probably overkill for your domain though and complexity does tend to bring bugs. A reasonable approach would probably be to implement the simple array-of-wordsize/2 strategy and regression test against that lib. Or actually the GNU one is reasonable for testing purposes, though beware that GNU's one kills the process on out of memory.
I need to write a bigint implementation for a lisp/ml compiler anyway and am probably up for making that compatible with your GC layout. Oils built and ran locally a moment ago. I'm more likely to write that for free than for money though, will send you an email anyway.
