fixed size integer arithmetic

[Evan Lavelle]

I can't speak for the OP, but...

Richard B. Kreckel wrote:
> I suppose you guys are talking about modular arithmetic, right?

In principle, yes. In practice, though, a modular arithmetic library is 
probably not the best way to go (in my case, anyway).

> Did you try CLN <http://www.ginac.de/CLN/>? CLN is not C, though. It is 
> C++.
> 
> (I may mention that in CLN the modulus (called "invariant" above) is a 
> dynamic attribute of the class, not determined at compile time. IOW: 
> different moduli are not different C++ types and mismatches cause 
> runtime errors.)

I didn't find CLN; thanks for the link. My own app is modelling 
hardware, and the compiler constructs which let you do this. This is 
required in hardware description languages, such as VHDL and Verilog. A 
simple way to look at this is to think of an N-bit processor, with N-bit 
registers and an N-bit ALU, where N is arbitrary and is not necessarily 
a power of 2. You then need to handle all the low-level N-bit arithmetic 
and logical/bitwise operations that you'd expect to find in a processor. 
Or, alternatively, take the set of operators from a language such as C 
and re-implement them for arbitrary N, rather than the standard set of 
8, 16, 32, and 64.

CLN might have been a useful starting point, but it doesn't appear to 
have the bitwise operators, apart from << and >>, and >> seems to have a 
restriction on N. There's also the issue of operations on elements of 
different modular rings. There's nothing wrong, in principle, in adding 
a 9-bit integer to a 191-bit integer, to get a 191-bit result (or 
vice-versa), but CLN won't let you do this. It could be handled at a 
higher level, but you'd then need an op to resize integers, which I 
can't find. This leads on to a can of worms involving truncations and 
extensions, arithmetic conversions, and so on. The actual usage of these 
low-level ops turns out to be just as difficult as the low-level 
arithmetic itself.

Evan