Random notes:

Bignums do not come into existence until something overflows, so they
should have no effect on normal performance.  I've sent a rover.c that
does the overflow check in C, which does affect performance, though
not that I can detect.

cvint() fails if given a bignum, as it does if given a big real.  So
something like assigning a bignum to a keyword will fail, as it should.
Most numeric things use cvnum(), and those all handle bignums. 
I changed a few things from cvint() to cvnum(), like iand and friends.
That accounts for most of the changes in iconx proper.  I think the only
thing I missed is toby.  (And the compiler and linker.)

I wanted it to work at least with 16-bit digits using 32-bit unsigned
arithmetic or with 31-bit digits using 64-bit signed arithmetic, and it
does, at the cost of quite a lot of casts.  (Since the main computational
type is of ambiguous signedness and might be larger than int.)  It might
happen that it works on a machine with 16-bit ints because of this, but I
have no way to try it.

It uses alloca(), bcopy(), and bzero(), which are Berkleyisms.  I don't
think they'd be hard to get rid of, but I didn't spend any time on trying
to fit more closely into Icon's current structure since you said it's
changed.

I put everything into one file, rbignum.c, whether it belongs there or
not, to keep the changes to iconx proper as short as possible.
I used the term "bignum" because it's familiar from Lisp; I don't
know how well it accords with Icon terminology.  My formatting style
definitely isn't in accord with the rest of iconx.  If you decide
to adopt this stuff, of course, you can change it all around as
needed.

I've included test programs to print out some tables from Knuth,
which have known right answers.

I added a field to union numeric that points to a bignum block,
which is a very bad idea since it leaves block pointers floating
around outside descriptors.  It works ok, the pointers immediately
get put into descriptors by the code that called cvnum(), but it
still seems like bad idea.  I don't know enough about how things ought
to work to have any better ideas.

		Chris Smith
		Convex
