Add ARC umul_ppmm.

Note sparc32/v9 mulx not much help.
Add ia64-*-hpux* elf-32 in libtool.
Add possible -mno-cygwin for mingw.

1 files changed, 18 insertions, 7 deletions

diff --git a/doc/tasks.html b/doc/tasks.html
index dcefc1a79..7cd2c5d6d 100644
--- a/doc/tasks.html
+++ b/doc/tasks.html
@@ -33,7 +33,7 @@ MA 02111-1307, USA.
 <hr>
 <!-- NB. timestamp updated automatically by emacs -->
 <comment>
-  This file current as of 19 Feb 2002.  An up-to-date version is available at
+  This file current as of 7 Mar 2002.  An up-to-date version is available at
   <a href="http://www.swox.com/gmp/tasks.html">http://www.swox.com/gmp/tasks.html</a>.
   Please send comments about this page to
   <a href="mailto:bug-gmp@gnu.org">bug-gmp@gnu.org</a>.
@@ -372,6 +372,9 @@ MA 02111-1307, USA.
 <li> Alpha 21264 ev67: Use <code>ctlz</code> and <code>cttz</code> for
      <code>count_leading_zeros</code> and<code>count_trailing_zeros</code>.
      Use inline for gcc, probably want asm files for elsewhere.
+<li> ARC: gcc longlong.h sets up <code>umul_ppmm</code> to call
+     <code>__umulsidi3</code> in libgcc.  Could be copied straight across, but
+     perhaps ought to be tested.
 <li> ARM: On v5 cpus see if the <code>clz</code> instruction can be used for
      <code>count_leading_zeros</code>.
 <li> Itanium: <code>mpn_divexact_by3</code> isn't particularly important, but
@@ -400,7 +403,8 @@ MA 02111-1307, USA.
      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).
+     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
@@ -710,6 +714,8 @@ MA 02111-1307, USA.
      perhaps just as a build-time choice.  In any case, figure out how to
      identify a suitable gcc or put it in the right mode, for the GMP compiler
      choices.
+<li> IA64: Latest libtool has some nonsense to detect ELF-32 or ELF-64 on
+     <code>ia64-*-hpux*</code>.  Does GMP need to know anything about that?
 <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.  GMP currently only
@@ -772,6 +778,10 @@ MA 02111-1307, USA.
      case someone runs configure a second time without a
      <code>distclean</code> in between.  The only tricky part would be making
      sure all possible <code>extra_functions</code> are covered.
+<li> MinGW: Apparently a Cygwin version of gcc can be used by passing
+     <code>-mno-cygwin</code>.  For <code>--host=*-*-mingw32*</code> it might
+     be convenient to automatically use that option, if it works.  Needs
+     someone with a dual cygwin/mingw setup to test.
 </ul>
 
 
@@ -902,11 +912,12 @@ near future, but are at least worth thinking about.
      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, a
-     subroutine version of some macro, and the corresponding .asm file could
-     be included in libgmp only in that case, the same as done for
-     <code>__clz_tab</code>.  But this would be a very small space saving, so
-     perhaps not worth the complexity.
+<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.