Re: gmp issues (long)

[Rob Browning]

Marius Vollmer <address@hidden> writes:

> I'm not so much worried about the size of an mpz_t but about the
> fact that it requires an additional malloc.

OK, though an extra 6 bytes of overhead (actually 8 if you include the
fact that mpzs can't allocate in 2-byte-increments) for a 6 byte
integer still concerns me a bit, but perhaps it's OK -- and not
worrying about it will certainly keep the code simpler.

> 12 bytes is just right for our double cells, tho.  So I would
> suggest making bignums a double cell and putting the mpz_t structure
> into slots 1, 2, and 3.

Hmm good idea -- didn't think about the fact that that could work this
time...

So is there a way we can memcpy the mpz_t data into the double cell's
three words, or would I need to pass the individual coerced pieces of
the mpz_t to a call to scm_double_cell?  i.e. is it OK to presume cell
words are guaranteed to be contiguous, or are you required to go
through the SCM_CELL_N interface?

> There should be a test somewhere whether mpz_t really fits into this
> space.  For now we can just wait for this test to fail, I'd say.

What would be the correct formulation of this test?  Would this be
right?

  sizeof (mpz_t) <= 3 * sizeof (SCM)

or perhaps given scm_double_cell's prototype

  sizeof (mpz_t) <= 3 * sizeof (scm_t_bits)

> This also removes the additional indirection.

Yep.

-- 
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