Re: CLN, GMP inputs

[Hans Aberg]

At 09:44 +1000 2001/05/06, Kevin Ryde wrote:
>> If GMP would add small number representations, that might even be a
>> complication, because GHC might still need to convert to its internal
>> format.
>
>You know a possibility would be to reserve one bit of a 32-bit int as
>a flag indicating it's not a number but a pointer to a bignum.  Then
>maybe all arithmetic could be inlined and just have traps to special
>code if a bignum is encountered.  But no doubt others smarter than me
>have thought more about such things.

I have been thinking about the representation I suggested in the earlier email:
  typedef struct  {
    _mp_int _mp_s;     /* Small number representation. */
    mp_limb_t *_mp_d;  /* Pointer to the limbs and all other data.  */
  } __mpz_struct;
where simply _mp_d is set to NULL if one is using the small number
representation.

I find it interesting for several reasons:

First, the small number format is wholly untampered with, so all one is
down to is overflow checks. If a CPU would support instructions for
  +, -, *: 1-register x 1-register -> 2-register
then the small number representations could be made very fast. (But I am
told that many CPU's do not support that.)

But the conversion back and forth from native integral types to GMP types
are also easy:

For example, the signed integral type one merely puts into the _mp_s field
and sets _mp_d to NULL. The unsigned integral type one checks the most
significant bit; if it is 0, one converts it as a signed, if it is 1, one
sets it to the one limb format.

GMP would only need to define the basic arithmetic operations involving
__mpz_struct; the ones involving native integral types could be macroed on
top of them.

  Hans Aberg