GMP 6 the incomatible GMP?

[Marc Glisse]

On Tue, 8 Jan 2013, David Miller wrote:

> From: Torbjorn Granlund <tg at gmplib.org>
> Date: Tue, 08 Jan 2013 12:50:01 +0100
>
>> Marc Glisse <marc.glisse at inria.fr> writes:
>>
>>   Then we might as well always put it in _mp_d[-1], no? IIRC that's what
>>   mpfr does.
>>
>> I see some problems with that:
>>
>> * There is a serial memory dependency problem, making the allocation
>>   check at least one more cache latency away.  I don't think OoO
>>   execution will be able to hide that, as this is used.

My intuition would be that this won't matter, but you have more experience 
than me with that.

> I don't know how amicable you are to an idea like this, but if user
> applications can only treat pointers to these objects as opaque then
> you can encode information in the lowest bits of the pointer.
>
> For example, you could encode in the lowest bit whether the _mp_d[-1]
> thing is being done or not.
>
> Then it's at worst a mis-predicted branch in the allocation check.

That seems similar (not saying one is better than the other) to what Niels 
was proposing, where he was encoding it as a special value of the bitfield 
_mp_alloc (so basically in a few bits of _mp_size) instead of _mp_d.

What is done by bignum libraries in many languages is that the base object 
is a single pointer, and depending on the lowest (?) bit it is interpreted 
either as a pointer to (alloc+)size+limb[] or as a small integer. But 
again, their intended main use is with numbers that would fit in an int.

-- 
Marc Glisse

PS: thanks a lot for your sparc assembly work!