From 4954b784a53fb545ecd0bbea3f7cb8fc1874e5f8 Mon Sep 17 00:00:00 2001
From: wbhart <goodwillhart@googlemail.com>
Date: Wed, 23 Jul 2008 23:07:55 +0000
Subject: [PATCH] Update eol-style for these files.

---
 README            |  214 +++---
 doc/projects.html | 1290 ++++++++++++++++----------------
 doc/tasks.html    | 1804 ++++++++++++++++++++++-----------------------
 3 files changed, 1654 insertions(+), 1654 deletions(-)

diff --git a/README b/README
index 84920c99..74b5b226 100644
--- a/README
+++ b/README
@@ -1,107 +1,107 @@
-Copyright 1991, 1996, 1999, 2000 Free Software Foundation, Inc.
-
-This file is part of the GNU MP Library.
-
-The GNU MP Library is free software; you can redistribute it and/or modify
-it under the terms of the GNU Lesser General Public License as published by
-the Free Software Foundation; either version 2.1 of the License, or (at your
-option) any later version.
-
-The GNU MP Library is distributed in the hope that it will be useful, but
-WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
-or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU Lesser General Public
-License for more details.
-
-You should have received a copy of the GNU Lesser General Public License
-along with the GNU MP Library; see the file COPYING.LIB.  If not, write to
-the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
-02110-1301, USA.
-
-
-
-
-
-
-			THE MPIR LIBRARY
-
-
-MPIR is a library for arbitrary precision arithmetic, operating on signed
-integers, rational numbers, and floating point numbers.  It has a rich set of
-functions, and the functions have a regular interface.
-
-MPIR is designed to be as fast as possible, both for small operands and huge
-operands.  The speed is achieved by using fullwords as the basic arithmetic
-type, by using fast algorithms, with carefully optimized assembly code for the
-most common inner loops for lots of CPUs, and by a general emphasis on speed
-(instead of simplicity or elegance).
-
-MPIR is believed to be faster than any other similar library.  Its advantage
-increases with operand sizes for certain operations, since MPIR in many
-cases has asymptotically faster algorithms.
-
-MPIR is free software and may be freely copied on the terms contained in the
-files COPYING.LIB and COPYING (most of MPIR is under the former, some under
-the latter).
-
-
-
-			OVERVIEW OF MPIR
-
-There are five classes of functions in MPIR.
-
- 1. Signed integer arithmetic functions (mpz).  These functions are intended
-    to be easy to use, with their regular interface.  The associated type is
-    `mpz_t'.
-
- 2. Rational arithmetic functions (mpq).  For now, just a small set of
-    functions necessary for basic rational arithmetics.  The associated type
-    is `mpq_t'.
-
- 3. Floating-point arithmetic functions (mpf).  If the C type `double'
-    doesn't give enough precision for your application, declare your
-    variables as `mpf_t' instead, set the precision to any number desired,
-    and call the functions in the mpf class for the arithmetic operations.
-
- 4. Positive-integer, hard-to-use, very low overhead functions are in the
-    mpn class.  No memory management is performed.  The caller must ensure
-    enough space is available for the results.  The set of functions is not
-    regular, nor is the calling interface.  These functions accept input
-    arguments in the form of pairs consisting of a pointer to the least
-    significant word, and an integral size telling how many limbs (= words)
-    the pointer points to.
-
-    Almost all calculations, in the entire package, are made by calling these
-    low-level functions.
-
- 5. Berkeley MP compatible functions.
-
-    To use these functions, include the file "mp.h".  You can test if you are
-    using the GNU version by testing if the symbol __GNU_MP__ is defined.
-
-For more information on how to use MPIR, please refer to the documentation.
-It is composed from the file gmp.texi, and can be displayed on the screen or
-printed.  How to do that, as well how to build the library, is described in
-the INSTALL file in this directory.
-
-
-
-			REPORTING BUGS
-
-If you find a bug in the library, please make sure to tell us about it!
-
-You should first check the MPIR web pages at http://www.swox.com/gmp/,
-under "Status of the current release".  There will be patches for all known
-serious bugs there.
-
-Report bugs to bug-gmp@gnu.org.  What information is needed in a good bug
-report is described in the manual.  The same address can be used for
-suggesting modifications and enhancements.
-
-
-
-
-----------------
-Local variables:
-mode: text
-fill-column: 78
-End:
+Copyright 1991, 1996, 1999, 2000 Free Software Foundation, Inc.
+
+This file is part of the GNU MP Library.
+
+The GNU MP Library is free software; you can redistribute it and/or modify
+it under the terms of the GNU Lesser General Public License as published by
+the Free Software Foundation; either version 2.1 of the License, or (at your
+option) any later version.
+
+The GNU MP Library is distributed in the hope that it will be useful, but
+WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU Lesser General Public
+License for more details.
+
+You should have received a copy of the GNU Lesser General Public License
+along with the GNU MP Library; see the file COPYING.LIB.  If not, write to
+the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
+02110-1301, USA.
+
+
+
+
+
+
+			THE MPIR LIBRARY
+
+
+MPIR is a library for arbitrary precision arithmetic, operating on signed
+integers, rational numbers, and floating point numbers.  It has a rich set of
+functions, and the functions have a regular interface.
+
+MPIR is designed to be as fast as possible, both for small operands and huge
+operands.  The speed is achieved by using fullwords as the basic arithmetic
+type, by using fast algorithms, with carefully optimized assembly code for the
+most common inner loops for lots of CPUs, and by a general emphasis on speed
+(instead of simplicity or elegance).
+
+MPIR is believed to be faster than any other similar library.  Its advantage
+increases with operand sizes for certain operations, since MPIR in many
+cases has asymptotically faster algorithms.
+
+MPIR is free software and may be freely copied on the terms contained in the
+files COPYING.LIB and COPYING (most of MPIR is under the former, some under
+the latter).
+
+
+
+			OVERVIEW OF MPIR
+
+There are five classes of functions in MPIR.
+
+ 1. Signed integer arithmetic functions (mpz).  These functions are intended
+    to be easy to use, with their regular interface.  The associated type is
+    `mpz_t'.
+
+ 2. Rational arithmetic functions (mpq).  For now, just a small set of
+    functions necessary for basic rational arithmetics.  The associated type
+    is `mpq_t'.
+
+ 3. Floating-point arithmetic functions (mpf).  If the C type `double'
+    doesn't give enough precision for your application, declare your
+    variables as `mpf_t' instead, set the precision to any number desired,
+    and call the functions in the mpf class for the arithmetic operations.
+
+ 4. Positive-integer, hard-to-use, very low overhead functions are in the
+    mpn class.  No memory management is performed.  The caller must ensure
+    enough space is available for the results.  The set of functions is not
+    regular, nor is the calling interface.  These functions accept input
+    arguments in the form of pairs consisting of a pointer to the least
+    significant word, and an integral size telling how many limbs (= words)
+    the pointer points to.
+
+    Almost all calculations, in the entire package, are made by calling these
+    low-level functions.
+
+ 5. Berkeley MP compatible functions.
+
+    To use these functions, include the file "mp.h".  You can test if you are
+    using the GNU version by testing if the symbol __GNU_MP__ is defined.
+
+For more information on how to use MPIR, please refer to the documentation.
+It is composed from the file gmp.texi, and can be displayed on the screen or
+printed.  How to do that, as well how to build the library, is described in
+the INSTALL file in this directory.
+
+
+
+			REPORTING BUGS
+
+If you find a bug in the library, please make sure to tell us about it!
+
+You should first check the MPIR web pages at http://www.swox.com/gmp/,
+under "Status of the current release".  There will be patches for all known
+serious bugs there.
+
+Report bugs to bug-gmp@gnu.org.  What information is needed in a good bug
+report is described in the manual.  The same address can be used for
+suggesting modifications and enhancements.
+
+
+
+
+----------------
+Local variables:
+mode: text
+fill-column: 78
+End:
diff --git a/doc/projects.html b/doc/projects.html
index 0e5bd2b6..ca28da18 100644
--- a/doc/projects.html
+++ b/doc/projects.html
@@ -1,645 +1,645 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<html>
-<head>
-  <title>GMP Development Projects</title>
-  <link rel="shortcut icon" href="favicon.ico">
-  <link rel="stylesheet" href="gmp.css">
-  <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
-</head>
-
-<center>
-  <h1>
-    GMP Development Projects
-  </h1>
-</center>
-
-<font size=-1>
-Copyright 2000, 2001, 2002, 2003, 2004, 2005, 2006 Free Software Foundation,
-Inc. <br><br>
-This file is part of the GNU MP Library. <br><br>
-The GNU MP Library is free software; you can redistribute it and/or modify
-it under the terms of the GNU Lesser General Public License as published
-by the Free Software Foundation; either version 2.1 of the License, or (at
-your option) any later version. <br><br>
-The GNU MP Library is distributed in the hope that it will be useful, but
-WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
-or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU Lesser General Public
-License for more details. <br><br>
-You should have received a copy of the GNU Lesser General Public License
-along with the GNU MP Library; see the file COPYING.LIB.  If not, write to
-the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
-MA 02110-1301, USA.
-</font>
-
-<hr>
-<!-- NB. timestamp updated automatically by emacs -->
-  This file current as of 21 Apr 2006. Please send comments 
-  to http://groups.google.co.uk/group/mpir-devel/.
-
-<p> This file lists projects suitable for volunteers.  Please see the
-    <a href="tasks.html">tasks file</a> for smaller tasks.
-
-<p> If you want to work on any of the projects below, please let us know at
-    http://groups.google.co.uk/group/mpir-devel/.  If you want to help with a project
-    that already somebody else is working on, we will help you will get in touch.  
-    (There are no email addresses of
-    volunteers below, due to spamming problems.)
-
-<ul>
-<li> <strong>Faster multiplication</strong>
-
-  <p> The current multiplication code uses Karatsuba, 3-way Toom, and Fermat
-      FFT.  Several new developments are desirable:
-
-  <ol>
-
-    <li> Handle multiplication of operands with different digit count better
-	 than today.  We now split the operands in a very inefficient way, see
-	 mpn/generic/mul.c.  The best operands splitting strategy depends on
-	 the underlying multiplication algorithm to be used.
-
-    <li> Implement an FFT variant computing the coefficients mod m different
-	 limb size primes of the form l*2^k+1. i.e., compute m separate FFTs.
-	 The wanted coefficients will at the end be found by lifting with CRT
-	 (Chinese Remainder Theorem).  If we let m = 3, i.e., use 3 primes, we
-	 can split the operands into coefficients at limb boundaries, and if
-	 our machine uses b-bit limbs, we can multiply numbers with close to
-	 2^b limbs without coefficient overflow.  For smaller multiplication,
-	 we might perhaps let m = 1, and instead of splitting our operands at
-	 limb boundaries, split them in much smaller pieces.  We might also use
-	 4 or more primes, and split operands into bigger than b-bit chunks.
-	 By using more primes, the gain in shorter transform length, but lose
-	 in having to do more FFTs, but that is a slight total save.  We then
-	 lose in more expensive CRT. <br><br>
-
-         An nearly complete implementation has been done by Tommy Färnqvist.
-
-    <li> Perhaps consider N-way Toom, N > 3.  See Knuth's Seminumerical
-	 Algorithms for details on the method.  Code implementing it exists.
-	 This is asymptotically inferior to FFTs, but is finer grained.  A
-	 Toom-4 might fit in between Toom-3 and the FFTs (or it might not).
-
-    <li> Add support for partial products, either a given number of low limbs
-         or high limbs of the result.  A high partial product can be used by
-         <code>mpf_mul</code> and by Newton approximations, a low half partial
-         product might be of use in a future sub-quadratic REDC.  On small
-         sizes a partial product will be faster simply through fewer
-         cross-products, similar to the way squaring is faster.  But work by
-         Thom Mulders shows that for Karatsuba and higher order algorithms the
-         advantage is progressively lost, so for large sizes partial products
-         turn out to be no faster.
-
-  </ol>
-
-  <p> Another possibility would be an optimized cube.  In the basecase that
-      should definitely be able to save cross-products in a similar fashion to
-      squaring, but some investigation might be needed for how best to adapt
-      the higher-order algorithms.  Not sure whether cubing or further small
-      powers have any particularly important uses though.
-
-
-<li> <strong>Assembly routines</strong>
-
-  <p> Write new and improve existing assembly routines.  The tests/devel
-      programs and the tune/speed.c and tune/many.pl programs are useful for
-      testing and timing the routines you write.  See the README files in those
-      directories for more information.
-
-  <p> Please make sure your new routines are fast for these three situations:
-      <ol>
-        <li> Operands that fit into the cache.
-        <li> Small operands of less than, say, 10 limbs.
-        <li> Huge operands that does not fit into the cache.
-      </ol>
-
-  <p> The most important routines are mpn_addmul_1, mpn_mul_basecase and
-      mpn_sqr_basecase.  The latter two don't exist for all machines, while
-      mpn_addmul_1 exists for almost all machines.
-
-  <p> Standard techniques for these routines are unrolling, software
-      pipelining, and specialization for common operand values.  For machines
-      with poor integer multiplication, it is often possible to improve the
-      performance using floating-point operations, or SIMD operations such as
-      MMX or Sun's VIS.
-
-  <p> Using floating-point operations is interesting but somewhat tricky.
-      Since IEEE double has 53 bit of mantissa, one has to split the operands
-      in small prices, so that no result is greater than 2^53.  For 32-bit
-      computers, splitting one operand into 16-bit pieces works.  For 64-bit
-      machines, one operand can be split into 21-bit pieces and the other into
-      32-bit pieces.  (A 64-bit operand can be split into just three 21-bit
-      pieces if one allows the split operands to be negative!)
-
-
-<li> <strong>Faster GCD</strong>
-
-  <p> Work on Schönhage GCD and GCDEXT for large numbers is in progress.
-      Contact Niels Möller if you want to help.
-
-
-<li> <strong>Math functions for the mpf layer</strong>
-
-  <p> Implement the functions of math.h for the GMP mpf layer!  Check the book
-      "Pi and the AGM" by Borwein and Borwein for ideas how to do this.  These
-      functions are desirable: acos, acosh, asin, asinh, atan, atanh, atan2,
-      cos, cosh, exp, log, log10, pow, sin, sinh, tan, tanh.
-
-
-<li> <strong>Faster sqrt</strong>
-
-  <p> The current code uses divisions, which are reasonably fast, but it'd be
-      possible to use only multiplications by computing 1/sqrt(A) using this
-      formula:
-      <pre>
-                                    2
-                   x   = x  (3 &minus; A x )/2
-                    i+1   i         i  </pre>
-      The square root can then be computed like this:
-      <pre>
-                     sqrt(A) = A x
-                                  n  </pre>
-      <p> That final multiply might be the full size of the input (though it might
-      only need the high half of that), so there may or may not be any speedup
-      overall.
-
-
-<li> <strong>Nth root</strong>
-
-  <p> Improve mpn_rootrem.  The current code is really naive, using full
-      precision from the first iteration.  Also, calling mpn_pow_1 isn't very
-      clever, as only 1/n of the result bits will be used; truncation after
-      each multiplication would be better.  Avoiding division might also be
-      possible.
-
-      Work mostly done, see
-      <a href="http://gmplib.org/devel/</a>.
-
-
-<li> <strong>Quotient-Only Division</strong>
-
-  <p> Some work can be saved when only the quotient is required in a division,
-      basically the necessary correction -0, -1 or -2 to the estimated quotient
-      can almost always be determined from only a few limbs of multiply and
-      subtract, rather than forming a complete remainder.  The greatest savings
-      are when the quotient is small compared to the dividend and divisor.
-
-  <p> Some code along these lines can be found in the current
-      <code>mpn_tdiv_qr</code>, though perhaps calculating bigger chunks of
-      remainder than might be strictly necessary.  That function in its current
-      form actually then always goes on to calculate a full remainder.
-      Burnikel and Zeigler describe a similar approach for the divide and
-      conquer case.
-
-
-<li> <strong>Sub-Quadratic REDC and Exact Division</strong>
-
-  <p> See also
-      <a href="http://gmplib.org/devel/">http://gmplib.org/devel/</a>
-      for some new code for divexact.
-
-  <p> <code>mpn_bdivmod</code> and the <code>redc</code> in
-      <code>mpz_powm</code> should use some sort of divide and conquer
-      algorithm.  This would benefit <code>mpz_divexact</code>, and
-      <code>mpn_gcd</code> on large unequal size operands.  See "Exact Division
-      with Karatsuba Complexity" by Jebelean for a (brief) description.
-
-  <p> Failing that, some sort of <code>DIVEXACT_THRESHOLD</code> could be added
-      to control whether <code>mpz_divexact</code> uses
-      <code>mpn_bdivmod</code> or <code>mpn_tdiv_qr</code>, since the latter is
-      faster on large divisors.
-
-  <p> For the REDC, basically all that's needed is Montgomery's algorithm done
-      in multi-limb integers.  R is multiple limbs, and the inverse and
-      operands are multi-precision.
-
-  <p> For exact division the time to calculate a multi-limb inverse is not
-      amortized across many modular operations, but instead will probably
-      create a threshold below which the current style <code>mpn_bdivmod</code>
-      is best.  There's also Krandick and Jebelean, "Bidirectional Exact
-      Integer Division" to basically use a low to high exact division for the
-      low half quotient, and a quotient-only division for the high half.
-
-  <p> It will be noted that low-half and high-half multiplies, and a low-half
-      square, can be used.  These ought to each take as little as half the time
-      of a full multiply, or square, though work by Thom Mulders shows the
-      advantage is progressively lost as Karatsuba and higher algorithms are
-      applied.
-
-
-<li> <strong>Exceptions</strong>
-
-  <p> Some sort of scheme for exceptions handling would be desirable.
-      Presently the only thing documented is that divide by zero in GMP
-      functions provokes a deliberate machine divide by zero (on those systems
-      where such a thing exists at least).  The global <code>gmp_errno</code>
-      is not actually documented, except for the old <code>gmp_randinit</code>
-      function.  Being currently just a plain global means it's not
-      thread-safe.
-
-  <p> The basic choices for exceptions are returning an error code or having a
-      handler function to be called.  The disadvantage of error returns is they
-      have to be checked, leading to tedious and rarely executed code, and
-      strictly speaking such a scheme wouldn't be source or binary compatible.
-      The disadvantage of a handler function is that a <code>longjmp</code> or
-      similar recovery from it may be difficult.  A combination would be
-      possible, for instance by allowing the handler to return an error code.
-
-  <p> Divide-by-zero, sqrt-of-negative, and similar operand range errors can
-      normally be detected at the start of functions, so exception handling
-      would have a clean state.  What's worth considering though is that the
-      GMP function detecting the exception may have been called via some third
-      party library or self contained application module, and hence have
-      various bits of state to be cleaned up above it.  It'd be highly
-      desirable for an exceptions scheme to allow for such cleanups.
-
-  <p> The C++ destructor mechanism could help with cleanups both internally and
-      externally, but being a plain C library we don't want to depend on that.
-
-  <p> A C++ <code>throw</code> might be a good optional extra exceptions
-      mechanism, perhaps under a build option.  For GCC
-      <code>-fexceptions</code> will add the necessary frame information to
-      plain C code, or GMP could be compiled as C++.
-
-  <p> Out-of-memory exceptions are expected to be handled by the
-      <code>mp_set_memory_functions</code> routines, rather than being a
-      prospective part of divide-by-zero etc.  Some similar considerations
-      apply but what differs is that out-of-memory can arise deep within GMP
-      internals.  Even fundamental routines like <code>mpn_add_n</code> and
-      <code>mpn_addmul_1</code> can use temporary memory (for instance on Cray
-      vector systems).  Allowing for an error code return would require an
-      awful lot of checking internally.  Perhaps it'd still be worthwhile, but
-      it'd be a lot of changes and the extra code would probably be rather
-      rarely executed in normal usages.
-
-  <p> A <code>longjmp</code> recovery for out-of-memory will currently, in
-      general, lead to memory leaks and may leave GMP variables operated on in
-      inconsistent states.  Maybe it'd be possible to record recovery
-      information for use by the relevant allocate or reallocate function, but
-      that too would be a lot of changes.
-
-  <p> One scheme for out-of-memory would be to note that all GMP allocations go
-      through the <code>mp_set_memory_functions</code> routines.  So if the
-      application has an intended <code>setjmp</code> recovery point it can
-      record memory activity by GMP and abandon space allocated and variables
-      initialized after that point.  This might be as simple as directing the
-      allocation functions to a separate pool, but in general would have the
-      disadvantage of needing application-level bookkeeping on top of the
-      normal system <code>malloc</code>.  An advantage however is that it needs
-      nothing from GMP itself and on that basis doesn't burden applications not
-      needing recovery.  Note that there's probably some details to be worked
-      out here about reallocs of existing variables, and perhaps about copying
-      or swapping between "permanent" and "temporary" variables.
-
-  <p> Applications desiring a fine-grained error control, for instance a
-      language interpreter, would very possibly not be well served by a scheme
-      requiring <code>longjmp</code>.  Wrapping every GMP function call with a
-      <code>setjmp</code> would be very inconvenient.
-
-  <p> Another option would be to let <code>mpz_t</code> etc hold a sort of NaN,
-      a special value indicating an out-of-memory or other failure.  This would
-      be similar to NaNs in mpfr.  Unfortunately such a scheme could only be
-      used by programs prepared to handle such special values, since for
-      instance a program waiting for some condition to be satisfied could
-      become an infinite loop if it wasn't also watching for NaNs.  The work to
-      implement this would be significant too, lots of checking of inputs and
-      intermediate results.  And if <code>mpn</code> routines were to
-      participate in this (which they would have to internally) a lot of new
-      return values would need to be added, since of course there's no
-      <code>mpz_t</code> etc structure for them to indicate failure in.
-
-  <p> Stack overflow is another possible exception, but perhaps not one that
-      can be easily detected in general.  On i386 GNU/Linux for instance GCC
-      normally doesn't generate stack probes for an <code>alloca</code>, but
-      merely adjusts <code>%esp</code>.  A big enough <code>alloca</code> can
-      miss the stack redzone and hit arbitrary data.  GMP stack usage is
-      normally a function of operand size, which might be enough for some
-      applications to know they'll be safe.  Otherwise a fixed maximum usage
-      can probably be obtained by building with
-      <code>--enable-alloca=malloc-reentrant</code> (or
-      <code>notreentrant</code>).  Arranging the default to be
-      <code>alloca</code> only on blocks up to a certain size and
-      <code>malloc</code> thereafter might be a better approach and would have
-      the advantage of not having calculations limited by available stack.
-
-  <p> Actually recovering from stack overflow is of course another problem.  It
-      might be possible to catch a <code>SIGSEGV</code> in the stack redzone
-      and do something in a <code>sigaltstack</code>, on systems which have
-      that, but recovery might otherwise not be possible.  This is worth
-      bearing in mind because there's no point worrying about tight and careful
-      out-of-memory recovery if an out-of-stack is fatal.
-
-  <p> Operand overflow is another exception to be addressed.  It's easy for
-      instance to ask <code>mpz_pow_ui</code> for a result bigger than an
-      <code>mpz_t</code> can possibly represent.  Currently overflows in limb
-      or byte count calculations will go undetected.  Often they'll still end
-      up asking the memory functions for blocks bigger than available memory,
-      but that's by no means certain and results are unpredictable in general.
-      It'd be desirable to tighten up such size calculations.  Probably only
-      selected routines would need checks, if it's assumed say that no input
-      will be more than half of all memory and hence size additions like say
-      <code>mpz_mul</code> won't overflow.
-
-
-<li> <strong>Performance Tool</strong>
-
-  <p> It'd be nice to have some sort of tool for getting an overview of
-      performance.  Clearly a great many things could be done, but some primary
-      uses would be,
-
-      <ol>
-        <li> Checking speed variations between compilers.
-        <li> Checking relative performance between systems or CPUs.
-      </ol>
-
-  <p> A combination of measuring some fundamental routines and some
-      representative application routines might satisfy these.
-
-  <p> The tune/time.c routines would be the easiest way to get good accurate
-      measurements on lots of different systems.  The high level
-      <code>speed_measure</code> may or may not suit, but the basic
-      <code>speed_starttime</code> and <code>speed_endtime</code> would cover
-      lots of portability and accuracy questions.
-
-
-<li> <strong>Using <code>restrict</code></strong>
-
-  <p> There might be some value in judicious use of C99 style
-      <code>restrict</code> on various pointers, but this would need some
-      careful thought about what it implies for the various operand overlaps
-      permitted in GMP.
-
-  <p> Rumour has it some pre-C99 compilers had <code>restrict</code>, but
-      expressing tighter (or perhaps looser) requirements.  Might be worth
-      investigating that before using <code>restrict</code> unconditionally.
-
-  <p> Loops are presumably where the greatest benefit would be had, by allowing
-      the compiler to advance reads ahead of writes, perhaps as part of loop
-      unrolling.  However critical loops are generally coded in assembler, so
-      there might not be very much to gain.  And on Cray systems the explicit
-      use of <code>_Pragma</code> gives an equivalent effect.
-
-  <p> One thing to note is that Microsoft C headers (on ia64 at least) contain
-      <code>__declspec(restrict)</code>, so a <code>#define</code> of
-      <code>restrict</code> should be avoided.  It might be wisest to setup a
-      <code>gmp_restrict</code>.
-
-
-<li> <strong>Nx1 Division</strong>
-
-  <p> The limb-by-limb dependencies in the existing Nx1 division (and
-      remainder) code means that chips with multiple execution units or
-      pipelined multipliers are not fully utilized.
-
-  <p> One possibility is to follow the current preinv method but taking two
-      limbs at a time.  That means a 2x2-&gt;4 and a 2x1-&gt;2 multiply for
-      each two limbs processed, and because the 2x2 and 2x1 can each be done in
-      parallel the latency will be not much more than 2 multiplies for two
-      limbs, whereas the single limb method has a 2 multiply latency for just
-      one limb.  A version of <code>mpn_divrem_1</code> doing this has been
-      written in C, but not yet tested on likely chips.  Clearly this scheme
-      would extend to 3x3-&gt;9 and 3x1-&gt;3 etc, though with diminishing
-      returns.
-
-  <p> For <code>mpn_mod_1</code>, Peter L. Montgomery proposes the following
-      scheme.  For a limb R=2^<code>bits_per_mp_limb</code>, pre-calculate
-      values R mod N, R^2 mod N, R^3 mod N, R^4 mod N.  Then take dividend
-      limbs and multiply them by those values, thereby reducing them (moving
-      them down) by the corresponding factor.  The products can be added to
-      produce an intermediate remainder of 2 or 3 limbs to be similarly
-      included in the next step.  The point is that such multiplies can be done
-      in parallel, meaning as little as 1 multiply worth of latency for 4
-      limbs.  If the modulus N is less than R/4 (or is it R/5?) the summed
-      products will fit in 2 limbs, otherwise 3 will be required, but with the
-      high only being small.  Clearly this extends to as many factors of R as a
-      chip can efficiently apply.
-
-  <p> The logical conclusion for powers R^i is a whole array "p[i] = R^i mod N"
-      for i up to k, the size of the dividend.  This could then be applied at
-      multiplier throughput speed like an inner product.  If the powers took
-      roughly k divide steps to calculate then there'd be an advantage any time
-      the same N was used three or more times.  Suggested by Victor Shoup in
-      connection with chinese-remainder style decompositions, but perhaps with
-      other uses.
-
-  <p> <code>mpn_modexact_1_odd</code> calculates an x in the range 0&lt;=x&lt;d
-      satisfying a = q*d + x*b^n, where b=2^bits_per_limb.  The factor b^n
-      needed to get the true remainder r could be calculated by a powering
-      algorithm, allowing <code>mpn_modexact_1_odd</code> to be pressed into
-      service for an <code>mpn_mod_1</code>.  <code>modexact_1</code> is
-      simpler and on some chips can run noticeably faster than plain
-      <code>mod_1</code>, on Athlon for instance 11 cycles/limb instead of 17.
-      Such a difference could soon overcome the time to calculate b^n.  The
-      requirement for an odd divisor in <code>modexact</code> can be handled by
-      some shifting on-the-fly, or perhaps by an extra partial-limb step at the
-      end.
-
-
-<li> <strong>Factorial</strong>
-
-  <p> The removal of twos in the current code could be extended to factors of 3
-      or 5.  Taking this to its logical conclusion would be a complete
-      decomposition into powers of primes.  The power for a prime p is of
-      course floor(n/p)+floor(n/p^2)+...  Conrad Curry found this is quite fast
-      (using simultaneous powering as per Handbook of Applied Cryptography
-      algorithm 14.88).
-
-  <p> A difficulty with using all primes is that quite large n can be
-      calculated on a system with enough memory, larger than we'd probably want
-      for a table of primes, so some sort of sieving would be wanted.  Perhaps
-      just taking out the factors of 3 and 5 would give most of the speedup
-      that a prime decomposition can offer.
-
-
-<li> <strong>Binomial Coefficients</strong>
-
-  <p> An obvious improvement to the current code would be to strip factors of 2
-      from each multiplier and divisor and count them separately, to be applied
-      with a bit shift at the end.  Factors of 3 and perhaps 5 could even be
-      handled similarly.
-
-  <p> Conrad Curry reports a big speedup for binomial coefficients using a
-      prime powering scheme, at least for k near n/2.  Of course this is only
-      practical for moderate size n since again it requires primes up to n.
-
-  <p> When k is small the current (n-k+1)...n/1...k will be fastest.  Some sort
-      of rule would be needed for when to use this or when to use prime
-      powering.  Such a rule will be a function of both n and k.  Some
-      investigation is needed to see what sort of shape the crossover line will
-      have, the usual parameter tuning can of course find machine dependent
-      constants to fill in where necessary.
-
-  <p> An easier possibility also reported by Conrad Curry is that it may be
-      faster not to divide out the denominator (1...k) one-limb at a time, but
-      do one big division at the end.  Is this because a big divisor in
-      <code>mpn_bdivmod</code> trades the latency of
-      <code>mpn_divexact_1</code> for the throughput of
-      <code>mpn_submul_1</code>?  Overheads must hurt though.
-
-  <p> Another reason a big divisor might help is that
-      <code>mpn_divexact_1</code> won't be getting a full limb in
-      <code>mpz_bin_uiui</code>.  It's called when the n accumulator is full
-      but the k may be far from full.  Perhaps the two could be decoupled so k
-      is applied when full.  It'd be necessary to delay consideration of k
-      terms until the corresponding n terms had been applied though, since
-      otherwise the division won't be exact.
-
-
-<li> <strong>Perfect Power Testing</strong>
-
-  <p> <code>mpz_perfect_power_p</code> could be improved in a number of ways,
-      for instance p-adic arithmetic to find possible roots.
-
-  <p> Non-powers can be quickly identified by checking for Nth power residues
-      modulo small primes, like <code>mpn_perfect_square_p</code> does for
-      squares.  The residues to each power N for a given remainder could be
-      grouped into a bit mask, the masks for the remainders to each divisor
-      would then be "and"ed together to hopefully leave only a few candidate
-      powers.  Need to think about how wide to make such masks, ie. how many
-      powers to examine in this way.
-
-  <p> Any zero remainders found in residue testing reveal factors which can be
-      divided out, with the multiplicity restricting the powers that need to be
-      considered, as per the current code.  Further prime dividing should be
-      grouped into limbs like <code>PP</code>.  Need to think about how much
-      dividing to do like that, probably more for bigger inputs, less for
-      smaller inputs.
-
-  <p> <code>mpn_gcd_1</code> would probably be better than the current private
-      GCD routine.  The use it's put to isn't time-critical, and it might help
-      ensure correctness to just use the main GCD routine.
-
-
-<li> <strong>Prime Testing</strong>
-
-  <p> GMP is not really a number theory library and probably shouldn't have
-      large amounts of code dedicated to sophisticated prime testing
-      algorithms, but basic things well-implemented would suit.  Tests offering
-      certainty are probably all too big or too slow (or both!) to justify
-      inclusion in the main library.  Demo programs showing some possibilities
-      would be good though.
-
-  <p> The present "repetitions" argument to <code>mpz_probab_prime_p</code> is
-      rather specific to the Miller-Rabin tests of the current implementation.
-      Better would be some sort of parameter asking perhaps for a maximum
-      chance 1/2^x of a probable prime in fact being composite.  If
-      applications follow the advice that the present reps gives 1/4^reps
-      chance then perhaps such a change is unnecessary, but an explicitly
-      described 1/2^x would allow for changes in the implementation or even for
-      new proofs about the theory.
-
-  <p> <code>mpz_probab_prime_p</code> always initializes a new
-      <code>gmp_randstate_t</code> for randomized tests, which unfortunately
-      means it's not really very random and in particular always runs the same
-      tests for a given input.  Perhaps a new interface could accept an rstate
-      to use, so successive tests could increase confidence in the result.
-
-  <p> <code>mpn_mod_34lsub1</code> is an obvious and easy improvement to the
-      trial divisions.  And since the various prime factors are constants, the
-      remainder can be tested with something like
-<pre>
-#define MP_LIMB_DIVISIBLE_7_P(n) \
-  ((n) * MODLIMB_INVERSE_7 &lt;= MP_LIMB_T_MAX/7)
-</pre>
-      Which would help compilers that don't know how to optimize divisions by
-      constants, and is even an improvement on current gcc 3.2 code.  This
-      technique works for any modulus, see Granlund and Montgomery "Division by
-      Invariant Integers" section 9.
-
-  <p> The trial divisions are done with primes generated and grouped at
-      runtime.  This could instead be a table of data, with pre-calculated
-      inverses too.  Storing deltas, ie. amounts to add, rather than actual
-      primes would save space.  <code>udiv_qrnnd_preinv</code> style inverses
-      can be made to exist by adding dummy factors of 2 if necessary.  Some
-      thought needs to be given as to how big such a table should be, based on
-      how much dividing would be profitable for what sort of size inputs.  The
-      data could be shared by the perfect power testing.
-
-  <p> Jason Moxham points out that if a sqrt(-1) mod N exists then any factor
-      of N must be == 1 mod 4, saving half the work in trial dividing.  (If
-      x^2==-1 mod N then for a prime factor p we have x^2==-1 mod p and so the
-      jacobi symbol (-1/p)=1.  But also (-1/p)=(-1)^((p-1)/2), hence must have
-      p==1 mod 4.)  But knowing whether sqrt(-1) mod N exists is not too easy.
-      A strong pseudoprime test can reveal one, so perhaps such a test could be
-      inserted part way though the dividing.
-
-  <p> Jon Grantham "Frobenius Pseudoprimes" (www.pseudoprime.com) describes a
-      quadratic pseudoprime test taking about 3x longer than a plain test, but
-      with only a 1/7710 chance of error (whereas 3 plain Miller-Rabin tests
-      would offer only (1/4)^3 == 1/64).  Such a test needs completely random
-      parameters to satisfy the theory, though single-limb values would run
-      faster.  It's probably best to do at least one plain Miller-Rabin before
-      any quadratic tests, since that can identify composites in less total
-      time.
-
-  <p> Some thought needs to be given to the structure of which tests (trial
-      division, Miller-Rabin, quadratic) and how many are done, based on what
-      sort of inputs we expect, with a view to minimizing average time.
-
-  <p> It might be a good idea to break out subroutines for the various tests,
-      so that an application can combine them in ways it prefers, if sensible
-      defaults in <code>mpz_probab_prime_p</code> don't suit.  In particular
-      this would let applications skip tests it knew would be unprofitable,
-      like trial dividing when an input is already known to have no small
-      factors.
-
-  <p> For small inputs, combinations of theory and explicit search make it
-      relatively easy to offer certainty.  For instance numbers up to 2^32
-      could be handled with a strong pseudoprime test and table lookup.  But
-      it's rather doubtful whether a smallnum prime test belongs in a bignum
-      library.  Perhaps if it had other internal uses.
-
-  <p> An <code>mpz_nthprime</code> might be cute, but is almost certainly
-      impractical for anything but small n.
-
-
-<li> <strong>Intra-Library Calls</strong>
-
-  <p> On various systems, calls within libgmp still go through the PLT, TOC or
-      other mechanism, which makes the code bigger and slower than it needs to
-      be.
-
-  <p> The theory would be to have all GMP intra-library calls resolved directly
-      to the routines in the library.  An application wouldn't be able to
-      replace a routine, the way it can normally, but there seems no good
-      reason to do that, in normal circumstances.
-
-  <p> The <code>visibility</code> attribute in recent gcc is good for this,
-      because it lets gcc omit unnecessary GOT pointer setups or whatever if it
-      finds all calls are local and there's no global data references.
-      Documented entrypoints would be <code>protected</code>, and purely
-      internal things not wanted by test programs or anything can be
-      <code>internal</code>.
-
-  <p> Unfortunately, on i386 it seems <code>protected</code> ends up causing
-      text segment relocations within libgmp.so, meaning the library code can't
-      be shared between processes, defeating the purpose of a shared library.
-      Perhaps this is just a gremlin in binutils (debian packaged
-      2.13.90.0.16-1).
-
-  <p> The linker can be told directly (with a link script, or options) to do
-      the same sort of thing.  This doesn't change the code emitted by gcc of
-      course, but it does mean calls are resolved directly to their targets,
-      avoiding a PLT entry.
-
-  <p> Keeping symbols private to libgmp.so is probably a good thing in general
-      too, to stop anyone even attempting to access them.  But some
-      undocumented things will need or want to be kept visible, for use by
-      mpfr, or the test and tune programs.  Libtool has a standard option for
-      selecting public symbols (used now for libmp).
-
-
-</ul>
-<hr>
-
-</body>
-</html>
-
-<!--
-Local variables:
-eval: (add-hook 'write-file-hooks 'time-stamp)
-time-stamp-start: "This file current as of "
-time-stamp-format: "%:d %3b %:y"
-time-stamp-end: "\\."
-time-stamp-line-limit: 50
-End:
--->
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html>
+<head>
+  <title>GMP Development Projects</title>
+  <link rel="shortcut icon" href="favicon.ico">
+  <link rel="stylesheet" href="gmp.css">
+  <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
+</head>
+
+<center>
+  <h1>
+    GMP Development Projects
+  </h1>
+</center>
+
+<font size=-1>
+Copyright 2000, 2001, 2002, 2003, 2004, 2005, 2006 Free Software Foundation,
+Inc. <br><br>
+This file is part of the GNU MP Library. <br><br>
+The GNU MP Library is free software; you can redistribute it and/or modify
+it under the terms of the GNU Lesser General Public License as published
+by the Free Software Foundation; either version 2.1 of the License, or (at
+your option) any later version. <br><br>
+The GNU MP Library is distributed in the hope that it will be useful, but
+WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU Lesser General Public
+License for more details. <br><br>
+You should have received a copy of the GNU Lesser General Public License
+along with the GNU MP Library; see the file COPYING.LIB.  If not, write to
+the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+MA 02110-1301, USA.
+</font>
+
+<hr>
+<!-- NB. timestamp updated automatically by emacs -->
+  This file current as of 21 Apr 2006. Please send comments 
+  to http://groups.google.co.uk/group/mpir-devel/.
+
+<p> This file lists projects suitable for volunteers.  Please see the
+    <a href="tasks.html">tasks file</a> for smaller tasks.
+
+<p> If you want to work on any of the projects below, please let us know at
+    http://groups.google.co.uk/group/mpir-devel/.  If you want to help with a project
+    that already somebody else is working on, we will help you will get in touch.  
+    (There are no email addresses of
+    volunteers below, due to spamming problems.)
+
+<ul>
+<li> <strong>Faster multiplication</strong>
+
+  <p> The current multiplication code uses Karatsuba, 3-way Toom, and Fermat
+      FFT.  Several new developments are desirable:
+
+  <ol>
+
+    <li> Handle multiplication of operands with different digit count better
+	 than today.  We now split the operands in a very inefficient way, see
+	 mpn/generic/mul.c.  The best operands splitting strategy depends on
+	 the underlying multiplication algorithm to be used.
+
+    <li> Implement an FFT variant computing the coefficients mod m different
+	 limb size primes of the form l*2^k+1. i.e., compute m separate FFTs.
+	 The wanted coefficients will at the end be found by lifting with CRT
+	 (Chinese Remainder Theorem).  If we let m = 3, i.e., use 3 primes, we
+	 can split the operands into coefficients at limb boundaries, and if
+	 our machine uses b-bit limbs, we can multiply numbers with close to
+	 2^b limbs without coefficient overflow.  For smaller multiplication,
+	 we might perhaps let m = 1, and instead of splitting our operands at
+	 limb boundaries, split them in much smaller pieces.  We might also use
+	 4 or more primes, and split operands into bigger than b-bit chunks.
+	 By using more primes, the gain in shorter transform length, but lose
+	 in having to do more FFTs, but that is a slight total save.  We then
+	 lose in more expensive CRT. <br><br>
+
+         An nearly complete implementation has been done by Tommy Färnqvist.
+
+    <li> Perhaps consider N-way Toom, N > 3.  See Knuth's Seminumerical
+	 Algorithms for details on the method.  Code implementing it exists.
+	 This is asymptotically inferior to FFTs, but is finer grained.  A
+	 Toom-4 might fit in between Toom-3 and the FFTs (or it might not).
+
+    <li> Add support for partial products, either a given number of low limbs
+         or high limbs of the result.  A high partial product can be used by
+         <code>mpf_mul</code> and by Newton approximations, a low half partial
+         product might be of use in a future sub-quadratic REDC.  On small
+         sizes a partial product will be faster simply through fewer
+         cross-products, similar to the way squaring is faster.  But work by
+         Thom Mulders shows that for Karatsuba and higher order algorithms the
+         advantage is progressively lost, so for large sizes partial products
+         turn out to be no faster.
+
+  </ol>
+
+  <p> Another possibility would be an optimized cube.  In the basecase that
+      should definitely be able to save cross-products in a similar fashion to
+      squaring, but some investigation might be needed for how best to adapt
+      the higher-order algorithms.  Not sure whether cubing or further small
+      powers have any particularly important uses though.
+
+
+<li> <strong>Assembly routines</strong>
+
+  <p> Write new and improve existing assembly routines.  The tests/devel
+      programs and the tune/speed.c and tune/many.pl programs are useful for
+      testing and timing the routines you write.  See the README files in those
+      directories for more information.
+
+  <p> Please make sure your new routines are fast for these three situations:
+      <ol>
+        <li> Operands that fit into the cache.
+        <li> Small operands of less than, say, 10 limbs.
+        <li> Huge operands that does not fit into the cache.
+      </ol>
+
+  <p> The most important routines are mpn_addmul_1, mpn_mul_basecase and
+      mpn_sqr_basecase.  The latter two don't exist for all machines, while
+      mpn_addmul_1 exists for almost all machines.
+
+  <p> Standard techniques for these routines are unrolling, software
+      pipelining, and specialization for common operand values.  For machines
+      with poor integer multiplication, it is often possible to improve the
+      performance using floating-point operations, or SIMD operations such as
+      MMX or Sun's VIS.
+
+  <p> Using floating-point operations is interesting but somewhat tricky.
+      Since IEEE double has 53 bit of mantissa, one has to split the operands
+      in small prices, so that no result is greater than 2^53.  For 32-bit
+      computers, splitting one operand into 16-bit pieces works.  For 64-bit
+      machines, one operand can be split into 21-bit pieces and the other into
+      32-bit pieces.  (A 64-bit operand can be split into just three 21-bit
+      pieces if one allows the split operands to be negative!)
+
+
+<li> <strong>Faster GCD</strong>
+
+  <p> Work on Schönhage GCD and GCDEXT for large numbers is in progress.
+      Contact Niels Möller if you want to help.
+
+
+<li> <strong>Math functions for the mpf layer</strong>
+
+  <p> Implement the functions of math.h for the GMP mpf layer!  Check the book
+      "Pi and the AGM" by Borwein and Borwein for ideas how to do this.  These
+      functions are desirable: acos, acosh, asin, asinh, atan, atanh, atan2,
+      cos, cosh, exp, log, log10, pow, sin, sinh, tan, tanh.
+
+
+<li> <strong>Faster sqrt</strong>
+
+  <p> The current code uses divisions, which are reasonably fast, but it'd be
+      possible to use only multiplications by computing 1/sqrt(A) using this
+      formula:
+      <pre>
+                                    2
+                   x   = x  (3 &minus; A x )/2
+                    i+1   i         i  </pre>
+      The square root can then be computed like this:
+      <pre>
+                     sqrt(A) = A x
+                                  n  </pre>
+      <p> That final multiply might be the full size of the input (though it might
+      only need the high half of that), so there may or may not be any speedup
+      overall.
+
+
+<li> <strong>Nth root</strong>
+
+  <p> Improve mpn_rootrem.  The current code is really naive, using full
+      precision from the first iteration.  Also, calling mpn_pow_1 isn't very
+      clever, as only 1/n of the result bits will be used; truncation after
+      each multiplication would be better.  Avoiding division might also be
+      possible.
+
+      Work mostly done, see
+      <a href="http://gmplib.org/devel/</a>.
+
+
+<li> <strong>Quotient-Only Division</strong>
+
+  <p> Some work can be saved when only the quotient is required in a division,
+      basically the necessary correction -0, -1 or -2 to the estimated quotient
+      can almost always be determined from only a few limbs of multiply and
+      subtract, rather than forming a complete remainder.  The greatest savings
+      are when the quotient is small compared to the dividend and divisor.
+
+  <p> Some code along these lines can be found in the current
+      <code>mpn_tdiv_qr</code>, though perhaps calculating bigger chunks of
+      remainder than might be strictly necessary.  That function in its current
+      form actually then always goes on to calculate a full remainder.
+      Burnikel and Zeigler describe a similar approach for the divide and
+      conquer case.
+
+
+<li> <strong>Sub-Quadratic REDC and Exact Division</strong>
+
+  <p> See also
+      <a href="http://gmplib.org/devel/">http://gmplib.org/devel/</a>
+      for some new code for divexact.
+
+  <p> <code>mpn_bdivmod</code> and the <code>redc</code> in
+      <code>mpz_powm</code> should use some sort of divide and conquer
+      algorithm.  This would benefit <code>mpz_divexact</code>, and
+      <code>mpn_gcd</code> on large unequal size operands.  See "Exact Division
+      with Karatsuba Complexity" by Jebelean for a (brief) description.
+
+  <p> Failing that, some sort of <code>DIVEXACT_THRESHOLD</code> could be added
+      to control whether <code>mpz_divexact</code> uses
+      <code>mpn_bdivmod</code> or <code>mpn_tdiv_qr</code>, since the latter is
+      faster on large divisors.
+
+  <p> For the REDC, basically all that's needed is Montgomery's algorithm done
+      in multi-limb integers.  R is multiple limbs, and the inverse and
+      operands are multi-precision.
+
+  <p> For exact division the time to calculate a multi-limb inverse is not
+      amortized across many modular operations, but instead will probably
+      create a threshold below which the current style <code>mpn_bdivmod</code>
+      is best.  There's also Krandick and Jebelean, "Bidirectional Exact
+      Integer Division" to basically use a low to high exact division for the
+      low half quotient, and a quotient-only division for the high half.
+
+  <p> It will be noted that low-half and high-half multiplies, and a low-half
+      square, can be used.  These ought to each take as little as half the time
+      of a full multiply, or square, though work by Thom Mulders shows the
+      advantage is progressively lost as Karatsuba and higher algorithms are
+      applied.
+
+
+<li> <strong>Exceptions</strong>
+
+  <p> Some sort of scheme for exceptions handling would be desirable.
+      Presently the only thing documented is that divide by zero in GMP
+      functions provokes a deliberate machine divide by zero (on those systems
+      where such a thing exists at least).  The global <code>gmp_errno</code>
+      is not actually documented, except for the old <code>gmp_randinit</code>
+      function.  Being currently just a plain global means it's not
+      thread-safe.
+
+  <p> The basic choices for exceptions are returning an error code or having a
+      handler function to be called.  The disadvantage of error returns is they
+      have to be checked, leading to tedious and rarely executed code, and
+      strictly speaking such a scheme wouldn't be source or binary compatible.
+      The disadvantage of a handler function is that a <code>longjmp</code> or
+      similar recovery from it may be difficult.  A combination would be
+      possible, for instance by allowing the handler to return an error code.
+
+  <p> Divide-by-zero, sqrt-of-negative, and similar operand range errors can
+      normally be detected at the start of functions, so exception handling
+      would have a clean state.  What's worth considering though is that the
+      GMP function detecting the exception may have been called via some third
+      party library or self contained application module, and hence have
+      various bits of state to be cleaned up above it.  It'd be highly
+      desirable for an exceptions scheme to allow for such cleanups.
+
+  <p> The C++ destructor mechanism could help with cleanups both internally and
+      externally, but being a plain C library we don't want to depend on that.
+
+  <p> A C++ <code>throw</code> might be a good optional extra exceptions
+      mechanism, perhaps under a build option.  For GCC
+      <code>-fexceptions</code> will add the necessary frame information to
+      plain C code, or GMP could be compiled as C++.
+
+  <p> Out-of-memory exceptions are expected to be handled by the
+      <code>mp_set_memory_functions</code> routines, rather than being a
+      prospective part of divide-by-zero etc.  Some similar considerations
+      apply but what differs is that out-of-memory can arise deep within GMP
+      internals.  Even fundamental routines like <code>mpn_add_n</code> and
+      <code>mpn_addmul_1</code> can use temporary memory (for instance on Cray
+      vector systems).  Allowing for an error code return would require an
+      awful lot of checking internally.  Perhaps it'd still be worthwhile, but
+      it'd be a lot of changes and the extra code would probably be rather
+      rarely executed in normal usages.
+
+  <p> A <code>longjmp</code> recovery for out-of-memory will currently, in
+      general, lead to memory leaks and may leave GMP variables operated on in
+      inconsistent states.  Maybe it'd be possible to record recovery
+      information for use by the relevant allocate or reallocate function, but
+      that too would be a lot of changes.
+
+  <p> One scheme for out-of-memory would be to note that all GMP allocations go
+      through the <code>mp_set_memory_functions</code> routines.  So if the
+      application has an intended <code>setjmp</code> recovery point it can
+      record memory activity by GMP and abandon space allocated and variables
+      initialized after that point.  This might be as simple as directing the
+      allocation functions to a separate pool, but in general would have the
+      disadvantage of needing application-level bookkeeping on top of the
+      normal system <code>malloc</code>.  An advantage however is that it needs
+      nothing from GMP itself and on that basis doesn't burden applications not
+      needing recovery.  Note that there's probably some details to be worked
+      out here about reallocs of existing variables, and perhaps about copying
+      or swapping between "permanent" and "temporary" variables.
+
+  <p> Applications desiring a fine-grained error control, for instance a
+      language interpreter, would very possibly not be well served by a scheme
+      requiring <code>longjmp</code>.  Wrapping every GMP function call with a
+      <code>setjmp</code> would be very inconvenient.
+
+  <p> Another option would be to let <code>mpz_t</code> etc hold a sort of NaN,
+      a special value indicating an out-of-memory or other failure.  This would
+      be similar to NaNs in mpfr.  Unfortunately such a scheme could only be
+      used by programs prepared to handle such special values, since for
+      instance a program waiting for some condition to be satisfied could
+      become an infinite loop if it wasn't also watching for NaNs.  The work to
+      implement this would be significant too, lots of checking of inputs and
+      intermediate results.  And if <code>mpn</code> routines were to
+      participate in this (which they would have to internally) a lot of new
+      return values would need to be added, since of course there's no
+      <code>mpz_t</code> etc structure for them to indicate failure in.
+
+  <p> Stack overflow is another possible exception, but perhaps not one that
+      can be easily detected in general.  On i386 GNU/Linux for instance GCC
+      normally doesn't generate stack probes for an <code>alloca</code>, but
+      merely adjusts <code>%esp</code>.  A big enough <code>alloca</code> can
+      miss the stack redzone and hit arbitrary data.  GMP stack usage is
+      normally a function of operand size, which might be enough for some
+      applications to know they'll be safe.  Otherwise a fixed maximum usage
+      can probably be obtained by building with
+      <code>--enable-alloca=malloc-reentrant</code> (or
+      <code>notreentrant</code>).  Arranging the default to be
+      <code>alloca</code> only on blocks up to a certain size and
+      <code>malloc</code> thereafter might be a better approach and would have
+      the advantage of not having calculations limited by available stack.
+
+  <p> Actually recovering from stack overflow is of course another problem.  It
+      might be possible to catch a <code>SIGSEGV</code> in the stack redzone
+      and do something in a <code>sigaltstack</code>, on systems which have
+      that, but recovery might otherwise not be possible.  This is worth
+      bearing in mind because there's no point worrying about tight and careful
+      out-of-memory recovery if an out-of-stack is fatal.
+
+  <p> Operand overflow is another exception to be addressed.  It's easy for
+      instance to ask <code>mpz_pow_ui</code> for a result bigger than an
+      <code>mpz_t</code> can possibly represent.  Currently overflows in limb
+      or byte count calculations will go undetected.  Often they'll still end
+      up asking the memory functions for blocks bigger than available memory,
+      but that's by no means certain and results are unpredictable in general.
+      It'd be desirable to tighten up such size calculations.  Probably only
+      selected routines would need checks, if it's assumed say that no input
+      will be more than half of all memory and hence size additions like say
+      <code>mpz_mul</code> won't overflow.
+
+
+<li> <strong>Performance Tool</strong>
+
+  <p> It'd be nice to have some sort of tool for getting an overview of
+      performance.  Clearly a great many things could be done, but some primary
+      uses would be,
+
+      <ol>
+        <li> Checking speed variations between compilers.
+        <li> Checking relative performance between systems or CPUs.
+      </ol>
+
+  <p> A combination of measuring some fundamental routines and some
+      representative application routines might satisfy these.
+
+  <p> The tune/time.c routines would be the easiest way to get good accurate
+      measurements on lots of different systems.  The high level
+      <code>speed_measure</code> may or may not suit, but the basic
+      <code>speed_starttime</code> and <code>speed_endtime</code> would cover
+      lots of portability and accuracy questions.
+
+
+<li> <strong>Using <code>restrict</code></strong>
+
+  <p> There might be some value in judicious use of C99 style
+      <code>restrict</code> on various pointers, but this would need some
+      careful thought about what it implies for the various operand overlaps
+      permitted in GMP.
+
+  <p> Rumour has it some pre-C99 compilers had <code>restrict</code>, but
+      expressing tighter (or perhaps looser) requirements.  Might be worth
+      investigating that before using <code>restrict</code> unconditionally.
+
+  <p> Loops are presumably where the greatest benefit would be had, by allowing
+      the compiler to advance reads ahead of writes, perhaps as part of loop
+      unrolling.  However critical loops are generally coded in assembler, so
+      there might not be very much to gain.  And on Cray systems the explicit
+      use of <code>_Pragma</code> gives an equivalent effect.
+
+  <p> One thing to note is that Microsoft C headers (on ia64 at least) contain
+      <code>__declspec(restrict)</code>, so a <code>#define</code> of
+      <code>restrict</code> should be avoided.  It might be wisest to setup a
+      <code>gmp_restrict</code>.
+
+
+<li> <strong>Nx1 Division</strong>
+
+  <p> The limb-by-limb dependencies in the existing Nx1 division (and
+      remainder) code means that chips with multiple execution units or
+      pipelined multipliers are not fully utilized.
+
+  <p> One possibility is to follow the current preinv method but taking two
+      limbs at a time.  That means a 2x2-&gt;4 and a 2x1-&gt;2 multiply for
+      each two limbs processed, and because the 2x2 and 2x1 can each be done in
+      parallel the latency will be not much more than 2 multiplies for two
+      limbs, whereas the single limb method has a 2 multiply latency for just
+      one limb.  A version of <code>mpn_divrem_1</code> doing this has been
+      written in C, but not yet tested on likely chips.  Clearly this scheme
+      would extend to 3x3-&gt;9 and 3x1-&gt;3 etc, though with diminishing
+      returns.
+
+  <p> For <code>mpn_mod_1</code>, Peter L. Montgomery proposes the following
+      scheme.  For a limb R=2^<code>bits_per_mp_limb</code>, pre-calculate
+      values R mod N, R^2 mod N, R^3 mod N, R^4 mod N.  Then take dividend
+      limbs and multiply them by those values, thereby reducing them (moving
+      them down) by the corresponding factor.  The products can be added to
+      produce an intermediate remainder of 2 or 3 limbs to be similarly
+      included in the next step.  The point is that such multiplies can be done
+      in parallel, meaning as little as 1 multiply worth of latency for 4
+      limbs.  If the modulus N is less than R/4 (or is it R/5?) the summed
+      products will fit in 2 limbs, otherwise 3 will be required, but with the
+      high only being small.  Clearly this extends to as many factors of R as a
+      chip can efficiently apply.
+
+  <p> The logical conclusion for powers R^i is a whole array "p[i] = R^i mod N"
+      for i up to k, the size of the dividend.  This could then be applied at
+      multiplier throughput speed like an inner product.  If the powers took
+      roughly k divide steps to calculate then there'd be an advantage any time
+      the same N was used three or more times.  Suggested by Victor Shoup in
+      connection with chinese-remainder style decompositions, but perhaps with
+      other uses.
+
+  <p> <code>mpn_modexact_1_odd</code> calculates an x in the range 0&lt;=x&lt;d
+      satisfying a = q*d + x*b^n, where b=2^bits_per_limb.  The factor b^n
+      needed to get the true remainder r could be calculated by a powering
+      algorithm, allowing <code>mpn_modexact_1_odd</code> to be pressed into
+      service for an <code>mpn_mod_1</code>.  <code>modexact_1</code> is
+      simpler and on some chips can run noticeably faster than plain
+      <code>mod_1</code>, on Athlon for instance 11 cycles/limb instead of 17.
+      Such a difference could soon overcome the time to calculate b^n.  The
+      requirement for an odd divisor in <code>modexact</code> can be handled by
+      some shifting on-the-fly, or perhaps by an extra partial-limb step at the
+      end.
+
+
+<li> <strong>Factorial</strong>
+
+  <p> The removal of twos in the current code could be extended to factors of 3
+      or 5.  Taking this to its logical conclusion would be a complete
+      decomposition into powers of primes.  The power for a prime p is of
+      course floor(n/p)+floor(n/p^2)+...  Conrad Curry found this is quite fast
+      (using simultaneous powering as per Handbook of Applied Cryptography
+      algorithm 14.88).
+
+  <p> A difficulty with using all primes is that quite large n can be
+      calculated on a system with enough memory, larger than we'd probably want
+      for a table of primes, so some sort of sieving would be wanted.  Perhaps
+      just taking out the factors of 3 and 5 would give most of the speedup
+      that a prime decomposition can offer.
+
+
+<li> <strong>Binomial Coefficients</strong>
+
+  <p> An obvious improvement to the current code would be to strip factors of 2
+      from each multiplier and divisor and count them separately, to be applied
+      with a bit shift at the end.  Factors of 3 and perhaps 5 could even be
+      handled similarly.
+
+  <p> Conrad Curry reports a big speedup for binomial coefficients using a
+      prime powering scheme, at least for k near n/2.  Of course this is only
+      practical for moderate size n since again it requires primes up to n.
+
+  <p> When k is small the current (n-k+1)...n/1...k will be fastest.  Some sort
+      of rule would be needed for when to use this or when to use prime
+      powering.  Such a rule will be a function of both n and k.  Some
+      investigation is needed to see what sort of shape the crossover line will
+      have, the usual parameter tuning can of course find machine dependent
+      constants to fill in where necessary.
+
+  <p> An easier possibility also reported by Conrad Curry is that it may be
+      faster not to divide out the denominator (1...k) one-limb at a time, but
+      do one big division at the end.  Is this because a big divisor in
+      <code>mpn_bdivmod</code> trades the latency of
+      <code>mpn_divexact_1</code> for the throughput of
+      <code>mpn_submul_1</code>?  Overheads must hurt though.
+
+  <p> Another reason a big divisor might help is that
+      <code>mpn_divexact_1</code> won't be getting a full limb in
+      <code>mpz_bin_uiui</code>.  It's called when the n accumulator is full
+      but the k may be far from full.  Perhaps the two could be decoupled so k
+      is applied when full.  It'd be necessary to delay consideration of k
+      terms until the corresponding n terms had been applied though, since
+      otherwise the division won't be exact.
+
+
+<li> <strong>Perfect Power Testing</strong>
+
+  <p> <code>mpz_perfect_power_p</code> could be improved in a number of ways,
+      for instance p-adic arithmetic to find possible roots.
+
+  <p> Non-powers can be quickly identified by checking for Nth power residues
+      modulo small primes, like <code>mpn_perfect_square_p</code> does for
+      squares.  The residues to each power N for a given remainder could be
+      grouped into a bit mask, the masks for the remainders to each divisor
+      would then be "and"ed together to hopefully leave only a few candidate
+      powers.  Need to think about how wide to make such masks, ie. how many
+      powers to examine in this way.
+
+  <p> Any zero remainders found in residue testing reveal factors which can be
+      divided out, with the multiplicity restricting the powers that need to be
+      considered, as per the current code.  Further prime dividing should be
+      grouped into limbs like <code>PP</code>.  Need to think about how much
+      dividing to do like that, probably more for bigger inputs, less for
+      smaller inputs.
+
+  <p> <code>mpn_gcd_1</code> would probably be better than the current private
+      GCD routine.  The use it's put to isn't time-critical, and it might help
+      ensure correctness to just use the main GCD routine.
+
+
+<li> <strong>Prime Testing</strong>
+
+  <p> GMP is not really a number theory library and probably shouldn't have
+      large amounts of code dedicated to sophisticated prime testing
+      algorithms, but basic things well-implemented would suit.  Tests offering
+      certainty are probably all too big or too slow (or both!) to justify
+      inclusion in the main library.  Demo programs showing some possibilities
+      would be good though.
+
+  <p> The present "repetitions" argument to <code>mpz_probab_prime_p</code> is
+      rather specific to the Miller-Rabin tests of the current implementation.
+      Better would be some sort of parameter asking perhaps for a maximum
+      chance 1/2^x of a probable prime in fact being composite.  If
+      applications follow the advice that the present reps gives 1/4^reps
+      chance then perhaps such a change is unnecessary, but an explicitly
+      described 1/2^x would allow for changes in the implementation or even for
+      new proofs about the theory.
+
+  <p> <code>mpz_probab_prime_p</code> always initializes a new
+      <code>gmp_randstate_t</code> for randomized tests, which unfortunately
+      means it's not really very random and in particular always runs the same
+      tests for a given input.  Perhaps a new interface could accept an rstate
+      to use, so successive tests could increase confidence in the result.
+
+  <p> <code>mpn_mod_34lsub1</code> is an obvious and easy improvement to the
+      trial divisions.  And since the various prime factors are constants, the
+      remainder can be tested with something like
+<pre>
+#define MP_LIMB_DIVISIBLE_7_P(n) \
+  ((n) * MODLIMB_INVERSE_7 &lt;= MP_LIMB_T_MAX/7)
+</pre>
+      Which would help compilers that don't know how to optimize divisions by
+      constants, and is even an improvement on current gcc 3.2 code.  This
+      technique works for any modulus, see Granlund and Montgomery "Division by
+      Invariant Integers" section 9.
+
+  <p> The trial divisions are done with primes generated and grouped at
+      runtime.  This could instead be a table of data, with pre-calculated
+      inverses too.  Storing deltas, ie. amounts to add, rather than actual
+      primes would save space.  <code>udiv_qrnnd_preinv</code> style inverses
+      can be made to exist by adding dummy factors of 2 if necessary.  Some
+      thought needs to be given as to how big such a table should be, based on
+      how much dividing would be profitable for what sort of size inputs.  The
+      data could be shared by the perfect power testing.
+
+  <p> Jason Moxham points out that if a sqrt(-1) mod N exists then any factor
+      of N must be == 1 mod 4, saving half the work in trial dividing.  (If
+      x^2==-1 mod N then for a prime factor p we have x^2==-1 mod p and so the
+      jacobi symbol (-1/p)=1.  But also (-1/p)=(-1)^((p-1)/2), hence must have
+      p==1 mod 4.)  But knowing whether sqrt(-1) mod N exists is not too easy.
+      A strong pseudoprime test can reveal one, so perhaps such a test could be
+      inserted part way though the dividing.
+
+  <p> Jon Grantham "Frobenius Pseudoprimes" (www.pseudoprime.com) describes a
+      quadratic pseudoprime test taking about 3x longer than a plain test, but
+      with only a 1/7710 chance of error (whereas 3 plain Miller-Rabin tests
+      would offer only (1/4)^3 == 1/64).  Such a test needs completely random
+      parameters to satisfy the theory, though single-limb values would run
+      faster.  It's probably best to do at least one plain Miller-Rabin before
+      any quadratic tests, since that can identify composites in less total
+      time.
+
+  <p> Some thought needs to be given to the structure of which tests (trial
+      division, Miller-Rabin, quadratic) and how many are done, based on what
+      sort of inputs we expect, with a view to minimizing average time.
+
+  <p> It might be a good idea to break out subroutines for the various tests,
+      so that an application can combine them in ways it prefers, if sensible
+      defaults in <code>mpz_probab_prime_p</code> don't suit.  In particular
+      this would let applications skip tests it knew would be unprofitable,
+      like trial dividing when an input is already known to have no small
+      factors.
+
+  <p> For small inputs, combinations of theory and explicit search make it
+      relatively easy to offer certainty.  For instance numbers up to 2^32
+      could be handled with a strong pseudoprime test and table lookup.  But
+      it's rather doubtful whether a smallnum prime test belongs in a bignum
+      library.  Perhaps if it had other internal uses.
+
+  <p> An <code>mpz_nthprime</code> might be cute, but is almost certainly
+      impractical for anything but small n.
+
+
+<li> <strong>Intra-Library Calls</strong>
+
+  <p> On various systems, calls within libgmp still go through the PLT, TOC or
+      other mechanism, which makes the code bigger and slower than it needs to
+      be.
+
+  <p> The theory would be to have all GMP intra-library calls resolved directly
+      to the routines in the library.  An application wouldn't be able to
+      replace a routine, the way it can normally, but there seems no good
+      reason to do that, in normal circumstances.
+
+  <p> The <code>visibility</code> attribute in recent gcc is good for this,
+      because it lets gcc omit unnecessary GOT pointer setups or whatever if it
+      finds all calls are local and there's no global data references.
+      Documented entrypoints would be <code>protected</code>, and purely
+      internal things not wanted by test programs or anything can be
+      <code>internal</code>.
+
+  <p> Unfortunately, on i386 it seems <code>protected</code> ends up causing
+      text segment relocations within libgmp.so, meaning the library code can't
+      be shared between processes, defeating the purpose of a shared library.
+      Perhaps this is just a gremlin in binutils (debian packaged
+      2.13.90.0.16-1).
+
+  <p> The linker can be told directly (with a link script, or options) to do
+      the same sort of thing.  This doesn't change the code emitted by gcc of
+      course, but it does mean calls are resolved directly to their targets,
+      avoiding a PLT entry.
+
+  <p> Keeping symbols private to libgmp.so is probably a good thing in general
+      too, to stop anyone even attempting to access them.  But some
+      undocumented things will need or want to be kept visible, for use by
+      mpfr, or the test and tune programs.  Libtool has a standard option for
+      selecting public symbols (used now for libmp).
+
+
+</ul>
+<hr>
+
+</body>
+</html>
+
+<!--
+Local variables:
+eval: (add-hook 'write-file-hooks 'time-stamp)
+time-stamp-start: "This file current as of "
+time-stamp-format: "%:d %3b %:y"
+time-stamp-end: "\\."
+time-stamp-line-limit: 50
+End:
+-->
diff --git a/doc/tasks.html b/doc/tasks.html
index fa31e2a0..da2487c5 100644
--- a/doc/tasks.html
+++ b/doc/tasks.html
@@ -1,902 +1,902 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<html>
-<head>
-  <title>GMP Itemized Development Tasks</title>
-  <link rel="shortcut icon" href="favicon.ico">
-  <link rel="stylesheet" href="gmp.css">
-  <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
-</head>
-
-<center>
-  <h1>
-    GMP Itemized Development Tasks
-  </h1>
-</center>
-
-<font size=-1>
-Copyright 2000, 2001, 2002, 2003, 2004, 2006 Free Software Foundation, Inc. <br><br>
-This file is part of the GNU MP Library. <br><br>
-The GNU MP Library is free software; you can redistribute it and/or modify
-it under the terms of the GNU Lesser General Public License as published
-by the Free Software Foundation; either version 2.1 of the License, or (at
-your option) any later version. <br><br>
-The GNU MP Library is distributed in the hope that it will be useful, but
-WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
-or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU Lesser General Public
-License for more details. <br><br>
-You should have received a copy of the GNU Lesser General Public License
-along with the GNU MP Library; see the file COPYING.LIB.  If not, write to
-the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
-MA 02110-1301, USA.
-</font>
-
-<hr>
-<!-- NB. timestamp updated automatically by emacs -->
-  This file current as of 21 Apr 2006.  
-  Please send comments to
-  <a href="http://groups.google.co.uk/group/mpir-devel/">http://groups.google.co.uk/group/mpir-devel/</a>.
-
-<p> These are itemized GMP development tasks.  Not all the tasks
-    listed here are suitable for volunteers, but many of them are.
-    Please see the <a href="projects.html">projects file</a> for more
-    sizeable projects.
-
-<h4>Correctness and Completeness</h4>
-<ul>
-<li> <code>_LONG_LONG_LIMB</code> in gmp.h is not namespace clean.  Reported
-     by Patrick Pelissier.
-     <br>
-     We sort of mentioned <code>_LONG_LONG_LIMB</code> in past releases, so
-     need to be careful about changing it.  It used to be a define
-     applications had to set for long long limb systems, but that in
-     particular is no longer relevant now that it's established automatically.
-<li> The various reuse.c tests need to force reallocation by calling
-     <code>_mpz_realloc</code> with a small (1 limb) size.
-<li> One reuse case is missing from mpX/tests/reuse.c:
-     <code>mpz_XXX(a,a,a)</code>.
-<li> When printing <code>mpf_t</code> numbers with exponents &gt;2^53 on
-     machines with 64-bit <code>mp_exp_t</code>, the precision of
-     <code>__mp_bases[base].chars_per_bit_exactly</code> is insufficient and
-     <code>mpf_get_str</code> 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.
-<li> Make the string reading functions allow the `0x' prefix when the base is
-     explicitly 16.  They currently only allow that prefix when the base is
-     unspecified (zero).
-<li> <code>mpf_eq</code> 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 <code>mpf_sub</code> for this
-     situation; put similar code in <code>mpf_eq</code>.  [In progress.]
-<li> <code>mpf_eq</code> doesn't implement what gmp.texi specifies.  It should
-     not use just whole limbs, but partial limbs.  [In progress.]
-<li> <code>mpf_set_str</code> doesn't validate it's exponent, for instance
-     garbage 123.456eX789X is accepted (and an exponent 0 used), and overflow
-     of a <code>long</code> is not detected.
-<li> <code>mpf_add</code> 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.
-<li> Windows DLLs: tests/mpz/reuse.c and tests/mpf/reuse.c initialize global
-     variables with pointers to <code>mpz_add</code> 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.
-<li> <code>mpz_pow_ui</code>: Detect when the result would be more memory than
-     a <code>size_t</code> can represent and raise some suitable exception,
-     probably an alloc call asking for <code>SIZE_T_MAX</code>, and if that
-     somehow succeeds then an <code>abort</code>.  Various size overflows of
-     this kind are not handled gracefully, probably resulting in segvs.
-     <br>
-     In <code>mpz_n_pow_ui</code>, detect when the count of low zero bits
-     exceeds an <code>unsigned long</code>.  There's a (small) chance of this
-     happening but still having enough memory to represent the value.
-     Reported by Winfried Dreckmann in for instance <code>mpz_ui_pow_ui (x,
-     4UL, 1431655766UL)</code>.
-<li> <code>mpf</code>: Detect exponent overflow and raise some exception.
-     It'd be nice to allow the full <code>mp_exp_t</code> range since that's
-     how it's been in the past, but maybe dropping one bit would make it
-     easier to test if e1+e2 goes out of bounds.
-</ul>
-
-
-
-<h4>Machine Independent Optimization</h4>
-<ul>
-<li> <code>mpf_cmp</code>: For better cache locality, don't test for low zero
-     limbs until the high limbs fail to give an ordering.  Reduce code size by
-     turning the three <code>mpn_cmp</code>'s into a single loop stopping when
-     the end of one operand is reached (and then looking for a non-zero in the
-     rest of the other).
-<li> <code>mpf_mul_2exp</code>, <code>mpf_div_2exp</code>: The use of
-     <code>mpn_lshift</code> for any size&lt;=prec means repeated
-     <code>mul_2exp</code> and <code>div_2exp</code> calls accumulate low zero
-     limbs until size==prec+1 is reached.  Those zeros will slow down
-     subsequent operations, especially if the value is otherwise only small.
-     If low bits of the low limb are zero, use <code>mpn_rshift</code> so as
-     to not increase the size.
-<li> <code>mpn_dc_sqrtrem</code>: Don't use <code>mpn_addmul_1</code> with
-     multiplier==2, instead either <code>mpn_addlsh1_n</code> when available,
-     or <code>mpn_lshift</code>+<code>mpn_add_n</code> if not.
-<li> <code>mpn_dc_sqrtrem</code>, <code>mpn_sqrtrem2</code>: Don't use
-     <code>mpn_add_1</code> and <code>mpn_sub_1</code> for 1 limb operations,
-     instead <code>ADDC_LIMB</code> and <code>SUBC_LIMB</code>.
-<li> <code>mpn_sqrtrem2</code>: Use plain variables for <code>sp[0]</code> and
-     <code>rp[0]</code> calculations, so the compiler needn't worry about
-     aliasing between <code>sp</code> and <code>rp</code>.
-<li> <code>mpn_sqrtrem</code>: Some work can be saved in the last step when
-     the remainder is not required, as noted in Paul's paper.
-<li> <code>mpq_add</code>, <code>mpq_add</code>: The division "op1.den / gcd"
-     is done twice, where of course only once is necessary.  Reported by Larry
-     Lambe.
-<li> <code>mpq_add</code>, <code>mpq_sub</code>: The gcd fits a single limb
-     with high probability and in this case <code>modlimb_invert</code> could
-     be used to calculate the inverse just once for the two exact divisions
-     "op1.den / gcd" and "op2.den / gcd", rather than letting
-     <code>mpn_divexact_1</code> do it each time.  This would require a new
-     <code>mpn_preinv_divexact_1</code> interface.  Not sure if it'd be worth
-     the trouble.
-<li> <code>mpq_add</code>, <code>mpq_sub</code>: The use of
-     <code>mpz_mul(x,y,x)</code> causes temp allocation or copying in
-     <code>mpz_mul</code> which can probably be avoided.  A rewrite using
-     <code>mpn</code> might be best.
-<li> <code>mpn_gcdext</code>: Don't test <code>count_leading_zeros</code> for
-     zero, instead check the high bit of the operand and avoid invoking
-     <code>count_leading_zeros</code>.  This is an optimization on all
-     machines, and significant on machines with slow
-     <code>count_leading_zeros</code>, though it's possible an already
-     normalized operand might not be encountered very often.
-<li> Rewrite <code>umul_ppmm</code> to use floating-point for generating the
-     most significant limb (if <code>BITS_PER_MP_LIMB</code> &lt= 52 bits).
-     (Peter Montgomery has some ideas on this subject.)
-<li> Improve the default <code>umul_ppmm</code> code in longlong.h: Add partial
-     products with fewer operations.
-<li> Consider inlining <code>mpz_set_ui</code>.  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 <code>mpz_t</code>,
-     preventing the "lazy" allocation scheme below.
-<li> Consider inlining <code>mpz_[cft]div_ui</code> and maybe
-     <code>mpz_[cft]div_r_ui</code>.  A <code>__gmp_divide_by_zero</code>
-     would be needed for the divide by zero test, unless that could be left to
-     <code>mpn_mod_1</code> (not sure currently whether all the risc chips
-     provoke the right exception there if using mul-by-inverse).
-<li> Consider inlining: <code>mpz_fits_s*_p</code>.  The setups for
-     <code>LONG_MAX</code> etc would need to go into gmp.h, and on Cray it
-     might, unfortunately, be necessary to forcibly include &lt;limits.h&gt;
-     since there's no apparent way to get <code>SHRT_MAX</code> with an
-     expression (since <code>short</code> and <code>unsigned short</code> can
-     be different sizes).
-<li> <code>mpz_powm</code> and <code>mpz_powm_ui</code> 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.
-<li> <code>mpz_powm</code> and <code>mpz_powm_ui</code> want better
-     algorithm selection, and the latter should use REDC.  Both could
-     change to use an <code>mpn_powm</code> and <code>mpn_redc</code>.
-<li> <code>mpz_powm</code> REDC should do multiplications by <code>g[]</code>
-     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.
-<li> <code>mpz_powm</code> 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.
-<li> <code>mpn_gcd</code> might be able to be sped up on small to
-     moderate sizes by improving <code>find_a</code>, possibly just by
-     providing an alternate implementation for CPUs with slowish
-     <code>count_leading_zeros</code>.
-<li> Toom3 could use a low to high cache localized evaluate and interpolate.
-     The necessary <code>mpn_divexact_by3c</code> exists.
-<li> <code>mpf_set_str</code> 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.
-<li> <code>mpz_and</code>, <code>mpz_ior</code> and <code>mpz_xor</code> should
-     use <code>mpn_and_n</code> 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 <code>mpz</code>
-     routines?
-<li> <code>mpf_add</code>: 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).
-<li> <code>mpf_add</code>: 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 <code>MPN_COPY_INCR</code> will be done to
-     reduce prec+1 limbs to prec.
-<li> <code>mpf_div_ui</code>: Instead of padding with low zeros, call
-     <code>mpn_divrem_1</code> asking for fractional quotient limbs.
-<li> <code>mpf_div_ui</code>: Eliminate <code>TMP_ALLOC</code>.  When r!=u
-     there's no overlap and the division can be called on those operands.
-     When r==u and is prec+1 limbs, then it's an in-place division.  If r==u
-     and not prec+1 limbs, then move the available limbs up to prec+1 and do
-     an in-place there.
-<li> <code>mpf_div_ui</code>: Whether the high quotient limb is zero can be
-     determined by testing the dividend for high&lt;divisor.  When non-zero, the
-     divison can be done on prec dividend limbs instead of prec+1.  The result
-     size is also known before the division, so that can be a tail call (once
-     the <code>TMP_ALLOC</code> is eliminated).
-<li> <code>mpn_divrem_2</code> 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
-     <code>mpn_tdiv_qr</code>.
-<li> <code>mpf_sqrt</code>: If r!=u, and if u doesn't need to be padded with
-     zeros, then there's no need for the tp temporary.
-<li> <code>mpq_cmp_ui</code> could form the <code>num1*den2</code> and
-     <code>num2*den1</code> 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.
-<li> <code>mpq_cmp</code> 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.
-<li> <code>mpn_add_1</code>, <code>mpn_sub_1</code>, <code>mpn_add</code>,
-     <code>mpn_sub</code>: Internally use <code>__GMPN_ADD_1</code> etc
-     instead of the functions, so they get inlined on all compilers, not just
-     gcc and others with <code>inline</code> recognised in gmp.h.
-     <code>__GMPN_ADD_1</code> etc are meant mostly to support application
-     inline <code>mpn_add_1</code> 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.
-<li> <code>__gmp_extract_double</code> on 64-bit systems could use just one
-     bitfield for the mantissa extraction, not two, when endianness permits.
-     Might depend on the compiler allowing <code>long long</code> bit fields
-     when that's the only actual 64-bit type.
-<li> tal-notreent.c could keep a block of memory permanently allocated.
-     Currently the last nested <code>TMP_FREE</code> releases all memory, so
-     there's an allocate and free every time a top-level function using
-     <code>TMP</code> is called.  Would need
-     <code>mp_set_memory_functions</code> to tell tal-notreent.c to release
-     any cached memory when changing allocation functions though.
-<li> <code>__gmp_tmp_alloc</code> 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 <code>__gmp_tmp_increase</code> would be needed.  The requirement that
-     <code>TMP_ALLOC</code> is an expression might make the implementation a
-     bit ugly and/or a bit sub-optimal.
-<pre>
-#define TMP_ALLOC(n)
-  ((ROUND_UP(n) &gt; current-&gt;end - current-&gt;point ?
-     __gmp_tmp_increase (ROUND_UP (n)) : 0),
-     current-&gt;point += ROUND_UP (n),
-     current-&gt;point - ROUND_UP (n))
-</pre>
-<li> <code>__mp_bases</code> has a lot of data for bases which are pretty much
-     never used.  Perhaps the table should just go up to base 16, and have
-     code to generate data above that, if and when required.  Naturally this
-     assumes the code would be smaller than the data saved.
-<li> <code>__mp_bases</code> field <code>big_base_inverted</code> is only used
-     if <code>USE_PREINV_DIVREM_1</code> is true, and could be omitted
-     otherwise, to save space.
-<li> <code>mpz_get_str</code>, <code>mtox</code>: For power-of-2 bases, which
-     are of course fast, it seems a little silly to make a second pass over
-     the <code>mpn_get_str</code> output to convert to ASCII.  Perhaps combine
-     that with the bit extractions.
-<li> <code>mpz_gcdext</code>: If the caller requests only the S cofactor (of
-     A), and A&lt;B, then the code ends up generating the cofactor T (of B) and
-     deriving S from that.  Perhaps it'd be possible to arrange to get S in
-     the first place by calling <code>mpn_gcdext</code> with A+B,B.  This
-     might only be an advantage if A and B are about the same size.
-<li> <code>mpz_n_pow_ui</code> does a good job with small bases and stripping
-     powers of 2, but it's perhaps a bit too complicated for what it gains.
-     The simpler <code>mpn_pow_1</code> is a little faster on small exponents.
-     (Note some of the ugliness in <code>mpz_n_pow_ui</code> is due to
-     supporting <code>mpn_mul_2</code>.)
-     <br>
-     Perhaps the stripping of 2s in <code>mpz_n_pow_ui</code> should be
-     confined to single limb operands for simplicity and since that's where
-     the greatest gain would be.
-     <br>
-     Ideally <code>mpn_pow_1</code> and <code>mpz_n_pow_ui</code> would be
-     merged.  The reason <code>mpz_n_pow_ui</code> writes to an
-     <code>mpz_t</code> is that its callers leave it to make a good estimate
-     of the result size.  Callers of <code>mpn_pow_1</code> already know the
-     size by separate means (<code>mp_bases</code>).
-<li> <code>mpz_invert</code> should call <code>mpn_gcdext</code> directly.
-</ul>
-
-
-<h4>Machine Dependent Optimization</h4>
-<ul>
-<li> <code>invert_limb</code> on various processors might benefit from the
-     little Newton iteration done for alpha and ia64.
-<li> Alpha 21264: <code>mpn_addlsh1_n</code> could be implemented with
-     <code>mpn_addmul_1</code>, since that code at 3.5 is a touch faster than
-     a separate <code>lshift</code> and <code>add_n</code> at
-     1.75+2.125=3.875.  Or very likely some specific <code>addlsh1_n</code>
-     code could beat both.
-<li> Alpha 21264: Improve feed-in code for <code>mpn_mul_1</code>,
-     <code>mpn_addmul_1</code>, and <code>mpn_submul_1</code>.
-<li> Alpha 21164: Rewrite <code>mpn_mul_1</code>, <code>mpn_addmul_1</code>,
-     and <code>mpn_submul_1</code> 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.
-<li> Alpha: GCC 3.4 will introduce <code>__builtin_ctzl</code>,
-     <code>__builtin_clzl</code> and <code>__builtin_popcountl</code> using
-     the corresponding CIX <code>ct</code> instructions, and
-     <code>__builtin_alpha_cmpbge</code>.  These should give GCC more
-     information about sheduling etc than the <code>asm</code> blocks
-     currently used in longlong.h and gmp-impl.h.
-<li> Alpha Unicos: Apparently there's no <code>alloca</code> on this system,
-     making <code>configure</code> choose the slower
-     <code>malloc-reentrant</code> allocation method.  Is there a better way?
-     Maybe variable-length arrays per notes below.
-<li> Alpha Unicos 21164, 21264: <code>.align</code> is not used since it pads
-     with garbage.  Does the code get the intended slotting required for the
-     claimed speeds?  <code>.align</code> at the start of a function would
-     presumably be safe no matter how it pads.
-<li> ARM V5: <code>count_leading_zeros</code> can use the <code>clz</code>
-     instruction.  For GCC 3.4 and up, do this via <code>__builtin_clzl</code>
-     since then gcc knows it's "predicable".
-<li> Itanium: GCC 3.4 introduces <code>__builtin_popcount</code> which can be
-     used instead of an <code>asm</code> block.  The builtin should give gcc
-     more opportunities for scheduling, bundling and predication.
-     <code>__builtin_ctz</code> similarly (it just uses popcount as per
-     current longlong.h).
-<li> UltraSPARC/64: Optimize <code>mpn_mul_1</code>, <code>mpn_addmul_1</code>,
-     for s2 &lt; 2^32 (or perhaps for any zero 16-bit s2 chunk).  Not sure how
-     much this can improve the speed, though, since the symmetry that we rely
-     on is lost.  Perhaps we can just gain cycles when s2 &lt; 2^16, or more
-     accurately, when two 16-bit s2 chunks which are 16 bits apart are zero.
-<li> UltraSPARC/64: Write native <code>mpn_submul_1</code>, analogous to
-     <code>mpn_addmul_1</code>.
-<li> UltraSPARC/64: Write <code>umul_ppmm</code>.  Using four
-     "<code>mulx</code>"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 "<code>mulx</code>"s.
-<li> UltraSPARC/32: Rewrite <code>mpn_lshift</code>, <code>mpn_rshift</code>.
-     Will give 2 cycles/limb.  Trivial modifications of mpn/sparc64 should do.
-<li> UltraSPARC/32: Write special mpn_Xmul_1 loops for s2 &lt; 2^16.
-<li> UltraSPARC/32: Use <code>mulx</code> for <code>umul_ppmm</code> if
-     possible (see commented out code in longlong.h).  This is unlikely to
-     save more than a couple of cycles, so perhaps isn't worth bothering with.
-<li> UltraSPARC/32: On Solaris gcc doesn't give us <code>__sparc_v9__</code>
-     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 <code>mulx</code> for multiplying is commented out.)
-<li> UltraSPARC/32: <code>mpn_divexact_1</code> and
-     <code>mpn_modexact_1c_odd</code> can use a 64-bit inverse and take
-     64-bits at a time from the dividend, as per the 32-bit divisor case in
-     mpn/sparc64/mode1o.c.  This must be done in assembler, since the full
-     64-bit registers (<code>%gN</code>) are not available from C.
-<li> UltraSPARC/32: <code>mpn_divexact_by3c</code> can work 64-bits at a time
-     using <code>mulx</code>, in assembler.  This would be the same as for
-     sparc64.
-<li> UltraSPARC: <code>modlimb_invert</code> might save a few cycles from
-     masking down to just the useful bits at each point in the calculation,
-     since <code>mulx</code> speed depends on the highest bit set.  Either
-     explicit masks or small types like <code>short</code> and
-     <code>int</code> ought to work.
-<li> Sparc64 HAL R1 <code>popc</code>: This chip reputedly implements
-     <code>popc</code> properly (see gcc sparc.md).  Would need to recognise
-     it as <code>sparchalr1</code> or something in configure / config.sub /
-     config.guess.  <code>popc_limb</code> in gmp-impl.h could use this (per
-     commented out code).  <code>count_trailing_zeros</code> could use it too.
-<li> PA64: Improve <code>mpn_addmul_1</code>, <code>mpn_submul_1</code>, and
-     <code>mpn_mul_1</code>.  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 &lt; 2^32;
-     it should be possible to make them run at about 5 cycles/limb.
-<li> PPC601: See which of the power or powerpc32 code runs better.  Currently
-     the powerpc32 is used, but only because it's the default for
-     <code>powerpc*</code>.
-<li> PPC630: Rewrite <code>mpn_addmul_1</code>, <code>mpn_submul_1</code>, and
-     <code>mpn_mul_1</code>.  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).
-<li> PPC630: <code>mpn_rshift</code> could do the same sort of unrolled loop
-     as <code>mpn_lshift</code>.  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.
-<li> Implement <code>mpn_mul_basecase</code> and <code>mpn_sqr_basecase</code>
-     for important machines.  Helping the generic sqr_basecase.c with an
-     <code>mpn_sqr_diagonal</code> might be enough for some of the RISCs.
-<li> POWER2/POWER2SC: Schedule <code>mpn_lshift</code>/<code>mpn_rshift</code>.
-     Will bring time from 1.75 to 1.25 cycles/limb.
-<li> X86: Optimize non-MMX <code>mpn_lshift</code> for shifts by 1.  (See
-     Pentium code.)
-<li> X86: Good authority has it that in the past an inline <code>rep
-     movs</code> would upset GCC register allocation for the whole function.
-     Is this still true in GCC 3?  It uses <code>rep movs</code> itself for
-     <code>__builtin_memcpy</code>.  Examine the code for some simple and
-     complex functions to find out.  Inlining <code>rep movs</code> would be
-     desirable, it'd be both smaller and faster.
-<li> Pentium P54: <code>mpn_lshift</code> and <code>mpn_rshift</code> can come
-     down from 6.0 c/l to 5.5 or 5.375 by paying attention to pairing after
-     <code>shrdl</code> and <code>shldl</code>, see mpn/x86/pentium/README.
-<li> Pentium P55 MMX: <code>mpn_lshift</code> and <code>mpn_rshift</code>
-     might benefit from some destination prefetching.
-<li> PentiumPro: <code>mpn_divrem_1</code> might be able to use a
-     mul-by-inverse, hoping for maybe 30 c/l.
-<li> K7: <code>mpn_lshift</code> and <code>mpn_rshift</code> 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.
-<li> PPC32: Try using fewer registers in the current <code>mpn_lshift</code>.
-     The pipeline is now extremely deep, perhaps unnecessarily deep.
-<li> Fujitsu VPP: Vectorize main functions, perhaps in assembly language.
-<li> Fujitsu VPP: Write <code>mpn_mul_basecase</code> and
-     <code>mpn_sqr_basecase</code>.  This should use a "vertical multiplication
-     method", to avoid carry propagation.  splitting one of the operands in
-     11-bit chunks.
-<li> Pentium: <code>mpn_lshift</code> by 31 should use the special rshift
-     by 1 code, and vice versa <code>mpn_rshift</code> 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
-     <code>mpn_rshift</code> already provided.
-<li> Cray T3E: Experiment with optimization options.  In particular,
-     -hpipeline3 seems promising.  We should at least up -O to -O2 or -O3.
-<li> Cray: <code>mpn_com_n</code> and <code>mpn_and_n</code> etc very probably
-     wants a pragma like <code>MPN_COPY_INCR</code>.
-<li> Cray vector systems: <code>mpn_lshift</code>, <code>mpn_rshift</code>,
-     <code>mpn_popcount</code> and <code>mpn_hamdist</code> are nice and small
-     and could be inlined to avoid function calls.
-<li> Cray: Variable length arrays seem to be faster than the tal-notreent.c
-     scheme.  Not sure why, maybe they merely give the compiler more
-     information about aliasing (or the lack thereof).  Would like to modify
-     <code>TMP_ALLOC</code> 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
-     <code>alloca</code>.
-<li> Cray: <code>mpn_get_str</code> on power-of-2 bases ought to vectorize.
-     Does it?  <code>bits_per_digit</code> and the inner loop over bits in a
-     limb might prevent it.  Perhaps special cases for binary, octal and hex
-     would be worthwhile (very possibly for all processors too).
-<li> S390: <code>BSWAP_LIMB_FETCH</code> looks like it could be done with
-     <code>lrvg</code>, as per glibc sysdeps/s390/s390-64/bits/byteswap.h.
-     This is only for 64-bit mode or something is it, since 32-bit mode has
-     other code?  Also, is it worth using for <code>BSWAP_LIMB</code> too, or
-     would that mean a store and re-fetch?  Presumably that's what comes out
-     in glibc.
-<li> Improve <code>count_leading_zeros</code> for 64-bit machines:
-  <pre>
-	   if ((x &gt&gt 32) == 0) { x &lt&lt= 32; cnt += 32; }
-	   if ((x &gt&gt 48) == 0) { x &lt&lt= 16; cnt += 16; }
-	   ... </pre>
-<li> IRIX 6 MIPSpro compiler has an <code>__inline</code> which could perhaps
-     be used in <code>__GMP_EXTERN_INLINE</code>.  What would be the right way
-     to identify suitable versions of that compiler?
-<li> IRIX <code>cc</code> is rumoured to have an <code>_int_mult_upper</code>
-     (in <code>&lt;intrinsics.h&gt;</code> like Cray), but it didn't seem to
-     exist on some IRIX 6.5 systems tried.  If it does actually exist
-     somewhere it would very likely be an improvement over a function call to
-     umul.asm.
-<li> <code>mpn_get_str</code> final divisions by the base with
-     <code>udiv_qrnd_unnorm</code> could use some sort of multiply-by-inverse
-     on suitable machines.  This ends up happening for decimal by presenting
-     the compiler with a run-time constant, but the same for other bases would
-     be good.  Perhaps use could be made of the fact base&lt;256.
-<li> <code>mpn_umul_ppmm</code>, <code>mpn_udiv_qrnnd</code>: Return a
-     structure like <code>div_t</code> to avoid going through memory, in
-     particular helping RISCs that don't do store-to-load forwarding.  Clearly
-     this is only possible if the ABI returns a structure of two
-     <code>mp_limb_t</code>s in registers.
-     <br>
-     On PowerPC, structures are returned in memory on AIX and Darwin.  In SVR4
-     they're returned in registers, except that draft SVR4 had said memory, so
-     it'd be prudent to check which is done.  We can jam the compiler into the
-     right mode if we know how, since all this is purely internal to libgmp.
-     (gcc has an option, though of course gcc doesn't matter since we use
-     inline asm there.)
-</ul>
-
-<h4>New Functionality</h4>
-<ul>
-<li> Maybe add <code>mpz_crr</code> (Chinese Remainder Reconstruction).
-<li> Let `0b' and `0B' mean binary input everywhere.
-<li> <code>mpz_init</code> and <code>mpq_init</code> could do lazy allocation.
-     Set <code>ALLOC(var)</code> to 0 to indicate nothing allocated, and let
-     <code>_mpz_realloc</code> do the initial alloc.  Set
-     <code>z-&gt;_mp_d</code> to a dummy that <code>mpz_get_ui</code> and
-     similar can unconditionally fetch from.  Niels Möller has had a go at
-     this.
-     <br>
-     The advantages of the lazy scheme would be:
-     <ul>
-     <li> Initial allocate would be the size required for the first value
-          stored, rather than getting 1 limb in <code>mpz_init</code> and then
-          more or less immediately reallocating.
-     <li> <code>mpz_init</code> would only store magic values in the
-          <code>mpz_t</code> fields, and could be inlined.
-     <li> A fixed initializer could even be used by applications, like
-          <code>mpz_t z = MPZ_INITIALIZER;</code>, which might be convenient
-          for globals.
-     </ul>
-     The advantages of the current scheme are:
-     <ul>
-     <li> <code>mpz_set_ui</code> and other similar routines needn't check the
-          size allocated and can just store unconditionally.
-     <li> <code>mpz_set_ui</code> and perhaps others like
-          <code>mpz_tdiv_r_ui</code> and a prospective
-          <code>mpz_set_ull</code> could be inlined.
-     </ul>
-<li> Add <code>mpf_out_raw</code> and <code>mpf_inp_raw</code>.  Make sure
-     format is portable between 32-bit and 64-bit machines, and between
-     little-endian and big-endian machines.  A format which MPFR can use too
-     would be good.
-<li> <code>mpn_and_n</code> ... <code>mpn_copyd</code>: 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.
-<li> <code>mpz_set_str</code> etc variants taking string lengths rather than
-     null-terminators.
-<li> <code>mpz_andn</code>, <code>mpz_iorn</code>, <code>mpz_nand</code>,
-     <code>mpz_nior</code>, <code>mpz_xnor</code> might be useful additions,
-     if they could share code with the current such functions (which should be
-     possible).
-<li> <code>mpz_and_ui</code> etc might be of use sometimes.  Suggested by
-     Niels Möller.
-<li> <code>mpf_set_str</code> and <code>mpf_inp_str</code> 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.
-<li> <code>GMP_LONG_LONG_LIMB</code> or some such could become a documented
-     feature of gmp.h, so applications could know whether to
-     <code>printf</code> a limb using <code>%lu</code> or <code>%Lu</code>.
-<li> <code>GMP_PRIdMP_LIMB</code> and similar defines following C99
-     &lt;inttypes.h&gt; might be of use to applications printing limbs.  But
-     if <code>GMP_LONG_LONG_LIMB</code> or whatever is added then perhaps this
-     can easily enough be left to applications.
-<li> <code>gmp_printf</code> could accept <code>%b</code> for binary output.
-     It'd be nice if it worked for plain <code>int</code> etc too, not just
-     <code>mpz_t</code> etc.
-<li> <code>gmp_printf</code> in fact could usefully accept an arbitrary base,
-     for both integer and float conversions.  A base either in the format
-     string or as a parameter with <code>*</code> should be allowed.  Maybe
-     <code>&amp;13b</code> (b for base) or something like that.
-<li> <code>gmp_printf</code> could perhaps accept <code>mpq_t</code> for float
-     conversions, eg. <code>"%.4Qf"</code>.  This would be merely for
-     convenience, but still might be useful.  Rounding would be the same as
-     for an <code>mpf_t</code> (ie. currently round-to-nearest, but not
-     actually documented).  Alternately, perhaps a separate
-     <code>mpq_get_str_point</code> or some such might be more use.  Suggested
-     by Pedro Gimeno.
-<li> <code>mpz_rscan0</code> or <code>mpz_revscan0</code> or some such
-     searching towards the low end of an integer might match
-     <code>mpz_scan0</code> nicely.  Likewise for <code>scan1</code>.
-     Suggested by Roberto Bagnara.
-<li> <code>mpz_bit_subset</code> or some such to test whether one integer is a
-     bitwise subset of another might be of use.  Some sort of return value
-     indicating whether it's a proper or non-proper subset would be good and
-     wouldn't cost anything in the implementation.  Suggested by Roberto
-     Bagnara.
-<li> <code>mpf_get_ld</code>, <code>mpf_set_ld</code>: Conversions between
-     <code>mpf_t</code> and <code>long double</code>, suggested by Dan
-     Christensen.  Other <code>long double</code> routines might be desirable
-     too, but <code>mpf</code> would be a start.
-     <br>
-     <code>long double</code> is an ANSI-ism, so everything involving it would
-     need to be suppressed on a K&amp;R compiler.
-     <br>
-     There'd be some work to be done by <code>configure</code> to recognise
-     the format in use, MPFR has a start on this.  Often <code>long
-     double</code> is the same as <code>double</code>, which is easy but
-     pretty pointless.  A single float format detector macro could look at
-     <code>double</code> then <code>long double</code>
-     <br>
-     Sometimes there's a compiler option for the size of a <code>long
-     double</code>, eg. xlc on AIX can use either 64-bit or 128-bit.  It's
-     probably simplest to regard this as a compiler compatibility issue, and
-     leave it to users or sysadmins to ensure application and library code is
-     built the same.
-<li> <code>mpz_sqrt_if_perfect_square</code>: When
-     <code>mpz_perfect_square_p</code> does its tests it calculates a square
-     root and then discards it.  For some applications it might be useful to
-     return that root.  Suggested by Jason Moxham.
-<li> <code>mpz_get_ull</code>, <code>mpz_set_ull</code>,
-     <code>mpz_get_sll</code>, <code>mpz_get_sll</code>: Conversions for
-     <code>long long</code>.  These would aid interoperability, though a
-     mixture of GMP and <code>long long</code> would probably not be too
-     common.  Since <code>long long</code> is not always available (it's in
-     C99 and GCC though), disadvantages of using <code>long long</code> in
-     libgmp.a would be
-     <ul>
-     <li> Library contents vary according to the build compiler.
-     <li> gmp.h would need an ugly <code>#ifdef</code> block to decide if the
-          application compiler could take the <code>long long</code>
-          prototypes.
-     <li> Some sort of <code>LIBGMP_HAS_LONGLONG</code> might be wanted to
-          indicate whether the functions are available.  (Applications using
-          autoconf could probe the library too.)
-     </ul>
-     It'd be possible to defer the need for <code>long long</code> to
-     application compile time, by having something like
-     <code>mpz_set_2ui</code> called with two halves of a <code>long
-     long</code>.  Disadvantages of this would be,
-     <ul>
-     <li> Bigger code in the application, though perhaps not if a <code>long
-          long</code> is normally passed as two halves anyway.
-     <li> <code>mpz_get_ull</code> would be a rather big inline, or would have
-          to be two function calls.
-     <li> <code>mpz_get_sll</code> would be a worse inline, and would put the
-          treatment of <code>-0x10..00</code> into applications (see
-          <code>mpz_get_si</code> correctness above).
-     <li> Although having libgmp.a independent of the build compiler is nice,
-          it sort of sacrifices the capabilities of a good compiler to
-          uniformity with inferior ones.
-     </ul>
-     Plain use of <code>long long</code> is probably the lesser evil, if only
-     because it makes best use of gcc.  In fact perhaps it would suffice to
-     guarantee <code>long long</code> conversions only when using GCC for both
-     application and library.  That would cover free software, and we can
-     worry about selected vendor compilers later.
-     <br>
-     In C++ the situation is probably clearer, we demand fairly recent C++ so
-     <code>long long</code> should be available always.  We'd probably prefer
-     to have the C and C++ the same in respect of <code>long long</code>
-     support, but it would be possible to have it unconditionally in gmpxx.h,
-     by some means or another.
-<li> <code>mpz_strtoz</code> parsing the same as <code>strtol</code>.
-     Suggested by Alexander Kruppa.
-</ul>
-
-
-<h4>Configuration</h4>
-
-<ul>
-<li> Alpha ev7, ev79: Add code to config.guess to detect these.  Believe ev7
-     will be "3-1307" in the current switch, but need to verify that.  (On
-     OSF, current configfsf.guess identifies ev7 using psrinfo, we need to do
-     it ourselves for other systems.)
-<li> Alpha OSF: Libtool (version 1.5) doesn't seem to recognise this system is
-     "pic always" and ends up running gcc twice with the same options.  This
-     is wasteful, but harmless.  Perhaps a newer libtool will be better.
-<li> ARM: <code>umul_ppmm</code> in longlong.h always uses <code>umull</code>,
-     but is that available only for M series chips or some such?  Perhaps it
-     should be configured in some way.
-<li> HPPA: config.guess should recognize 7000, 7100, 7200, and 8x00.
-<li> HPPA: gcc 3.2 introduces a <code>-mschedule=7200</code> etc parameter,
-     which could be driven by an exact hppa cpu type.
-<li> Mips: config.guess should say mipsr3000, mipsr4000, mipsr10000, etc.
-     "hinv -c processor" gives lots of information on Irix.  Standard
-     config.guess appends "el" to indicate endianness, but
-     <code>AC_C_BIGENDIAN</code> seems the best way to handle that for GMP.
-<li> PowerPC: The function descriptor nonsense for AIX is currently driven by
-     <code>*-*-aix*</code>.  It might be more reliable to do some sort of
-     feature test, examining the compiler output perhaps.  It might also be
-     nice to merge the aix.m4 files into powerpc-defs.m4.
-<li> config.m4 is generated only by the configure script, it won't be
-     regenerated by config.status.  Creating it as an <code>AC_OUTPUT</code>
-     would work, but it might upset "make" to have things like <code>L$</code>
-     get into the Makefiles through <code>AC_SUBST</code>.
-     <code>AC_CONFIG_COMMANDS</code> would be the alternative.  With some
-     careful m4 quoting the <code>changequote</code> calls might not be
-     needed, which might free up the order in which things had to be output.
-<li> Automake: Latest automake has a <code>CCAS</code>, <code>CCASFLAGS</code>
-     scheme.  Though we probably wouldn't be using its assembler support we
-     could try to use those variables in compatible ways.
-<li> <code>GMP_LDFLAGS</code> could probably be done with plain
-     <code>LDFLAGS</code> already used by automake for all linking.  But with
-     a bit of luck the next libtool will pass pretty much all
-     <code>CFLAGS</code> through to the compiler when linking, making
-     <code>GMP_LDFLAGS</code> unnecessary.
-<li> mpn/Makeasm.am uses <code>-c</code> and <code>-o</code> together in the
-     .S and .asm rules, but apparently that isn't completely portable (there's
-     an autoconf <code>AC_PROG_CC_C_O</code> test for it).  So far we've not
-     had problems, but perhaps the rules could be rewritten to use "foo.s" as
-     the temporary, or to do a suitable "mv" of the result.  The only danger
-     from using foo.s would be if a compile failed and the temporary foo.s
-     then looked like the primary source.  Hopefully if the
-     <code>SUFFIXES</code> are ordered to have .S and .asm ahead of .s that
-     wouldn't happen.  Might need to check.
-</ul>
-
-
-<h4>Random Numbers</h4>
-<ul>
-<li> <code>_gmp_rand</code> is not particularly fast on the linear
-     congruential algorithm and could stand various improvements.
-     <ul>
-     <li> Make a second seed area within <code>gmp_randstate_t</code> (or
-          <code>_mp_algdata</code> rather) to save some copying.
-     <li> Make a special case for a single limb <code>2exp</code> modulus, to
-          avoid <code>mpn_mul</code> calls.  Perhaps the same for two limbs.
-     <li> Inline the <code>lc</code> code, to avoid a function call and
-          <code>TMP_ALLOC</code> for every chunk.
-     <li> Perhaps the <code>2exp</code> and general LC cases should be split,
-          for clarity (if the general case is retained).
-     </ul>
-<li> <code>gmp_randstate_t</code> used for parameters perhaps should become
-     <code>gmp_randstate_ptr</code> the same as other types.
-<li> Some of the empirical randomness tests could be included in a "make
-     check".  They ought to work everywhere, for a given seed at least.
-</ul>
-
-
-<h4>C++</h4>
-<ul>
-<li> <code>mpz_class(string)</code>, etc: Use the C++ global locale to
-     identify whitespace.
-     <br>
-     <code>mpf_class(string)</code>: Use the C++ global locale decimal point,
-     rather than the C one.
-     <br>
-     Consider making these variant <code>mpz_set_str</code> etc forms
-     available for <code>mpz_t</code> too, not just <code>mpz_class</code>
-     etc.
-<li> <code>mpq_class operator+=</code>: Don't emit an unnecssary
-     <code>mpq_set(q,q)</code> before <code>mpz_addmul</code> etc.
-<li> Put various bits of gmpxx.h into libgmpxx, to avoid excessive inlining.
-     Candidates for this would be,
-     <ul>
-     <li> <code>mpz_class(const char *)</code>, etc: since they're normally
-          not fast anyway, and we can hide the exception <code>throw</code>.
-     <li> <code>mpz_class(string)</code>, etc: to hide the <code>cstr</code>
-          needed to get to the C conversion function.
-     <li> <code>mpz_class string, char*</code> etc constructors: likewise to
-          hide the throws and conversions.
-     <li> <code>mpz_class::get_str</code>, etc: to hide the <code>char*</code>
-          to <code>string</code> conversion and free.  Perhaps
-          <code>mpz_get_str</code> can write directly into a
-          <code>string</code>, to avoid copying.
-          <br>
-          Consider making such <code>string</code> returning variants
-          available for use with plain <code>mpz_t</code> etc too.
-     </ul>
-</ul>
-
-<h4>Miscellaneous</h4>
-<ul>
-<li> <code>mpz_gcdext</code> and <code>mpn_gcdext</code> 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|&lt;|b| and |y|&lt;|a| or something like that, but there's probably
-     two solutions under just those restrictions.
-<li> demos/factorize.c: use <code>mpz_divisible_ui_p</code> rather than
-     <code>mpz_tdiv_qr_ui</code>.  (Of course dividing multiple primes at a
-     time would be better still.)
-<li> The various test programs use quite a bit of the main
-     <code>libgmp</code>.  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
-     <code>libgmp</code> routine is only used for tests once it seems to be
-     good.
-<li> <code>MUL_FFT_THRESHOLD</code> etc: the FFT thresholds should allow a
-     return to a previous k at certain sizes.  This arises basically due to
-     the step effect caused by size multiples effectively used for each k.
-     Looking at a graph makes it fairly clear.
-<li> <code>__gmp_doprnt_mpf</code> does a rather unattractive round-to-nearest
-     on the string returned by <code>mpf_get_str</code>.  Perhaps some variant
-     of <code>mpf_get_str</code> could be made which would better suit.
-</ul>
-
-
-<h4>Aids to Development</h4>
-<ul>
-<li> Add <code>ASSERT</code>s at the start of each user-visible mpz/mpq/mpf
-     function to check the validity of each <code>mp?_t</code> parameter, in
-     particular to check they've been <code>mp?_init</code>ed.  This might
-     catch elementary mistakes in user programs.  Care would need to be taken
-     over <code>MPZ_TMP_INIT</code>ed variables used internally.  If nothing
-     else then consistency checks like size&lt;=alloc, ptr not
-     <code>NULL</code> and ptr+size not wrapping around the address space,
-     would be possible.  A more sophisticated scheme could track
-     <code>_mp_d</code> pointers and ensure only a valid one is used.  Such a
-     scheme probably wouldn't be reentrant, not without some help from the
-     system.
-<li> tune/time.c could try to determine at runtime whether
-     <code>getrusage</code> and <code>gettimeofday</code> are reliable.
-     Currently we pretend in configure that the dodgy m68k netbsd 1.4.1
-     <code>getrusage</code> doesn't exist.  If a test might take a long time
-     to run then perhaps cache the result in a file somewhere.
-<li> tune/time.c could choose the default precision based on the
-     <code>speed_unittime</code> determined, independent of the method in use.
-<li> Cray vector systems: CPU frequency could be determined from
-     <code>sysconf(_SC_CLK_TCK)</code>, since it seems to be clock cycle
-     based.  Is this true for all Cray systems?  Would like some documentation
-     or something to confirm.
-</ul>
-
-
-<h4>Documentation</h4>
-<ul>
-<li> <code>mpz_inp_str</code> (etc) doesn't say when it stops reading digits.
-<li> <code>mpn_get_str</code> isn't terribly clear about how many digits it
-     produces.  It'd probably be possible to say at most one leading zero,
-     which is what both it and <code>mpz_get_str</code> currently do.  But
-     want to be careful not to bind ourselves to something that might not suit
-     another implementation.
-<li> <code>va_arg</code> doesn't do the right thing with <code>mpz_t</code>
-     etc directly, but instead needs a pointer type like <code>MP_INT*</code>.
-     It'd be good to show how to do this, but we'd either need to document
-     <code>mpz_ptr</code> and friends, or perhaps fallback on something
-     slightly nasty with <code>void*</code>.
-</ul>
-
-
-<h4>Bright Ideas</h4>
-
-<p> The following may or may not be feasible, and aren't likely to get done in the
-near future, but are at least worth thinking about.
-
-<ul>
-<li> Reorganize longlong.h so that we can inline the operations even for the
-     system compiler.  When there is no such compiler feature, make calls to
-     stub functions.  Write such stub functions for as many machines as
-     possible.
-<li> longlong.h could declare when it's using, or would like to use,
-     <code>mpn_umul_ppmm</code>, and the corresponding umul.asm file could be
-     included in libgmp only in that case, the same as is effectively done for
-     <code>__clz_tab</code>.  Likewise udiv.asm and perhaps cntlz.asm.  This
-     would only be a very small space saving, so perhaps not worth the
-     complexity.
-<li> longlong.h could be built at configure time by concatenating or
-     #including fragments from each directory in the mpn path.  This would
-     select CPU specific macros the same way as CPU specific assembler code.
-     Code used would no longer depend on cpp predefines, and the current
-     nested conditionals could be flattened out.
-<li> <code>mpz_get_si</code> 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.
-<li> <code>mpz_init_set*</code> and <code>mpz_realloc</code> 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 <code>mpz_t</code> grows a bit more.
-     This could only be an option, since it'd badly bloat memory usage in
-     applications using many small values.
-<li> <code>mpq</code> 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.
-<li> <code>count_trailing_zeros</code> is used on more or less uniformly
-     distributed numbers in a couple of places.  For some CPUs
-     <code>count_trailing_zeros</code> is slow and it's probably worth handling
-     the frequently occurring 0 to 2 trailing zeros cases specially.
-<li> <code>mpf_t</code> 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 <code>mpz_set_f</code> and <code>mpf_cmp_ui</code> depend on
-     exp==0, maybe elsewhere too.
-<li> <code>__gmp_allocate_func</code>: Could use GCC <code>__attribute__
-     ((malloc))</code> 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.
-<li> <code>mpz_add_ui</code> contains two <code>__GMPN_COPY</code>s, one from
-     <code>mpn_add_1</code> and one from <code>mpn_sub_1</code>.  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.
-</ul>
-
-
-<h4>Old and Obsolete Stuff</h4>
-
-<p> The following tasks apply to chips or systems that are old and/or obsolete.
-It's unlikely anything will be done about them unless anyone is actively using
-them.
-
-<ul>
-<li> Sparc32: The integer based udiv_nfp.asm used to be selected by
-     <code>configure --nfp</code> but that option is gone now that autoconf is
-     used.  The file could go somewhere suitable in the mpn search if any
-     chips might benefit from it, though it's possible we don't currently
-     differentiate enough exact cpu types to do this properly.
-<li> VAX D and G format <code>double</code> floats are straightforward and
-     could perhaps be handled directly in <code>__gmp_extract_double</code>
-     and maybe in <code>mpn_get_d</code>, rather than falling back on the
-     generic code.  (Both formats are detected by <code>configure</code>.)
-</ul>
-
-
-<hr>
-
-</body>
-</html>
-
-<!--
-Local variables:
-eval: (add-hook 'write-file-hooks 'time-stamp)
-time-stamp-start: "This file current as of "
-time-stamp-format: "%:d %3b %:y"
-time-stamp-end: "\\."
-time-stamp-line-limit: 50
-End:
--->
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html>
+<head>
+  <title>GMP Itemized Development Tasks</title>
+  <link rel="shortcut icon" href="favicon.ico">
+  <link rel="stylesheet" href="gmp.css">
+  <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
+</head>
+
+<center>
+  <h1>
+    GMP Itemized Development Tasks
+  </h1>
+</center>
+
+<font size=-1>
+Copyright 2000, 2001, 2002, 2003, 2004, 2006 Free Software Foundation, Inc. <br><br>
+This file is part of the GNU MP Library. <br><br>
+The GNU MP Library is free software; you can redistribute it and/or modify
+it under the terms of the GNU Lesser General Public License as published
+by the Free Software Foundation; either version 2.1 of the License, or (at
+your option) any later version. <br><br>
+The GNU MP Library is distributed in the hope that it will be useful, but
+WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU Lesser General Public
+License for more details. <br><br>
+You should have received a copy of the GNU Lesser General Public License
+along with the GNU MP Library; see the file COPYING.LIB.  If not, write to
+the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+MA 02110-1301, USA.
+</font>
+
+<hr>
+<!-- NB. timestamp updated automatically by emacs -->
+  This file current as of 21 Apr 2006.  
+  Please send comments to
+  <a href="http://groups.google.co.uk/group/mpir-devel/">http://groups.google.co.uk/group/mpir-devel/</a>.
+
+<p> These are itemized GMP development tasks.  Not all the tasks
+    listed here are suitable for volunteers, but many of them are.
+    Please see the <a href="projects.html">projects file</a> for more
+    sizeable projects.
+
+<h4>Correctness and Completeness</h4>
+<ul>
+<li> <code>_LONG_LONG_LIMB</code> in gmp.h is not namespace clean.  Reported
+     by Patrick Pelissier.
+     <br>
+     We sort of mentioned <code>_LONG_LONG_LIMB</code> in past releases, so
+     need to be careful about changing it.  It used to be a define
+     applications had to set for long long limb systems, but that in
+     particular is no longer relevant now that it's established automatically.
+<li> The various reuse.c tests need to force reallocation by calling
+     <code>_mpz_realloc</code> with a small (1 limb) size.
+<li> One reuse case is missing from mpX/tests/reuse.c:
+     <code>mpz_XXX(a,a,a)</code>.
+<li> When printing <code>mpf_t</code> numbers with exponents &gt;2^53 on
+     machines with 64-bit <code>mp_exp_t</code>, the precision of
+     <code>__mp_bases[base].chars_per_bit_exactly</code> is insufficient and
+     <code>mpf_get_str</code> 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.
+<li> Make the string reading functions allow the `0x' prefix when the base is
+     explicitly 16.  They currently only allow that prefix when the base is
+     unspecified (zero).
+<li> <code>mpf_eq</code> 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 <code>mpf_sub</code> for this
+     situation; put similar code in <code>mpf_eq</code>.  [In progress.]
+<li> <code>mpf_eq</code> doesn't implement what gmp.texi specifies.  It should
+     not use just whole limbs, but partial limbs.  [In progress.]
+<li> <code>mpf_set_str</code> doesn't validate it's exponent, for instance
+     garbage 123.456eX789X is accepted (and an exponent 0 used), and overflow
+     of a <code>long</code> is not detected.
+<li> <code>mpf_add</code> 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.
+<li> Windows DLLs: tests/mpz/reuse.c and tests/mpf/reuse.c initialize global
+     variables with pointers to <code>mpz_add</code> 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.
+<li> <code>mpz_pow_ui</code>: Detect when the result would be more memory than
+     a <code>size_t</code> can represent and raise some suitable exception,
+     probably an alloc call asking for <code>SIZE_T_MAX</code>, and if that
+     somehow succeeds then an <code>abort</code>.  Various size overflows of
+     this kind are not handled gracefully, probably resulting in segvs.
+     <br>
+     In <code>mpz_n_pow_ui</code>, detect when the count of low zero bits
+     exceeds an <code>unsigned long</code>.  There's a (small) chance of this
+     happening but still having enough memory to represent the value.
+     Reported by Winfried Dreckmann in for instance <code>mpz_ui_pow_ui (x,
+     4UL, 1431655766UL)</code>.
+<li> <code>mpf</code>: Detect exponent overflow and raise some exception.
+     It'd be nice to allow the full <code>mp_exp_t</code> range since that's
+     how it's been in the past, but maybe dropping one bit would make it
+     easier to test if e1+e2 goes out of bounds.
+</ul>
+
+
+
+<h4>Machine Independent Optimization</h4>
+<ul>
+<li> <code>mpf_cmp</code>: For better cache locality, don't test for low zero
+     limbs until the high limbs fail to give an ordering.  Reduce code size by
+     turning the three <code>mpn_cmp</code>'s into a single loop stopping when
+     the end of one operand is reached (and then looking for a non-zero in the
+     rest of the other).
+<li> <code>mpf_mul_2exp</code>, <code>mpf_div_2exp</code>: The use of
+     <code>mpn_lshift</code> for any size&lt;=prec means repeated
+     <code>mul_2exp</code> and <code>div_2exp</code> calls accumulate low zero
+     limbs until size==prec+1 is reached.  Those zeros will slow down
+     subsequent operations, especially if the value is otherwise only small.
+     If low bits of the low limb are zero, use <code>mpn_rshift</code> so as
+     to not increase the size.
+<li> <code>mpn_dc_sqrtrem</code>: Don't use <code>mpn_addmul_1</code> with
+     multiplier==2, instead either <code>mpn_addlsh1_n</code> when available,
+     or <code>mpn_lshift</code>+<code>mpn_add_n</code> if not.
+<li> <code>mpn_dc_sqrtrem</code>, <code>mpn_sqrtrem2</code>: Don't use
+     <code>mpn_add_1</code> and <code>mpn_sub_1</code> for 1 limb operations,
+     instead <code>ADDC_LIMB</code> and <code>SUBC_LIMB</code>.
+<li> <code>mpn_sqrtrem2</code>: Use plain variables for <code>sp[0]</code> and
+     <code>rp[0]</code> calculations, so the compiler needn't worry about
+     aliasing between <code>sp</code> and <code>rp</code>.
+<li> <code>mpn_sqrtrem</code>: Some work can be saved in the last step when
+     the remainder is not required, as noted in Paul's paper.
+<li> <code>mpq_add</code>, <code>mpq_add</code>: The division "op1.den / gcd"
+     is done twice, where of course only once is necessary.  Reported by Larry
+     Lambe.
+<li> <code>mpq_add</code>, <code>mpq_sub</code>: The gcd fits a single limb
+     with high probability and in this case <code>modlimb_invert</code> could
+     be used to calculate the inverse just once for the two exact divisions
+     "op1.den / gcd" and "op2.den / gcd", rather than letting
+     <code>mpn_divexact_1</code> do it each time.  This would require a new
+     <code>mpn_preinv_divexact_1</code> interface.  Not sure if it'd be worth
+     the trouble.
+<li> <code>mpq_add</code>, <code>mpq_sub</code>: The use of
+     <code>mpz_mul(x,y,x)</code> causes temp allocation or copying in
+     <code>mpz_mul</code> which can probably be avoided.  A rewrite using
+     <code>mpn</code> might be best.
+<li> <code>mpn_gcdext</code>: Don't test <code>count_leading_zeros</code> for
+     zero, instead check the high bit of the operand and avoid invoking
+     <code>count_leading_zeros</code>.  This is an optimization on all
+     machines, and significant on machines with slow
+     <code>count_leading_zeros</code>, though it's possible an already
+     normalized operand might not be encountered very often.
+<li> Rewrite <code>umul_ppmm</code> to use floating-point for generating the
+     most significant limb (if <code>BITS_PER_MP_LIMB</code> &lt= 52 bits).
+     (Peter Montgomery has some ideas on this subject.)
+<li> Improve the default <code>umul_ppmm</code> code in longlong.h: Add partial
+     products with fewer operations.
+<li> Consider inlining <code>mpz_set_ui</code>.  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 <code>mpz_t</code>,
+     preventing the "lazy" allocation scheme below.
+<li> Consider inlining <code>mpz_[cft]div_ui</code> and maybe
+     <code>mpz_[cft]div_r_ui</code>.  A <code>__gmp_divide_by_zero</code>
+     would be needed for the divide by zero test, unless that could be left to
+     <code>mpn_mod_1</code> (not sure currently whether all the risc chips
+     provoke the right exception there if using mul-by-inverse).
+<li> Consider inlining: <code>mpz_fits_s*_p</code>.  The setups for
+     <code>LONG_MAX</code> etc would need to go into gmp.h, and on Cray it
+     might, unfortunately, be necessary to forcibly include &lt;limits.h&gt;
+     since there's no apparent way to get <code>SHRT_MAX</code> with an
+     expression (since <code>short</code> and <code>unsigned short</code> can
+     be different sizes).
+<li> <code>mpz_powm</code> and <code>mpz_powm_ui</code> 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.
+<li> <code>mpz_powm</code> and <code>mpz_powm_ui</code> want better
+     algorithm selection, and the latter should use REDC.  Both could
+     change to use an <code>mpn_powm</code> and <code>mpn_redc</code>.
+<li> <code>mpz_powm</code> REDC should do multiplications by <code>g[]</code>
+     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.
+<li> <code>mpz_powm</code> 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.
+<li> <code>mpn_gcd</code> might be able to be sped up on small to
+     moderate sizes by improving <code>find_a</code>, possibly just by
+     providing an alternate implementation for CPUs with slowish
+     <code>count_leading_zeros</code>.
+<li> Toom3 could use a low to high cache localized evaluate and interpolate.
+     The necessary <code>mpn_divexact_by3c</code> exists.
+<li> <code>mpf_set_str</code> 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.
+<li> <code>mpz_and</code>, <code>mpz_ior</code> and <code>mpz_xor</code> should
+     use <code>mpn_and_n</code> 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 <code>mpz</code>
+     routines?
+<li> <code>mpf_add</code>: 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).
+<li> <code>mpf_add</code>: 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 <code>MPN_COPY_INCR</code> will be done to
+     reduce prec+1 limbs to prec.
+<li> <code>mpf_div_ui</code>: Instead of padding with low zeros, call
+     <code>mpn_divrem_1</code> asking for fractional quotient limbs.
+<li> <code>mpf_div_ui</code>: Eliminate <code>TMP_ALLOC</code>.  When r!=u
+     there's no overlap and the division can be called on those operands.
+     When r==u and is prec+1 limbs, then it's an in-place division.  If r==u
+     and not prec+1 limbs, then move the available limbs up to prec+1 and do
+     an in-place there.
+<li> <code>mpf_div_ui</code>: Whether the high quotient limb is zero can be
+     determined by testing the dividend for high&lt;divisor.  When non-zero, the
+     divison can be done on prec dividend limbs instead of prec+1.  The result
+     size is also known before the division, so that can be a tail call (once
+     the <code>TMP_ALLOC</code> is eliminated).
+<li> <code>mpn_divrem_2</code> 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
+     <code>mpn_tdiv_qr</code>.
+<li> <code>mpf_sqrt</code>: If r!=u, and if u doesn't need to be padded with
+     zeros, then there's no need for the tp temporary.
+<li> <code>mpq_cmp_ui</code> could form the <code>num1*den2</code> and
+     <code>num2*den1</code> 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.
+<li> <code>mpq_cmp</code> 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.
+<li> <code>mpn_add_1</code>, <code>mpn_sub_1</code>, <code>mpn_add</code>,
+     <code>mpn_sub</code>: Internally use <code>__GMPN_ADD_1</code> etc
+     instead of the functions, so they get inlined on all compilers, not just
+     gcc and others with <code>inline</code> recognised in gmp.h.
+     <code>__GMPN_ADD_1</code> etc are meant mostly to support application
+     inline <code>mpn_add_1</code> 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.
+<li> <code>__gmp_extract_double</code> on 64-bit systems could use just one
+     bitfield for the mantissa extraction, not two, when endianness permits.
+     Might depend on the compiler allowing <code>long long</code> bit fields
+     when that's the only actual 64-bit type.
+<li> tal-notreent.c could keep a block of memory permanently allocated.
+     Currently the last nested <code>TMP_FREE</code> releases all memory, so
+     there's an allocate and free every time a top-level function using
+     <code>TMP</code> is called.  Would need
+     <code>mp_set_memory_functions</code> to tell tal-notreent.c to release
+     any cached memory when changing allocation functions though.
+<li> <code>__gmp_tmp_alloc</code> 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 <code>__gmp_tmp_increase</code> would be needed.  The requirement that
+     <code>TMP_ALLOC</code> is an expression might make the implementation a
+     bit ugly and/or a bit sub-optimal.
+<pre>
+#define TMP_ALLOC(n)
+  ((ROUND_UP(n) &gt; current-&gt;end - current-&gt;point ?
+     __gmp_tmp_increase (ROUND_UP (n)) : 0),
+     current-&gt;point += ROUND_UP (n),
+     current-&gt;point - ROUND_UP (n))
+</pre>
+<li> <code>__mp_bases</code> has a lot of data for bases which are pretty much
+     never used.  Perhaps the table should just go up to base 16, and have
+     code to generate data above that, if and when required.  Naturally this
+     assumes the code would be smaller than the data saved.
+<li> <code>__mp_bases</code> field <code>big_base_inverted</code> is only used
+     if <code>USE_PREINV_DIVREM_1</code> is true, and could be omitted
+     otherwise, to save space.
+<li> <code>mpz_get_str</code>, <code>mtox</code>: For power-of-2 bases, which
+     are of course fast, it seems a little silly to make a second pass over
+     the <code>mpn_get_str</code> output to convert to ASCII.  Perhaps combine
+     that with the bit extractions.
+<li> <code>mpz_gcdext</code>: If the caller requests only the S cofactor (of
+     A), and A&lt;B, then the code ends up generating the cofactor T (of B) and
+     deriving S from that.  Perhaps it'd be possible to arrange to get S in
+     the first place by calling <code>mpn_gcdext</code> with A+B,B.  This
+     might only be an advantage if A and B are about the same size.
+<li> <code>mpz_n_pow_ui</code> does a good job with small bases and stripping
+     powers of 2, but it's perhaps a bit too complicated for what it gains.
+     The simpler <code>mpn_pow_1</code> is a little faster on small exponents.
+     (Note some of the ugliness in <code>mpz_n_pow_ui</code> is due to
+     supporting <code>mpn_mul_2</code>.)
+     <br>
+     Perhaps the stripping of 2s in <code>mpz_n_pow_ui</code> should be
+     confined to single limb operands for simplicity and since that's where
+     the greatest gain would be.
+     <br>
+     Ideally <code>mpn_pow_1</code> and <code>mpz_n_pow_ui</code> would be
+     merged.  The reason <code>mpz_n_pow_ui</code> writes to an
+     <code>mpz_t</code> is that its callers leave it to make a good estimate
+     of the result size.  Callers of <code>mpn_pow_1</code> already know the
+     size by separate means (<code>mp_bases</code>).
+<li> <code>mpz_invert</code> should call <code>mpn_gcdext</code> directly.
+</ul>
+
+
+<h4>Machine Dependent Optimization</h4>
+<ul>
+<li> <code>invert_limb</code> on various processors might benefit from the
+     little Newton iteration done for alpha and ia64.
+<li> Alpha 21264: <code>mpn_addlsh1_n</code> could be implemented with
+     <code>mpn_addmul_1</code>, since that code at 3.5 is a touch faster than
+     a separate <code>lshift</code> and <code>add_n</code> at
+     1.75+2.125=3.875.  Or very likely some specific <code>addlsh1_n</code>
+     code could beat both.
+<li> Alpha 21264: Improve feed-in code for <code>mpn_mul_1</code>,
+     <code>mpn_addmul_1</code>, and <code>mpn_submul_1</code>.
+<li> Alpha 21164: Rewrite <code>mpn_mul_1</code>, <code>mpn_addmul_1</code>,
+     and <code>mpn_submul_1</code> 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.
+<li> Alpha: GCC 3.4 will introduce <code>__builtin_ctzl</code>,
+     <code>__builtin_clzl</code> and <code>__builtin_popcountl</code> using
+     the corresponding CIX <code>ct</code> instructions, and
+     <code>__builtin_alpha_cmpbge</code>.  These should give GCC more
+     information about sheduling etc than the <code>asm</code> blocks
+     currently used in longlong.h and gmp-impl.h.
+<li> Alpha Unicos: Apparently there's no <code>alloca</code> on this system,
+     making <code>configure</code> choose the slower
+     <code>malloc-reentrant</code> allocation method.  Is there a better way?
+     Maybe variable-length arrays per notes below.
+<li> Alpha Unicos 21164, 21264: <code>.align</code> is not used since it pads
+     with garbage.  Does the code get the intended slotting required for the
+     claimed speeds?  <code>.align</code> at the start of a function would
+     presumably be safe no matter how it pads.
+<li> ARM V5: <code>count_leading_zeros</code> can use the <code>clz</code>
+     instruction.  For GCC 3.4 and up, do this via <code>__builtin_clzl</code>
+     since then gcc knows it's "predicable".
+<li> Itanium: GCC 3.4 introduces <code>__builtin_popcount</code> which can be
+     used instead of an <code>asm</code> block.  The builtin should give gcc
+     more opportunities for scheduling, bundling and predication.
+     <code>__builtin_ctz</code> similarly (it just uses popcount as per
+     current longlong.h).
+<li> UltraSPARC/64: Optimize <code>mpn_mul_1</code>, <code>mpn_addmul_1</code>,
+     for s2 &lt; 2^32 (or perhaps for any zero 16-bit s2 chunk).  Not sure how
+     much this can improve the speed, though, since the symmetry that we rely
+     on is lost.  Perhaps we can just gain cycles when s2 &lt; 2^16, or more
+     accurately, when two 16-bit s2 chunks which are 16 bits apart are zero.
+<li> UltraSPARC/64: Write native <code>mpn_submul_1</code>, analogous to
+     <code>mpn_addmul_1</code>.
+<li> UltraSPARC/64: Write <code>umul_ppmm</code>.  Using four
+     "<code>mulx</code>"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 "<code>mulx</code>"s.
+<li> UltraSPARC/32: Rewrite <code>mpn_lshift</code>, <code>mpn_rshift</code>.
+     Will give 2 cycles/limb.  Trivial modifications of mpn/sparc64 should do.
+<li> UltraSPARC/32: Write special mpn_Xmul_1 loops for s2 &lt; 2^16.
+<li> UltraSPARC/32: Use <code>mulx</code> for <code>umul_ppmm</code> if
+     possible (see commented out code in longlong.h).  This is unlikely to
+     save more than a couple of cycles, so perhaps isn't worth bothering with.
+<li> UltraSPARC/32: On Solaris gcc doesn't give us <code>__sparc_v9__</code>
+     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 <code>mulx</code> for multiplying is commented out.)
+<li> UltraSPARC/32: <code>mpn_divexact_1</code> and
+     <code>mpn_modexact_1c_odd</code> can use a 64-bit inverse and take
+     64-bits at a time from the dividend, as per the 32-bit divisor case in
+     mpn/sparc64/mode1o.c.  This must be done in assembler, since the full
+     64-bit registers (<code>%gN</code>) are not available from C.
+<li> UltraSPARC/32: <code>mpn_divexact_by3c</code> can work 64-bits at a time
+     using <code>mulx</code>, in assembler.  This would be the same as for
+     sparc64.
+<li> UltraSPARC: <code>modlimb_invert</code> might save a few cycles from
+     masking down to just the useful bits at each point in the calculation,
+     since <code>mulx</code> speed depends on the highest bit set.  Either
+     explicit masks or small types like <code>short</code> and
+     <code>int</code> ought to work.
+<li> Sparc64 HAL R1 <code>popc</code>: This chip reputedly implements
+     <code>popc</code> properly (see gcc sparc.md).  Would need to recognise
+     it as <code>sparchalr1</code> or something in configure / config.sub /
+     config.guess.  <code>popc_limb</code> in gmp-impl.h could use this (per
+     commented out code).  <code>count_trailing_zeros</code> could use it too.
+<li> PA64: Improve <code>mpn_addmul_1</code>, <code>mpn_submul_1</code>, and
+     <code>mpn_mul_1</code>.  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 &lt; 2^32;
+     it should be possible to make them run at about 5 cycles/limb.
+<li> PPC601: See which of the power or powerpc32 code runs better.  Currently
+     the powerpc32 is used, but only because it's the default for
+     <code>powerpc*</code>.
+<li> PPC630: Rewrite <code>mpn_addmul_1</code>, <code>mpn_submul_1</code>, and
+     <code>mpn_mul_1</code>.  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).
+<li> PPC630: <code>mpn_rshift</code> could do the same sort of unrolled loop
+     as <code>mpn_lshift</code>.  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.
+<li> Implement <code>mpn_mul_basecase</code> and <code>mpn_sqr_basecase</code>
+     for important machines.  Helping the generic sqr_basecase.c with an
+     <code>mpn_sqr_diagonal</code> might be enough for some of the RISCs.
+<li> POWER2/POWER2SC: Schedule <code>mpn_lshift</code>/<code>mpn_rshift</code>.
+     Will bring time from 1.75 to 1.25 cycles/limb.
+<li> X86: Optimize non-MMX <code>mpn_lshift</code> for shifts by 1.  (See
+     Pentium code.)
+<li> X86: Good authority has it that in the past an inline <code>rep
+     movs</code> would upset GCC register allocation for the whole function.
+     Is this still true in GCC 3?  It uses <code>rep movs</code> itself for
+     <code>__builtin_memcpy</code>.  Examine the code for some simple and
+     complex functions to find out.  Inlining <code>rep movs</code> would be
+     desirable, it'd be both smaller and faster.
+<li> Pentium P54: <code>mpn_lshift</code> and <code>mpn_rshift</code> can come
+     down from 6.0 c/l to 5.5 or 5.375 by paying attention to pairing after
+     <code>shrdl</code> and <code>shldl</code>, see mpn/x86/pentium/README.
+<li> Pentium P55 MMX: <code>mpn_lshift</code> and <code>mpn_rshift</code>
+     might benefit from some destination prefetching.
+<li> PentiumPro: <code>mpn_divrem_1</code> might be able to use a
+     mul-by-inverse, hoping for maybe 30 c/l.
+<li> K7: <code>mpn_lshift</code> and <code>mpn_rshift</code> 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.
+<li> PPC32: Try using fewer registers in the current <code>mpn_lshift</code>.
+     The pipeline is now extremely deep, perhaps unnecessarily deep.
+<li> Fujitsu VPP: Vectorize main functions, perhaps in assembly language.
+<li> Fujitsu VPP: Write <code>mpn_mul_basecase</code> and
+     <code>mpn_sqr_basecase</code>.  This should use a "vertical multiplication
+     method", to avoid carry propagation.  splitting one of the operands in
+     11-bit chunks.
+<li> Pentium: <code>mpn_lshift</code> by 31 should use the special rshift
+     by 1 code, and vice versa <code>mpn_rshift</code> 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
+     <code>mpn_rshift</code> already provided.
+<li> Cray T3E: Experiment with optimization options.  In particular,
+     -hpipeline3 seems promising.  We should at least up -O to -O2 or -O3.
+<li> Cray: <code>mpn_com_n</code> and <code>mpn_and_n</code> etc very probably
+     wants a pragma like <code>MPN_COPY_INCR</code>.
+<li> Cray vector systems: <code>mpn_lshift</code>, <code>mpn_rshift</code>,
+     <code>mpn_popcount</code> and <code>mpn_hamdist</code> are nice and small
+     and could be inlined to avoid function calls.
+<li> Cray: Variable length arrays seem to be faster than the tal-notreent.c
+     scheme.  Not sure why, maybe they merely give the compiler more
+     information about aliasing (or the lack thereof).  Would like to modify
+     <code>TMP_ALLOC</code> 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
+     <code>alloca</code>.
+<li> Cray: <code>mpn_get_str</code> on power-of-2 bases ought to vectorize.
+     Does it?  <code>bits_per_digit</code> and the inner loop over bits in a
+     limb might prevent it.  Perhaps special cases for binary, octal and hex
+     would be worthwhile (very possibly for all processors too).
+<li> S390: <code>BSWAP_LIMB_FETCH</code> looks like it could be done with
+     <code>lrvg</code>, as per glibc sysdeps/s390/s390-64/bits/byteswap.h.
+     This is only for 64-bit mode or something is it, since 32-bit mode has
+     other code?  Also, is it worth using for <code>BSWAP_LIMB</code> too, or
+     would that mean a store and re-fetch?  Presumably that's what comes out
+     in glibc.
+<li> Improve <code>count_leading_zeros</code> for 64-bit machines:
+  <pre>
+	   if ((x &gt&gt 32) == 0) { x &lt&lt= 32; cnt += 32; }
+	   if ((x &gt&gt 48) == 0) { x &lt&lt= 16; cnt += 16; }
+	   ... </pre>
+<li> IRIX 6 MIPSpro compiler has an <code>__inline</code> which could perhaps
+     be used in <code>__GMP_EXTERN_INLINE</code>.  What would be the right way
+     to identify suitable versions of that compiler?
+<li> IRIX <code>cc</code> is rumoured to have an <code>_int_mult_upper</code>
+     (in <code>&lt;intrinsics.h&gt;</code> like Cray), but it didn't seem to
+     exist on some IRIX 6.5 systems tried.  If it does actually exist
+     somewhere it would very likely be an improvement over a function call to
+     umul.asm.
+<li> <code>mpn_get_str</code> final divisions by the base with
+     <code>udiv_qrnd_unnorm</code> could use some sort of multiply-by-inverse
+     on suitable machines.  This ends up happening for decimal by presenting
+     the compiler with a run-time constant, but the same for other bases would
+     be good.  Perhaps use could be made of the fact base&lt;256.
+<li> <code>mpn_umul_ppmm</code>, <code>mpn_udiv_qrnnd</code>: Return a
+     structure like <code>div_t</code> to avoid going through memory, in
+     particular helping RISCs that don't do store-to-load forwarding.  Clearly
+     this is only possible if the ABI returns a structure of two
+     <code>mp_limb_t</code>s in registers.
+     <br>
+     On PowerPC, structures are returned in memory on AIX and Darwin.  In SVR4
+     they're returned in registers, except that draft SVR4 had said memory, so
+     it'd be prudent to check which is done.  We can jam the compiler into the
+     right mode if we know how, since all this is purely internal to libgmp.
+     (gcc has an option, though of course gcc doesn't matter since we use
+     inline asm there.)
+</ul>
+
+<h4>New Functionality</h4>
+<ul>
+<li> Maybe add <code>mpz_crr</code> (Chinese Remainder Reconstruction).
+<li> Let `0b' and `0B' mean binary input everywhere.
+<li> <code>mpz_init</code> and <code>mpq_init</code> could do lazy allocation.
+     Set <code>ALLOC(var)</code> to 0 to indicate nothing allocated, and let
+     <code>_mpz_realloc</code> do the initial alloc.  Set
+     <code>z-&gt;_mp_d</code> to a dummy that <code>mpz_get_ui</code> and
+     similar can unconditionally fetch from.  Niels Möller has had a go at
+     this.
+     <br>
+     The advantages of the lazy scheme would be:
+     <ul>
+     <li> Initial allocate would be the size required for the first value
+          stored, rather than getting 1 limb in <code>mpz_init</code> and then
+          more or less immediately reallocating.
+     <li> <code>mpz_init</code> would only store magic values in the
+          <code>mpz_t</code> fields, and could be inlined.
+     <li> A fixed initializer could even be used by applications, like
+          <code>mpz_t z = MPZ_INITIALIZER;</code>, which might be convenient
+          for globals.
+     </ul>
+     The advantages of the current scheme are:
+     <ul>
+     <li> <code>mpz_set_ui</code> and other similar routines needn't check the
+          size allocated and can just store unconditionally.
+     <li> <code>mpz_set_ui</code> and perhaps others like
+          <code>mpz_tdiv_r_ui</code> and a prospective
+          <code>mpz_set_ull</code> could be inlined.
+     </ul>
+<li> Add <code>mpf_out_raw</code> and <code>mpf_inp_raw</code>.  Make sure
+     format is portable between 32-bit and 64-bit machines, and between
+     little-endian and big-endian machines.  A format which MPFR can use too
+     would be good.
+<li> <code>mpn_and_n</code> ... <code>mpn_copyd</code>: 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.
+<li> <code>mpz_set_str</code> etc variants taking string lengths rather than
+     null-terminators.
+<li> <code>mpz_andn</code>, <code>mpz_iorn</code>, <code>mpz_nand</code>,
+     <code>mpz_nior</code>, <code>mpz_xnor</code> might be useful additions,
+     if they could share code with the current such functions (which should be
+     possible).
+<li> <code>mpz_and_ui</code> etc might be of use sometimes.  Suggested by
+     Niels Möller.
+<li> <code>mpf_set_str</code> and <code>mpf_inp_str</code> 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.
+<li> <code>GMP_LONG_LONG_LIMB</code> or some such could become a documented
+     feature of gmp.h, so applications could know whether to
+     <code>printf</code> a limb using <code>%lu</code> or <code>%Lu</code>.
+<li> <code>GMP_PRIdMP_LIMB</code> and similar defines following C99
+     &lt;inttypes.h&gt; might be of use to applications printing limbs.  But
+     if <code>GMP_LONG_LONG_LIMB</code> or whatever is added then perhaps this
+     can easily enough be left to applications.
+<li> <code>gmp_printf</code> could accept <code>%b</code> for binary output.
+     It'd be nice if it worked for plain <code>int</code> etc too, not just
+     <code>mpz_t</code> etc.
+<li> <code>gmp_printf</code> in fact could usefully accept an arbitrary base,
+     for both integer and float conversions.  A base either in the format
+     string or as a parameter with <code>*</code> should be allowed.  Maybe
+     <code>&amp;13b</code> (b for base) or something like that.
+<li> <code>gmp_printf</code> could perhaps accept <code>mpq_t</code> for float
+     conversions, eg. <code>"%.4Qf"</code>.  This would be merely for
+     convenience, but still might be useful.  Rounding would be the same as
+     for an <code>mpf_t</code> (ie. currently round-to-nearest, but not
+     actually documented).  Alternately, perhaps a separate
+     <code>mpq_get_str_point</code> or some such might be more use.  Suggested
+     by Pedro Gimeno.
+<li> <code>mpz_rscan0</code> or <code>mpz_revscan0</code> or some such
+     searching towards the low end of an integer might match
+     <code>mpz_scan0</code> nicely.  Likewise for <code>scan1</code>.
+     Suggested by Roberto Bagnara.
+<li> <code>mpz_bit_subset</code> or some such to test whether one integer is a
+     bitwise subset of another might be of use.  Some sort of return value
+     indicating whether it's a proper or non-proper subset would be good and
+     wouldn't cost anything in the implementation.  Suggested by Roberto
+     Bagnara.
+<li> <code>mpf_get_ld</code>, <code>mpf_set_ld</code>: Conversions between
+     <code>mpf_t</code> and <code>long double</code>, suggested by Dan
+     Christensen.  Other <code>long double</code> routines might be desirable
+     too, but <code>mpf</code> would be a start.
+     <br>
+     <code>long double</code> is an ANSI-ism, so everything involving it would
+     need to be suppressed on a K&amp;R compiler.
+     <br>
+     There'd be some work to be done by <code>configure</code> to recognise
+     the format in use, MPFR has a start on this.  Often <code>long
+     double</code> is the same as <code>double</code>, which is easy but
+     pretty pointless.  A single float format detector macro could look at
+     <code>double</code> then <code>long double</code>
+     <br>
+     Sometimes there's a compiler option for the size of a <code>long
+     double</code>, eg. xlc on AIX can use either 64-bit or 128-bit.  It's
+     probably simplest to regard this as a compiler compatibility issue, and
+     leave it to users or sysadmins to ensure application and library code is
+     built the same.
+<li> <code>mpz_sqrt_if_perfect_square</code>: When
+     <code>mpz_perfect_square_p</code> does its tests it calculates a square
+     root and then discards it.  For some applications it might be useful to
+     return that root.  Suggested by Jason Moxham.
+<li> <code>mpz_get_ull</code>, <code>mpz_set_ull</code>,
+     <code>mpz_get_sll</code>, <code>mpz_get_sll</code>: Conversions for
+     <code>long long</code>.  These would aid interoperability, though a
+     mixture of GMP and <code>long long</code> would probably not be too
+     common.  Since <code>long long</code> is not always available (it's in
+     C99 and GCC though), disadvantages of using <code>long long</code> in
+     libgmp.a would be
+     <ul>
+     <li> Library contents vary according to the build compiler.
+     <li> gmp.h would need an ugly <code>#ifdef</code> block to decide if the
+          application compiler could take the <code>long long</code>
+          prototypes.
+     <li> Some sort of <code>LIBGMP_HAS_LONGLONG</code> might be wanted to
+          indicate whether the functions are available.  (Applications using
+          autoconf could probe the library too.)
+     </ul>
+     It'd be possible to defer the need for <code>long long</code> to
+     application compile time, by having something like
+     <code>mpz_set_2ui</code> called with two halves of a <code>long
+     long</code>.  Disadvantages of this would be,
+     <ul>
+     <li> Bigger code in the application, though perhaps not if a <code>long
+          long</code> is normally passed as two halves anyway.
+     <li> <code>mpz_get_ull</code> would be a rather big inline, or would have
+          to be two function calls.
+     <li> <code>mpz_get_sll</code> would be a worse inline, and would put the
+          treatment of <code>-0x10..00</code> into applications (see
+          <code>mpz_get_si</code> correctness above).
+     <li> Although having libgmp.a independent of the build compiler is nice,
+          it sort of sacrifices the capabilities of a good compiler to
+          uniformity with inferior ones.
+     </ul>
+     Plain use of <code>long long</code> is probably the lesser evil, if only
+     because it makes best use of gcc.  In fact perhaps it would suffice to
+     guarantee <code>long long</code> conversions only when using GCC for both
+     application and library.  That would cover free software, and we can
+     worry about selected vendor compilers later.
+     <br>
+     In C++ the situation is probably clearer, we demand fairly recent C++ so
+     <code>long long</code> should be available always.  We'd probably prefer
+     to have the C and C++ the same in respect of <code>long long</code>
+     support, but it would be possible to have it unconditionally in gmpxx.h,
+     by some means or another.
+<li> <code>mpz_strtoz</code> parsing the same as <code>strtol</code>.
+     Suggested by Alexander Kruppa.
+</ul>
+
+
+<h4>Configuration</h4>
+
+<ul>
+<li> Alpha ev7, ev79: Add code to config.guess to detect these.  Believe ev7
+     will be "3-1307" in the current switch, but need to verify that.  (On
+     OSF, current configfsf.guess identifies ev7 using psrinfo, we need to do
+     it ourselves for other systems.)
+<li> Alpha OSF: Libtool (version 1.5) doesn't seem to recognise this system is
+     "pic always" and ends up running gcc twice with the same options.  This
+     is wasteful, but harmless.  Perhaps a newer libtool will be better.
+<li> ARM: <code>umul_ppmm</code> in longlong.h always uses <code>umull</code>,
+     but is that available only for M series chips or some such?  Perhaps it
+     should be configured in some way.
+<li> HPPA: config.guess should recognize 7000, 7100, 7200, and 8x00.
+<li> HPPA: gcc 3.2 introduces a <code>-mschedule=7200</code> etc parameter,
+     which could be driven by an exact hppa cpu type.
+<li> Mips: config.guess should say mipsr3000, mipsr4000, mipsr10000, etc.
+     "hinv -c processor" gives lots of information on Irix.  Standard
+     config.guess appends "el" to indicate endianness, but
+     <code>AC_C_BIGENDIAN</code> seems the best way to handle that for GMP.
+<li> PowerPC: The function descriptor nonsense for AIX is currently driven by
+     <code>*-*-aix*</code>.  It might be more reliable to do some sort of
+     feature test, examining the compiler output perhaps.  It might also be
+     nice to merge the aix.m4 files into powerpc-defs.m4.
+<li> config.m4 is generated only by the configure script, it won't be
+     regenerated by config.status.  Creating it as an <code>AC_OUTPUT</code>
+     would work, but it might upset "make" to have things like <code>L$</code>
+     get into the Makefiles through <code>AC_SUBST</code>.
+     <code>AC_CONFIG_COMMANDS</code> would be the alternative.  With some
+     careful m4 quoting the <code>changequote</code> calls might not be
+     needed, which might free up the order in which things had to be output.
+<li> Automake: Latest automake has a <code>CCAS</code>, <code>CCASFLAGS</code>
+     scheme.  Though we probably wouldn't be using its assembler support we
+     could try to use those variables in compatible ways.
+<li> <code>GMP_LDFLAGS</code> could probably be done with plain
+     <code>LDFLAGS</code> already used by automake for all linking.  But with
+     a bit of luck the next libtool will pass pretty much all
+     <code>CFLAGS</code> through to the compiler when linking, making
+     <code>GMP_LDFLAGS</code> unnecessary.
+<li> mpn/Makeasm.am uses <code>-c</code> and <code>-o</code> together in the
+     .S and .asm rules, but apparently that isn't completely portable (there's
+     an autoconf <code>AC_PROG_CC_C_O</code> test for it).  So far we've not
+     had problems, but perhaps the rules could be rewritten to use "foo.s" as
+     the temporary, or to do a suitable "mv" of the result.  The only danger
+     from using foo.s would be if a compile failed and the temporary foo.s
+     then looked like the primary source.  Hopefully if the
+     <code>SUFFIXES</code> are ordered to have .S and .asm ahead of .s that
+     wouldn't happen.  Might need to check.
+</ul>
+
+
+<h4>Random Numbers</h4>
+<ul>
+<li> <code>_gmp_rand</code> is not particularly fast on the linear
+     congruential algorithm and could stand various improvements.
+     <ul>
+     <li> Make a second seed area within <code>gmp_randstate_t</code> (or
+          <code>_mp_algdata</code> rather) to save some copying.
+     <li> Make a special case for a single limb <code>2exp</code> modulus, to
+          avoid <code>mpn_mul</code> calls.  Perhaps the same for two limbs.
+     <li> Inline the <code>lc</code> code, to avoid a function call and
+          <code>TMP_ALLOC</code> for every chunk.
+     <li> Perhaps the <code>2exp</code> and general LC cases should be split,
+          for clarity (if the general case is retained).
+     </ul>
+<li> <code>gmp_randstate_t</code> used for parameters perhaps should become
+     <code>gmp_randstate_ptr</code> the same as other types.
+<li> Some of the empirical randomness tests could be included in a "make
+     check".  They ought to work everywhere, for a given seed at least.
+</ul>
+
+
+<h4>C++</h4>
+<ul>
+<li> <code>mpz_class(string)</code>, etc: Use the C++ global locale to
+     identify whitespace.
+     <br>
+     <code>mpf_class(string)</code>: Use the C++ global locale decimal point,
+     rather than the C one.
+     <br>
+     Consider making these variant <code>mpz_set_str</code> etc forms
+     available for <code>mpz_t</code> too, not just <code>mpz_class</code>
+     etc.
+<li> <code>mpq_class operator+=</code>: Don't emit an unnecssary
+     <code>mpq_set(q,q)</code> before <code>mpz_addmul</code> etc.
+<li> Put various bits of gmpxx.h into libgmpxx, to avoid excessive inlining.
+     Candidates for this would be,
+     <ul>
+     <li> <code>mpz_class(const char *)</code>, etc: since they're normally
+          not fast anyway, and we can hide the exception <code>throw</code>.
+     <li> <code>mpz_class(string)</code>, etc: to hide the <code>cstr</code>
+          needed to get to the C conversion function.
+     <li> <code>mpz_class string, char*</code> etc constructors: likewise to
+          hide the throws and conversions.
+     <li> <code>mpz_class::get_str</code>, etc: to hide the <code>char*</code>
+          to <code>string</code> conversion and free.  Perhaps
+          <code>mpz_get_str</code> can write directly into a
+          <code>string</code>, to avoid copying.
+          <br>
+          Consider making such <code>string</code> returning variants
+          available for use with plain <code>mpz_t</code> etc too.
+     </ul>
+</ul>
+
+<h4>Miscellaneous</h4>
+<ul>
+<li> <code>mpz_gcdext</code> and <code>mpn_gcdext</code> 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|&lt;|b| and |y|&lt;|a| or something like that, but there's probably
+     two solutions under just those restrictions.
+<li> demos/factorize.c: use <code>mpz_divisible_ui_p</code> rather than
+     <code>mpz_tdiv_qr_ui</code>.  (Of course dividing multiple primes at a
+     time would be better still.)
+<li> The various test programs use quite a bit of the main
+     <code>libgmp</code>.  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
+     <code>libgmp</code> routine is only used for tests once it seems to be
+     good.
+<li> <code>MUL_FFT_THRESHOLD</code> etc: the FFT thresholds should allow a
+     return to a previous k at certain sizes.  This arises basically due to
+     the step effect caused by size multiples effectively used for each k.
+     Looking at a graph makes it fairly clear.
+<li> <code>__gmp_doprnt_mpf</code> does a rather unattractive round-to-nearest
+     on the string returned by <code>mpf_get_str</code>.  Perhaps some variant
+     of <code>mpf_get_str</code> could be made which would better suit.
+</ul>
+
+
+<h4>Aids to Development</h4>
+<ul>
+<li> Add <code>ASSERT</code>s at the start of each user-visible mpz/mpq/mpf
+     function to check the validity of each <code>mp?_t</code> parameter, in
+     particular to check they've been <code>mp?_init</code>ed.  This might
+     catch elementary mistakes in user programs.  Care would need to be taken
+     over <code>MPZ_TMP_INIT</code>ed variables used internally.  If nothing
+     else then consistency checks like size&lt;=alloc, ptr not
+     <code>NULL</code> and ptr+size not wrapping around the address space,
+     would be possible.  A more sophisticated scheme could track
+     <code>_mp_d</code> pointers and ensure only a valid one is used.  Such a
+     scheme probably wouldn't be reentrant, not without some help from the
+     system.
+<li> tune/time.c could try to determine at runtime whether
+     <code>getrusage</code> and <code>gettimeofday</code> are reliable.
+     Currently we pretend in configure that the dodgy m68k netbsd 1.4.1
+     <code>getrusage</code> doesn't exist.  If a test might take a long time
+     to run then perhaps cache the result in a file somewhere.
+<li> tune/time.c could choose the default precision based on the
+     <code>speed_unittime</code> determined, independent of the method in use.
+<li> Cray vector systems: CPU frequency could be determined from
+     <code>sysconf(_SC_CLK_TCK)</code>, since it seems to be clock cycle
+     based.  Is this true for all Cray systems?  Would like some documentation
+     or something to confirm.
+</ul>
+
+
+<h4>Documentation</h4>
+<ul>
+<li> <code>mpz_inp_str</code> (etc) doesn't say when it stops reading digits.
+<li> <code>mpn_get_str</code> isn't terribly clear about how many digits it
+     produces.  It'd probably be possible to say at most one leading zero,
+     which is what both it and <code>mpz_get_str</code> currently do.  But
+     want to be careful not to bind ourselves to something that might not suit
+     another implementation.
+<li> <code>va_arg</code> doesn't do the right thing with <code>mpz_t</code>
+     etc directly, but instead needs a pointer type like <code>MP_INT*</code>.
+     It'd be good to show how to do this, but we'd either need to document
+     <code>mpz_ptr</code> and friends, or perhaps fallback on something
+     slightly nasty with <code>void*</code>.
+</ul>
+
+
+<h4>Bright Ideas</h4>
+
+<p> The following may or may not be feasible, and aren't likely to get done in the
+near future, but are at least worth thinking about.
+
+<ul>
+<li> Reorganize longlong.h so that we can inline the operations even for the
+     system compiler.  When there is no such compiler feature, make calls to
+     stub functions.  Write such stub functions for as many machines as
+     possible.
+<li> longlong.h could declare when it's using, or would like to use,
+     <code>mpn_umul_ppmm</code>, and the corresponding umul.asm file could be
+     included in libgmp only in that case, the same as is effectively done for
+     <code>__clz_tab</code>.  Likewise udiv.asm and perhaps cntlz.asm.  This
+     would only be a very small space saving, so perhaps not worth the
+     complexity.
+<li> longlong.h could be built at configure time by concatenating or
+     #including fragments from each directory in the mpn path.  This would
+     select CPU specific macros the same way as CPU specific assembler code.
+     Code used would no longer depend on cpp predefines, and the current
+     nested conditionals could be flattened out.
+<li> <code>mpz_get_si</code> 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.
+<li> <code>mpz_init_set*</code> and <code>mpz_realloc</code> 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 <code>mpz_t</code> grows a bit more.
+     This could only be an option, since it'd badly bloat memory usage in
+     applications using many small values.
+<li> <code>mpq</code> 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.
+<li> <code>count_trailing_zeros</code> is used on more or less uniformly
+     distributed numbers in a couple of places.  For some CPUs
+     <code>count_trailing_zeros</code> is slow and it's probably worth handling
+     the frequently occurring 0 to 2 trailing zeros cases specially.
+<li> <code>mpf_t</code> 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 <code>mpz_set_f</code> and <code>mpf_cmp_ui</code> depend on
+     exp==0, maybe elsewhere too.
+<li> <code>__gmp_allocate_func</code>: Could use GCC <code>__attribute__
+     ((malloc))</code> 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.
+<li> <code>mpz_add_ui</code> contains two <code>__GMPN_COPY</code>s, one from
+     <code>mpn_add_1</code> and one from <code>mpn_sub_1</code>.  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.
+</ul>
+
+
+<h4>Old and Obsolete Stuff</h4>
+
+<p> The following tasks apply to chips or systems that are old and/or obsolete.
+It's unlikely anything will be done about them unless anyone is actively using
+them.
+
+<ul>
+<li> Sparc32: The integer based udiv_nfp.asm used to be selected by
+     <code>configure --nfp</code> but that option is gone now that autoconf is
+     used.  The file could go somewhere suitable in the mpn search if any
+     chips might benefit from it, though it's possible we don't currently
+     differentiate enough exact cpu types to do this properly.
+<li> VAX D and G format <code>double</code> floats are straightforward and
+     could perhaps be handled directly in <code>__gmp_extract_double</code>
+     and maybe in <code>mpn_get_d</code>, rather than falling back on the
+     generic code.  (Both formats are detected by <code>configure</code>.)
+</ul>
+
+
+<hr>
+
+</body>
+</html>
+
+<!--
+Local variables:
+eval: (add-hook 'write-file-hooks 'time-stamp)
+time-stamp-start: "This file current as of "
+time-stamp-format: "%:d %3b %:y"
+time-stamp-end: "\\."
+time-stamp-line-limit: 50
+End:
+-->