Nelson : The mp_int bignum package API is so
frozen as to have become something of a standard of its own. There
are now at least 3 different implementations known to me that are all
API compatible, differing only in the content of the (opaque) mp_int
structure itself.

Documentation :
http://plan9.escet.urjc.es/magic/man2html/2/mp
Routines that return an mpint will allocate the mpint if the result parameter is nil. This includes strtomp, itomp, uitomp, and btomp. These functions, in addition to mpnew and mpcopy, will return nil if the allocation fails.
http://eof-project.net/sources/WarGame/RansomWar/mpi.h
typedef unsigned short mp_digit;

WTC : need to undo some processor-version-specific type definitions.
An example is the mp_digit type for 64-bit Solaris SPARC. mp_digit
is defined differently for different versions of the SPARC v9a processors

Nelson : The mp_int struct itself should be opaque in a public definition.
So there should be no need to change the machine-dependent definitions
of the contents of that struct (including the array to which it points).
But I know that mp_digit is also used for types in the function
signatures, and that IS an issue…

I think this says that the task is feasible but requires more time to
think about all its implications.

D’après la doc : http://plan9.escet.urjc.es/magic/man2html/2/mp
The remaining routines all work on arrays of mpdigit rather than mpint’s. They are the basis of all the other routines. They are separated out to allow them to be rewritten in assembler for each architecture
Soit mpdigdiv et mpvec*