These are itemized GMP development tasks. Not all the tasks listed here are suitable for volunteers, but many of them are. Please see the projects file for more sizeable projects.
mp_size_t data in several int
     variables.  (It is also really slow.  Perhaps just call
     mpn_divrem_1.  See also optimization item below.)
_mpz_realloc with a small (1 limb) size.
mpz_XXX(a,a,a).
mpf_t numbers with exponents >2^53 on
     machines with 64-bit mp_exp_t, the precision of
     __mp_bases[base].chars_per_bit_exactly is insufficient and
     mpf_get_str aborts.  Detect and compensate.  Alternately,
     think seriously about using some sort of fixed-point integer value.
     Avoiding unnecessary floating point is probably a good thing in general,
     and it might be faster on some CPUs.
mpf_eq is not always correct, when one operand is
     1000000000... and the other operand is 0111111111..., i.e., extremely
     close.  There is a special case in mpf_sub for this
     situation; put similar code in mpf_eq.
mpf_eq doesn't implement what gmp.texi specifies.  It should
     not use just whole limbs, but partial limbs.
_mpz_realloc will reallocate to less than the current size
     of an mpz.  This is ok internally when a destination size is yet to be
     updated, but from user code it should probably refuse to go below the
     size of the current value.  Could switch internal uses across to a new
     function, and tighten up _mpz_realloc.
mpf_set_str doesn't validate it's exponent, for instance
     garbage 123.456eX789X is accepted (and an exponent 0 used), and overflow
     of a long is not detected.
mpf_add doesn't check for a carry from truncated portions of
     the inputs, and in that respect doesn't implement the "infinite precision
     followed by truncate" specified in the manual.
mpf_div of x/x doesn't always give 1, reported by Peter
     Moulder.  Perhaps it suffices to put +1 on the effective divisor prec, so
     that data bits rather than zeros are shifted in when normalizing.  Would
     prefer to switch to mpn_tdiv_qr, where all shifting should
     disappear.
mpz_add etc, which doesn't work
     when those routines are coming from a DLL (because they're effectively
     function pointer global variables themselves).  Need to rearrange perhaps
     to a set of calls to a test function rather than iterating over an array.
mpn_gcdext, mpz_get_d,
     mpf_get_str: Don't test count_leading_zeros for
     zero, instead check the high bit of the operand and avoid invoking
     count_leading_zeros.  This is an optimization on all
     machines, and significant on machines with slow
     count_leading_zeros, though it's possible an already
     normalized operand might not be encountered very often.
umul_ppmm to use floating-point for generating the
     most significant limb (if BITS_PER_MP_LIMB <= 52 bits).
     (Peter Montgomery has some ideas on this subject.)
umul_ppmm code in longlong.h: Add partial
     products with fewer operations.
mpn_get_str and mpn_set_str running in
     the sub O(n^2) range, using some divide-and-conquer approach, preferably
     without using division.
mpn_get_str should use a native mpn_divrem_1
     when available (athlon, p6mmx).  A new mpn_preinv_divrem_1
     entrypoint would suit, since the inverse and shift are known from
     mp_bases.  Don't do an mpn_lshift in
     mpn_get_str, leave it up to mpn_divrem_1 to
     either make that call or do it on-the-fly.
mpn_get_str to mpf/get_str.  (Talk to Torbjörn about this.)
mpz_set_ui.  This would be both small and
     fast, especially for compile-time constants, but would make application
     binaries depend on having 1 limb allocated to an mpz_t,
     preventing the "lazy" allocation scheme below.
mpz_[cft]div_ui and maybe
     mpz_[cft]div_r_ui.  A __gmp_divide_by_zero
     would be needed for the divide by zero test, unless that could be left to
     mpn_mod_1 (not sure currently whether all the risc chips
     provoke the right exception there if using mul-by-inverse).
mpz_fits_s*_p.  The setups for
     LONG_MAX etc would need to go into gmp.h, and on Cray it
     might, unfortunately, be necessary to forcibly include <limits.h>
     since there's no apparent way to get SHRT_MAX with an
     expression (since short and unsigned short can
     be different sizes).
mpz_powm and mpz_powm_ui aren't very
     fast on one or two limb moduli, due to a lot of function call
     overheads.  These could perhaps be handled as special cases.
mpz_powm and mpz_powm_ui want better
     algorithm selection, and the latter should use REDC.  Both could
     change to use an mpn_powm and mpn_redc.
mpz_powm REDC should do multiplications by g[]
     using the division method when they're small, since the REDC form of a
     small multiplier is normally a full size product.  Probably would need a
     new tuned parameter to say what size multiplier is "small", as a function
     of the size of the modulus.
mpz_powm REDC should handle even moduli if possible.  Maybe
     this would mean for m=n*2^k doing mod n using REDC and an auxiliary
     calculation mod 2^k, then putting them together at the end.
mpn_gcd might be able to be sped up on small to
     moderate sizes by improving find_a, possibly just by
     providing an alternate implementation for CPUs with slowish
     count_leading_zeros.
USE_MORE_MPN could use a low to high cache localized
     evaluate and interpolate.  The necessary mpn_divexact_by3c
     exists.
mpn_mul_basecase on NxM with big N but small M could try for
     better cache locality by taking N piece by piece.  The current code could
     be left available for CPUs without caching.  Depending how karatsuba etc
     is applied to unequal size operands it might be possible to assume M is
     always smallish.
mpn_perfect_square_p on small operands might be better off
     skipping the residue tests and just taking a square root.
mpz_perfect_power_p could be improved in a number of ways.
     Test for Nth power residues modulo small primes like
     mpn_perfect_square_p does.  Use p-adic arithmetic to find
     possible roots.  Divisibility by other primes should be tested by
     grouping into a limb like PP.
mpz_perfect_power_p might like to use mpn_gcd_1
     instead of a private GCD routine.  The use it's put to isn't
     time-critical, and it might help be ensure correctness to use the main GCD
     routine.
mpz_perfect_power_p could use
     mpz_divisible_ui_p instead of mpz_tdiv_ui for
     divisibility testing, the former is faster on a number of systems.  (But
     all that prime test stuff is going to be rewritten some time.)
PP/PP_INVERTED into an array of such
     pairs, listing several hundred primes.  Perhaps actually make the
     products larger than one limb each.
PP can have factors of 2 introduced in order to get the high
     bit set and therefore a PP_INVERTED existing.  The factors
     of 2 don't affect the way the remainder r = a % ((x*y*z)*2^n) is used,
     further remainders r%x, r%y, etc, are the same since x, y, etc are odd.
     The advantage of this is that mpn_preinv_mod_1 can then be
     used if it's faster than plain mpn_mod_1.  This would be a
     change only for 16-bit limbs, all the rest already have PP
     in the right form.
PP could have extra factors of 3 or 5 or whatever introduced
     if they fit, and final remainders mod 9 or 25 or whatever used, thereby
     making more efficient use of the mpn_mod_1 done.  On a
     16-bit limb it looks like PP could take an extra factor of
     3.
mpz_probab_prime_p, mpn_perfect_square_p and
     mpz_perfect_power_p could take a remainder mod 2^24-1 to
     quickly get remainders mod 3, 5, 7, 13 and 17 (factors of 2^24-1).  A
     remainder mod 2^24-1 can be taken at adder throughput speed.  This could
     either replace the PP division currently done, or allow
     PP to do larger primes, depending how many residue tests
     seem worthwhile before launching into full root extractions or
     Miller-Rabin etc.
mpz_probab_prime_p (and maybe others) could code the
     divisibility tests like n%7 == 0 in the form
#define MP_LIMB_DIVISIBLE_7_P(n) \ ((n) * MODLIMB_INVERSE_7 <= MP_LIMB_T_MAX/7)This would help compilers which don't know how to optimize divisions by constants, and would help current gcc (3.0) too since gcc forms a whole remainder rather than using a modular inverse and comparing. This technique works for any odd modulus, and with some tweaks for even moduli too. See Granlund and Montgomery "Division By Invariant Integers" section 9.
mpz_probab_prime_p and mpz_nextprime could
     offer certainty for primes up to 2^32 by using a one limb miller-rabin
     test to base 2, combined with a table of actual strong pseudoprimes in
     that range (2314 of them).  If that table is too big then both base 2 and
     base 3 tests could be done, leaving a table of 104.  The test could use
     REDC and therefore be a modlimb_invert a remainder (maybe)
     then two multiplies per bit (successively dependent).  Processors with
     pipelined multipliers could do base 2 and 3 in parallel.  Vector systems
     could do a whole bunch of bases in parallel, and perhaps offer near
     certainty up to 64-bits (certainty might depend on an exhaustive search
     of pseudoprimes up to that limit).  Obviously 2^32 is not a big number,
     but an efficient and certain calculation is attractive.  It might find
     other uses internally, and could even be offered as a one limb prime test
     mpn_probab_prime_1_p or gmp_probab_prime_ui_p
     perhaps.
mpz_probab_prime_p doesn't need to make a copy of
     n when the input is negative, it can setup an
     mpz_t alias, same data pointer but a positive size.  With no
     need to clear before returning, the recursive function call could be
     dispensed with too.
mpf_set_str produces low zero limbs when a string has a
     fraction but is exactly representable, eg. 0.5 in decimal.  These could be
     stripped to save work in later operations.
mpz_and, mpz_ior and mpz_xor should
     use mpn_and_n etc for the benefit of the small number of
     targets with native versions of those routines.  Need to be careful not to
     pass size==0.  Is some code sharing possible between the mpz
     routines?
mpf_add: Don't do a copy to avoid overlapping operands
     unless it's really necessary (currently only sizes are tested, not
     whether r really is u or v).
mpf_add: Under the check for v having no effect on the
     result, perhaps test for r==u and do nothing in that case, rather than
     currently it looks like an MPN_COPY_INCR will be done to
     reduce prec+1 limbs to prec.
mpn_divrem_2 could usefully accept unnormalized divisors and
     shift the dividend on-the-fly, since this should cost nothing on
     superscalar processors and avoid the need for temporary copying in
     mpn_tdiv_qr.
mpf_sqrt_ui calculates prec+1 limbs, whereas just prec would
     satisfy the application requested precision.  It should suffice to simply
     reduce the rsize temporary to 2*prec-1 limbs.  mpf_sqrt
     might be similar.
invert_limb generic C: The division could use dividend
     b*(b-d)-1 which is high:low of (b-1-d):(b-1), instead of the current
     (b-d):0, where b=2^BITS_PER_MP_LIMB and d=divisor.  The
     former is per the original paper and is used in the x86 code, the
     advantage is that the current special case for 0x80..00 could be dropped.
     The two should be equivalent, but a little check of that would be wanted.
mpq_cmp_ui could form the num1*den2 and
     num2*den1 products limb-by-limb from high to low and look at
     each step for values differing by more than the possible carry bit from
     the uncalculated portion.
mpq_cmp could do the same high-to-low progressive multiply
     and compare.  The benefits of karatsuba and higher multiplication
     algorithms are lost, but if it's assumed only a few high limbs will be
     needed to determine an order then that's fine.
mpn_add_1, mpn_sub_1, mpn_add,
     mpn_sub: Internally use __GMPN_ADD_1 etc
     instead of the functions, so they get inlined on all compilers, not just
     gcc and others with inline recognised in gmp.h.
     __GMPN_ADD_1 etc are meant mostly to support application
     inline mpn_add_1 etc and if they don't come out good for
     internal uses then special forms can be introduced, for instance many
     internal uses are in-place.  Sometimes a block of code is executed based
     on the carry-out, rather than using it arithmetically, and those places
     might want to do their own loops entirely.
__gmp_extract_double on 64-bit systems could use just one
     bitfield for the mantissa extraction, not two, when endianness permits.
     Might depend on the compiler allowing long long bit fields
     when that's the only actual 64-bit type.
mpf_get_d could be more like mpz_get_d and do
     more in integers and give the float conversion as such a chance to round
     in its preferred direction.  Some code sharing ought to be possible.  Or
     if nothing else then for consistency the two ought to give identical
     results on integer operands (not clear if this is so right now).
usqr_ppm or some such could do a widening square in the
     style of umul_ppmm.  This would help 68000, and be a small
     improvement for the generic C (which is used on UltraSPARC/64 for
     instance).  GCC recognises the generic C ul*vh and vl*uh are identical,
     but does two separate additions to the rest of the result.
TMP_FREE releases all memory, so
     there's an allocate and free every time a top-level function using
     TMP is called.  Would need
     mp_set_memory_functions to tell tal-notreent.c to release
     any cached memory when changing allocation functions though.
__gmp_tmp_alloc from tal-notreent.c could be partially
     inlined.  If the current chunk has enough room then a couple of pointers
     can be updated.  Only if more space is required then a call to some sort
     of __gmp_tmp_increase would be needed.  The requirement that
     TMP_ALLOC is an expression might make the implementation a
     bit ugly and/or a bit sub-optimal.
#define TMP_ALLOC(n)
  ((ROUND_UP(n) > current->end - current->point ?
     __gmp_tmp_increase (ROUND_UP (n)) : 0),
     current->point += ROUND_UP (n),
     current->point - ROUND_UP (n))
#ifdef (__GNUC__) #if __GNUC__ == 2 && __GNUC_MINOR__ == 7 ... #endif #if __GNUC__ == 2 && __GNUC_MINOR__ == 8 ... #endif #ifndef KARATSUBA_MUL_THRESHOLD /* Default GNUC values */ ... #endif #else /* system compiler */ ... #endif
invert_limb on various processors might benefit from the
     little Newton iteration done for alpha and ia64.
mpn_addmul_1 and
     mpn_submul_1.  Integrate new mpn_mul_1 code.
mpn_addmul_1, mpn_submul_1,
     and mpn_mul_1 for the 21164.  This should use both integer
     multiplies and floating-point multiplies.  For the floating-point
     operations, the single-limb multiplier should be split into three 21-bit
     chunks, or perhaps even better in four 16-bit chunks.  Probably possible
     to reach 9 cycles/limb.
ctlz and cttz for
     count_leading_zeros andcount_trailing_zeros.
     Use inline for gcc, probably want asm files for elsewhere.
mpn_divexact_by3 isn't particularly important, but
     the generic C runs at about 27 c/l, whereas with the multiplies off the
     dependent chain about 3 c/l ought to be possible.
mpn_hamdist could be put together based on the
     current mpn_popcount.
popc_limb in gmp-impl.h could use the
     popcnt insn.
mpn_mul_1, mpn_addmul_1,
     and mpn_submul_1.  Should use floating-point operations, and
     split the invariant single-limb multiplier into 16-bit chunks.  Will give
     14 cycles/limb, but with a deep pipeline.
umul_ppmm.  Using four
     "mulx"s either with an asm block or via the generic C code is
     about 90 cycles.  Try using fp operations, and also try using karatsuba
     for just three "mulx"s.
mpn_sqr_diagonal.  Since we're
     squaring each limb, it seems best to split limbs into one 22-bit chunk
     (for most significant part) and two 21 bit chunks.  Things magically
     align to 64-bits borders with that splitting.  Will need 19 memory
     operations, and won't therefore run faster than at about 20 cycles/limb.
     (The current umul_ppmm loop of mpn_sqr_basecase runs at around 60
     cycles/limb.)  If we use VIS fand for splitting operands,
     just 13 memory are needed.
mpn_divrem_1, mpn_mod_1,
     mpn_divexact_1 and mpn_modexact_1_odd could
     process 32 bits at a time when the divisor fits 32-bits.  This will need
     only 4 mulx's per limb instead of 8 in the general case.
mpn_lshift, mpn_rshift.
     Will give 2 cycles/limb.  Trivial modifications of mpn/sparc64 should do.
mulx for umul_ppmm if
     possible (see commented out code in longlong.h).
__sparc_v9__
     or anything to indicate V9 support when -mcpu=v9 is selected.  See
     gcc/config/sol2-sld-64.h.  Will need to pass something through from
     ./configure to select the right code in longlong.h.  (Currently nothing
     is lost because mulx for multiplying is commented out.)
modlimb_invert might save a few cycles from
     masking down to just the useful bits at each point in the calculation,
     since mulx speed depends on the highest bit set.  Either
     explicit masks or small types like short and
     int ought to work.
mpn_popcount and mpn_hamdist
     could use popc currently commented out in gmp-impl.h.  This
     chip reputedly implements popc properly (see gcc sparc.md),
     would need to recognise the chip as sparchalr1 or something
     in configure / config.sub / config.guess.
mpn_addmul_1, mpn_submul_1, and
     mpn_mul_1.  The current code runs at 11 cycles/limb.  It
     should be possible to saturate the cache, which will happen at 8
     cycles/limb (7.5 for mpn_mul_1).  Write special loops for s2 < 2^32;
     it should be possible to make them run at about 5 cycles/limb.
mpn_addmul_1, mpn_submul_1, and
     mpn_mul_1.  Use both integer and floating-point operations,
     possibly two floating-point and one integer limb per loop.  Split operands
     into four 16-bit chunks for fast fp operations.  Should easily reach 9
     cycles/limb (using one int + one fp), but perhaps even 7 cycles/limb
     (using one int + two fp).
mpn_rshift could do the same sort of unrolled loop
     as mpn_lshift.  Some judicious use of m4 might let the two
     share source code, or with a register to control the loop direction
     perhaps even share object code.
mpn_mul_basecase and mpn_sqr_basecase
     for important machines.  Helping the generic sqr_basecase.c with an
     mpn_sqr_diagonal might be enough for some of the RISCs.
mpn_lshift/mpn_rshift.
     Will bring time from 1.75 to 1.25 cycles/limb.
mpn_lshift for shifts by 1.  (See
     Pentium code.)
rep
     movs would upset GCC register allocation for the whole function.
     Is this still true in GCC 3?  It uses rep movs itself for
     __builtin_memcpy.  Examine the code for some simple and
     complex functions to find out.  Inlining rep movs would be
     desirable, it'd be both smaller and faster.
mpn_lshift and mpn_rshift can come
     down from 6.0 c/l to 5.5 or 5.375 by paying attention to pairing after
     shrdl and shldl, see mpn/x86/pentium/README.
mpn_divexact_1 and
     mpn_modexact_1_odd on 16-bit divisors could use MMX
     multiplies and run at around 16 cycles (down from 23).
mpn_lshift and mpn_rshift
     might benefit from some destination prefetching.
mpn_divrem_1 might be able to use a
     mul-by-inverse, hoping for maybe 30 c/l.
mpn_add_n and mpn_sub_n should be able to go
     faster than the generic x86 code at 3.5 c/l.  The athlon code for instance
     runs at about 2.7.
mpn_lshift and mpn_rshift might be able to
     do something branch-free for unaligned startups, and shaving one insn
     from the loop with alternative indexing might save a cycle.
mpn_lshift.
     The pipeline is now extremely deep, perhaps unnecessarily deep.
mpn_rshift based on new mpn_lshift.
mpn_add_n and mpn_sub_n.  Should
     run at just 3.25 cycles/limb.
mpn_mul_basecase and
     mpn_sqr_basecase.  This should use a "vertical multiplication
     method", to avoid carry propagation.  splitting one of the operands in
     11-bit chunks.
mpn_lshift by 31 should use the special rshift
     by 1 code, and vice versa mpn_rshift by 31 should use the
     special lshift by 1.  This would be best as a jump across to the other
     routine, could let both live in lshift.asm and omit rshift.asm on finding
     mpn_rshift already provided.
mpn_com_n and mpn_and_n etc very probably
     wants a pragma like MPN_COPY_INCR.
mpn_lshift, mpn_rshift,
     mpn_popcount and mpn_hamdist are nice and small
     and could be inlined to avoid function calls.
TMP_ALLOC to use them, or introduce a new scheme.  Memory
     blocks wanted unconditionally are easy enough, those wanted only
     sometimes are a problem.  Perhaps a special size calculation to ask for a
     dummy length 1 when unwanted, or perhaps an inlined subroutine
     duplicating code under each conditional.  Don't really want to turn
     everything into a dog's dinner just because Cray don't offer an
     alloca.
mpn_mul_1 could check for a 16-bit multiplier and use
     two multiplies per limb, not four.  Ditto mpn_addmul_1 and
     mpn_submul_1.
mpn_lshift and mpn_rshift could use a
     roll and mask instead of lsrl and
     lsll.  This promises to be a speedup, effectively trading a
     6+2*n shift for one or two 4 cycle masks.  Suggested by Jean-Charles
     Meyrignac.
count_leading_zeros for 64-bit machines:
  
	   if ((x >> 32) == 0) { x <<= 32; cnt += 32; }
	   if ((x >> 48) == 0) { x <<= 16; cnt += 16; }
	   ... 
__inline which could perhaps
     be used in __GMP_EXTERN_INLINE.  What would be the right way
     to identify suitable versions of that compiler?
double floats are straightforward and
     could perhaps be handled directly in __gmp_extract_double
     and maybe in mpz_get_d, rather than falling back on the
     generic code.  GCC defines __GFLOAT when -mg has selected G
     format (which would be possible via a user CFLAGS).
mp?_out_raw and
     mp?_inp_raw.
mpz_get_nth_ui.  Return the nth word (not necessarily the
     nth limb).
mpz_crr (Chinese Remainder Reconstruction).
mpz_init and mpq_init could do lazy allocation.
     Set ALLOC(var) to 0 to indicate nothing allocated, and let
     _mpz_realloc do the initial alloc.  Set
     z->_mp_d to a dummy that mpz_get_ui and
     similar can unconditionally fetch from.  Niels Möller has had a go at
     this.
     mpz_init and then
          more or less immediately reallocating.
     mpz_init would only store magic values in the
          mpz_t fields, and could be inlined.
     mpz_t z = MPZ_INITIALIZER;, which might be convenient
          for globals.
     mpz_set_ui and other similar routines needn't check the
          size allocated and can just store unconditionally.
     mpz_set_ui and perhaps others like
          mpz_tdiv_r_ui and a prospective
          mpz_set_ull could be inlined.
     mpf_out_raw and mpf_inp_raw.  Make sure
     format is portable between 32-bit and 64-bit machines, and between
     little-endian and big-endian machines.
gmp_errno.  It should be possible to detect errors at the
     start of documented entrypoints and invoke an exception handler with a
     nice clean state, giving it the chance to recover with
     longjmp or a C++ throw or whatever.
longjmp or throw a C++
     exception on being out of memory (or out of the memory they care to offer
     GMP).  This would need GMP to ensure all variables are in a sensible
     state whenever attempting an alloc or realloc, and would need some way to
     record other temporary memory or temporary variables in use which should
     be freed.  The latter might be difficult, perhaps the C++ destructor
     mechanism would be necessary.
mpn_and_n ... mpn_copyd: Perhaps make the mpn
     logops and copys available in gmp.h, either as library functions or
     inlines, with the availability of library functions instantiated in the
     generated gmp.h at build time.
mpz_set_str etc variants taking string lengths rather than
     null-terminators.
<=" rather than "<", so a threshold can
     be set to MP_SIZE_T_MAX to get only the simpler code (the
     compiler will know size <= MP_SIZE_T_MAX is always true).
     Alternately it looks like the ABOVE_THRESHOLD and
     BELOW_THRESHOLD macros can do this adequately, and also pick
     up cases where a threshold of zero should mean only the second algorithm.
mpz_nthprime.
mpz_init2, initializing and making initial room for
     N bits.  The actual size would be rounded up to a limb, and perhaps an
     extra limb added since so many mpz routines need that on
     their destination.
mpz_andn, mpz_iorn, mpz_nand,
     mpz_nior, mpz_xnor might be useful additions,
     if they could share code with the current such functions (which should be
     possible).
mpf_set_str and mpf_inp_str could usefully
     accept 0x, 0b etc when base==0.  Perhaps the exponent could default to
     decimal in this case, with a further 0x, 0b etc allowed there.
     Eg. 0xFFAA@0x5A.  A leading "0" for octal would match the integers, but
     probably something like "0.123" ought not mean octal.
GMP_LONG_LONG_LIMB or some such could become a documented
     feature of gmp.h, so applications could know whether to
     printf a limb using %lu or %Lu.
PRIdMP_LIMB and similar defines following C99
     <inttypes.h> might be of use to applications printing limbs.
     Perhaps they should be defined only if specifically requested, the way
     <inttypes.h> does.
mpf_get_ld and mpf_set_ld converting
     mpf_t to and from long double.  Other
     long double routines would be desirable too, but these would
     be a start.  Often long double is the same as
     double, which is easy but pretty pointless.  Should
     recognise the Intel 80-bit format on i386, and IEEE 128-bit quad on
     sparc, hppa and power.  Might like an ABI sub-option or something when
     it's a compiler option for 64-bit or 128-bit long double.
#ifdef mess in gmp-impl.h.  This is simple when doing a
     native compile, but needs a reliable way to examine object files when
     cross-compiling.  Falling back on a run-time test would be reasonable, if
     build time tests fail.
GMP_ASM_LSYM_PREFIX.  We end up falling back on
     L which is probably right, but it might be desirable to
     recognise the format, or try to jam it into BSD mode or whatever.
umul_ppmm in longlong.h always uses umull,
     but is that available only for M series chips or some such?  Perhaps it
     should be configured in some way.
.byte used in
     GMP_ASM_LSYM_PREFIX because it's data being emitted in the
     text section.  It also complains about lacking
     .ent/.end directives.  The fallback
     L is probably right, but perhaps the test should be
     improved.
_system_configuration.implementation for more accurate CPU
     determination.
umul but not udiv, or something like
     that.  Check the mpn/sparc32/v8 code is suitable, and add -mcpu= options
     for gcc.
udiv should be selected
     according to the CPU target.  Currently floating point ends up being
     used on all sparcs, which is probably not right for generic V7 and V8.
AC_SUBSTs setup from configure.  That would junk up the
     Makefiles a bit, but using an extra AM_CONFIG_HEADER type
     file didn't work very well last time it was tried.
umul and udiv code not being
     used.  Check all such for bit rot and then put umul and udiv in
     $gmp_mpn_functions_optional as "standard optional" objects.
     mpn_umul_ppmm and mpn_udiv_qrnnd have a
     different parameter order than those functions on other CPUs.  It might
     avoid confusion to have them under different names, maybe
     mpn_umul_ppmm_r or some such.  Prototypes then wouldn't
     be conditionalized, and the appropriate form could be selected with the
     HAVE_NATIVE scheme if/when the code switches to use a
     PROLOGUE style.
DItype: The setup in gmp-impl.h for non-GCC could use an
     autoconf test to determine whether long long is available.
AC_OUTPUT
     would work, but it might upset "make" to have things like L$
     get into the Makefiles through AC_SUBST.
     AC_CONFIG_COMMANDS would be the alternative.  With some
     careful m4 quoting the changequote calls might not be
     needed, which might free up the order in which things had to be output.
_gmp_rand is not particularly fast on the linear
     congruential algorithm and could stand various improvements.
     gmp_randstate_t (or
          _mp_algdata rather) to save some copying.
     2exp modulus, to
          avoid mpn_mul calls.  Perhaps the same for two limbs.
     lc code, to avoid a function call and
          TMP_ALLOC for every chunk.
     seedn==0 will be very rarely used,
          and on that basis seems unnecessary.
     2exp and general LC cases should be split,
          for clarity (if the general case is retained).
     gmp_randinit_mm (named after Mitchell and Moore) for the
     55-element delayed Fibonacci generator from Knuth vol 2.  Being additive
     it should be fast, and might be random enough for GMP test program
     purposes, if nothing else.  Niels Möller has started on this.
gmp_randinit_lc: Finish or remove.  Doing a division for
     every every step won't be very fast, so check whether the usefulness of
     this algorithm can be justified.
gmp_randinit_bbs would be wanted, not the currently
     commented out case in gmp_randinit.
_gmp_rand could be done as a function pointer within
     gmp_randstate_t (or rather in the _mp_algdata
     part), instead of switching on a gmp_randalg_t.  Likewise
     gmp_randclear, and perhaps gmp_randseed if it
     became algorithm-specific.  This would be more modular, and would ensure
     only code for the desired algorithms is dragged into the link.
mpz_urandomm should do something for n<=0 (but what?),
     and the use of mpz_mod looks doubtful (does it suffice to
     generate numbers of nbits until getting one <n?)
gmp_randstate_t used for parameters perhaps should become
     gmp_randstate_ptr the same as other types.
mpz_div and mpz_divmod use rounding
     analogous to mpz_mod.  Document, and list as an
     incompatibility.
mpz_gcdext and mpn_gcdext ought to document
     what range of values the generated cofactors can take, and preferably
     ensure the definition uniquely specifies the cofactors for given inputs.
     A basic extended Euclidean algorithm or multi-step variant leads to
     |x|<|b| and |y|<|a| or something like that, but there's probably
     two solutions under just those restrictions.
mpz_invert should call mpn_gcdext directly.
random / mrand48.
libgmp.  This establishes good cross-checks, but it might be
     better to use simple reference routines where possible.  Where it's not
     possible some attention could be paid to the order of the tests, so a
     libgmp routine is only used for tests once it seems to be
     good.
mpf_set_q is very similar to mpf_div, it'd be
     good for the two to share code.  Perhaps mpf_set_q should
     make some mpf_t aliases for its numerator and denominator
     and just call mpf_div.  Both would be simplified a good deal
     by switching to mpn_tdiv_qr perhaps making them small enough
     not to bother with sharing (especially since mpf_set_q
     wouldn't need to watch out for overlaps).
ASSERTs at the start of each user-visible mpz/mpq/mpf
     function to check the validity of each mp?_t parameter, in
     particular to check they've been mp?_inited.  This might
     catch elementary mistakes in user programs.  Care would need to be taken
     over MPZ_TMP_INITed variables used internally.  If nothing
     else then consistency checks like size<=alloc, ptr not
     NULL and ptr+size not wrapping around the address space,
     would be possible.
getrusage and gettimeofday are reliable.
     Currently we pretend in configure that the dodgy m68k netbsd 1.4.1
     getrusage doesn't exist.  If a test might take a long time
     to run then perhaps cache the result in a file somewhere.
 unsigned long int is used for
     bit counts/ranges, and that mp_size_t is used for limb counts.
mpz_inp_str (etc) doesn't say when it stops reading digits.
__clz_tab.  But this would be a very small space saving, so
     perhaps not worth the complexity.
mpz_get_si returns 0x80000000 for -0x100000000, whereas it's
     sort of supposed to return the low 31 (or 63) bits.  But this is
     undocumented, and perhaps not too important.
mpz_*_ui division routines currently return abs(a%b).
     Perhaps make them return the real remainder instead?  Return type would
     be signed long int.  But this would be an incompatible
     change, so it might have to be under newly named functions.
mpz_init_set* and mpz_realloc could allocate
     say an extra 16 limbs over what's needed, so as to reduce the chance of
     having to do a reallocate if the mpz_t grows a bit more.
     This could only be an option, since it'd badly bloat memory usage in
     applications using many small values.
m68020fp or similar to select
     68881 floating point.  config.guess could try to detect that too.  This
     would only be to add -m68881 to gcc, there's no GMP asm code using float,
     so perhaps it's just as easily left to the user to set
     CFLAGS.
mpq functions could perhaps check for numerator or
     denominator equal to 1, on the assumption that integers or
     denominator-only values might be expected to occur reasonably often.
count_trailing_zeros is used on more or less uniformly
     distributed numbers in a couple of places.  For some CPUs
     count_trailing_zeros is slow and it's probably worth handling
     the frequently occurring 0 to 2 trailing zeros cases specially.
mpf_t might like to let the exponent be undefined when
     size==0, instead of requiring it 0 as now.  It should be possible to do
     size==0 tests before paying attention to the exponent.  The advantage is
     not needing to set exp in the various places a zero result can arise,
     which avoids some tedium but is otherwise perhaps not too important.
     Currently mpz_set_f and mpf_cmp_ui depend on
     exp==0, maybe elsewhere too.
__gmp_allocate_func: Could use GCC __attribute__
     ((malloc)) on this, though don't know if it'd do much.  GCC 3.0
     allows that attribute on functions, but not function pointers (see info
     node "Attribute Syntax"), so would need a new autoconf test.  This can
     wait until there's a GCC that supports it.
mpn_add_ui contains two __GMPN_COPYs, one from
     mpn_add_1 and one from mpn_sub_1.  If those two
     routines were opened up a bit maybe that code could be shared.  When a
     copy needs to be done there's no carry to append for the add, and if the
     copy is non-empty no high zero for the sub. mpz_add
     when one operand is longer than the other, and to mpz_com
     since it's just -(x+1).
restrict'ed pointers: Does the C99 definition of restrict
     (one writer many readers, or whatever it is) suit the GMP style "same or
     separate" function parameters?  If so, judicious use might improve the
     code generated a bit.  Do any compilers have their own flavour of
     restrict as "completely unaliased", and is that still usable?
ABI
     option, selecting _SHORT_LIMB in gmp.h.  Naturally a new set
     of asm subroutines would be necessary.  Would need new
     mpz_set_ui etc since the current code assumes limb>=long,
     but 2-limb operand forms would find a use for long long on
     other processors too.
throw() could be added to the C function prototypes to
     declare that they don't throw exceptions.  This might let the C++
     compiler avoid generating frame info in application code (when it knows
     no called function throws an exception).  But this would prevent any
     future scheme for allowing out-of-memory or divide-by-zero exceptions.
     Though such things may or may not be feasible, it seems wisest not to
     close the door on them yet.
BITS_PER_MP_LIMB) mod
     m", then for the input limbs x calculating an inner product "sum
     p[i]*x[i]", and a final 3x1 limb remainder mod m.  If those powers take
     roughly N divide steps to calculate then there'd be an advantage any time
     the same m is used three or more times.  Suggested by Victor Shoup in
     connection with chinese-remainder style decompositions, but perhaps with
     other uses.