Reply To: Arbitrary precission integer arithmetic hardware help

Efficient representation of arbitrary precision math is a specific example of the more general problem of runtime typing, which is a problem we have long had on our backlog.

Of the various suggestions on this thread:
1) math ops do not trap, they fault: when they happen, you’re not coming back. Think C++ “throw”.
2) the “excepting” forms only fault on overflow, and while they could be used to catch a wide add for example, they then would not catch a subtract.
3) NaRs do not fault on speculable operations, they just pass through, and all the math ops are speculable.
4) We could indeed define a new “APinteger” domain. Currently the domains are signed and unsigned integer, signed and unsigned fixed point, logical, boolean, binary and decimal float, and some pseudos for various unique ops. The new domain would add the set of ops to the ISA, which would have entropy consequences in the encoding. However, implementing the behavior via traps is real problematic on a Mill because of the wide issue – a single instruction could have a ton of distinct traps. We currently do not have any result-replacing traps defined; all the traps are for things like page faults which are fundamentally asynchronous to the core and belt. Trap-based programming could be done, but it would thoroughly muck up the execution engine, and we haven’t and probably won’t put such a thing in.
5) AP integer is a special case; the Mill tends to do the general case of things. The general case is an efficient runtime-typing mechanism that is type-system agnostic.

We have done some thinking about how to do runtime-typing in the Mill environment, but don’t have anything yet ready for publication, or even for patent filing. I wish I could be more informative; sorry.