Re: CLN, GMP inputs

[Kevin Ryde]

Hans Aberg <address@hidden> writes:
>
> Do I understand this right: Is the idea to then malloc the whole
> __mpf_struct, so that in the allocation _mp_d becomes whatever comes after
> the other fields?

Yes, that's the theory.

> The other thing that comes to my mind is field alignment: If int's,
> mp_exp_t, and mp_limb_t have different sizes, the word alignment for the
> limbs might go off, slowing it down.

I'm pretty sure writing mp_limb_t there forces a suitable alignment.
Anyway it's just an idea.

> I'm not sure what you mean with the need for "upward binary compatibility":
> Is that for use in DLL's? Otherwise, only the inteface would matter.

Any program (or library) should be able to just re-link to a new
libgmp and continue to work.  That means types like mpz_t must remain
the same size, and fields that get accessed in application code must
remain the same size and offset.  Applications don't directly access
fields, but references to _mp_size and _mp_d are made via mpz_sgn and
mpz_odd_p, and there'll be more similar inlining in the future.

> The question is how GMP best can support that; if one achieves the effects
> within GMP or by building something on top, I think matters little.

It's to be hoped gmp provides enough building blocks to do useful
things efficiently.