I was following development process of your library and was just waiting this moment. I'll test your fixed_int code and compare it to my own implementation. FYI gmp library performance was 4 times slower comparing to my fixed_int implementation.
I was also wondering if it's possible to provide generalized interface for the Boost licensed big_number and specifying underlying data storage using template parameter (boost::array for fixed integers or vector for not fixed integers). Most of the operations implementations (addition, multiplication and all the others) should remain the same. You may want to have a look at this code: http://svn.boost.org/svn/boost/sandbox/SOC/2007/bigint/boost/bigint/bigint_s... http://svn.boost.org/svn/boost/sandbox/SOC/2007/bigint/boost/bigint/bigint_s... http://svn.boost.org/svn/boost/sandbox/SOC/2007/bigint/boost/bigint/bigint_d... I would suggest that this way you should get not fixed int implementation performing almost the same as fixed_int, and as a plus you would not need tommath_int anymore.
It's an interesting idea - but at present I'm thinking that fixed_int is specialized enough to warrant it's own implementation - it's 2's complement where as almost all (all?) arbitrary precision types are signed-magnitude, there are also some operations that can be significantly streamlined for fixed precision 2's complement modulo arithmetic types (for example long multiplication doesn't need to calculate all the places in the result) which is the reason many operations can outperform GMP *even excluding memory allocations*. There's also the interesting effect, that since the array bounds are known at compile time, the compiler can unroll and / or vectorize the loops - and it can probably do that almost as well as hand written assembly. That said, since all the algorithms are non-member functions anyway, there may well end up being some possibility of code sharing further down the road... Cheers, John.