disallow defining MP_DIGIT_BIT, only allow MP_8/16/31/32/64BIT

[minad]

Maybe also make MP_31BIT the default the next time the ABI is broken?

[czurnieden]

Maybe also make MP_31BIT the default the next time the ABI is broken?

Would practically kill s_mp_mul_digs_fast because PRIVATE_MP_WARRAY would be just 8 (eight) with a 32-bit arch instead of the 512 with 28 bit; and FFT, because 31 is too large, I would need to divide it into parts, not a problem in itself, but it would be unequal parts with a prime which is way more complicated to do.

[minad]

Would practically kill s_mp_mul_digs_fast

Thanks! Good to know. How many additional bits do we need? 4 bits? Usable 28 on 32, 60 on 64 etc?

[minad]

@czurnieden The comment says "28 bit is needed to make porting easier", but this is clearly not the reason then. Maybe there should also be a warning that MP_31BIT is harmful? I don't know!?

[czurnieden]

Maybe there should also be a warning that MP_31BIT is harmful?

It is not harmful per se it just has consequences. But I think you are right, these consequences should be pointed out in a more precise way at a more prominent place.

[minad]

Ok, could you add a comment since you seem to know the consequences? If you agree with this PR (that MP_DIGIT_BIT should not be defined by the user), you can just add it to this PR or rework it as you wish.

[czurnieden]

Ok, could you add a comment since you seem to know the consequences?

But I just told you?
There are no others I'm aware of.

How many additional bits do we need?

Even 2 bit would result in 32 limbs, 992 bits but 4 bit will support up to 8k bit large RSA keys which I find sufficient for the next couple of years.

We could try a couple of variations and do a benchmark?

you can just add it to this PR or rework it as you wish.

No, don't like to mess with other people's PRs without a very good reason.
And you are still alive as it seems ;-)

/*  
   This is an extension that uses 31-bit digits.
    Please be aware that not all functions support this size, especially  s_mp_mul_digs_fast
    will be reduced to work on small numbers only:
    Up to 8 limbs, 248 bits instead of up to 512 limbs, 15872 bits with MP_28BIT.
 */

Just C&P if you like it.

I would add to it In the case that FFT finds its way into LTM because I don't plan to implement the MP_31BIT version, so no FFT for MP_31BIT.

[minad]

fixed and rebased