GMP code committed -- watch for bugs.

[Rob Browning]

I've just committed the code that switches us over to full-time
bignums using GMP.  I've tagged before and after with rlb-pre-gmp and
rlb-post-gmp.

(Marius: we'll need to finish switching to LGPL now.  I put a note in
 LICENSE for now.  I suppose we'll need to exchange COPYING for
 COPYING.LIB.  However if automake throws a fit and/or keeps putting
 COPYING back, we might just leave it.  LICENSE is the critical file.)

(Mikael: if you get a second, could you look at random.c and make sure
 you don't see any obvious mistakes.  One thing in particular -- could
 you look at the FIXME there -- if there's a chance that a random
 bignum could end up with enough leading zeroes to place it in fixnum
 territory, then we need to return scm_i_normbig (result), but I
 wanted to check with you first.  Returning a bignum with a value in
 fixnum range would violate an assumption made by other guile
 numerical code.)

There may well be bugs -- in addition to numbers.c, the other main
things to check (if you're motiviated) are random.c, socket.c, and
num2integral.c.  If/when you do find a bug, could you also try to add
a suitable test (if possible) to test-suite/tests/numbers.test or
similar so we don't regress in the future?

Overall the performance in my really simple tests on ~256-bit bignums
suggests this is code faster than the old code, but less space
efficient for smaller values.

To some extent the conversion in numbers.c has been fairly
straightforward.  There may still be places (i.e. perhaps have
integer-expt use mpz_pow or mpf_pow_ui when the types are right) where
special casing with GMP operations could help, but it'll probably take
some good benchmarking to know for sure.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4