tg at gmplib.org
Sun Mar 3 19:13:04 CET 2013
nisse at lysator.liu.se (Niels Möller) writes:
> I didn't list __gmpn_add_n_sub_n as public since I consider it
> experimental. It seemed like a good idea, but I never managed to make
> it faster, not even for the large operands for which is was intended.
I see. Main intended use was Schönhage-Strassen fft, or?
That's why it was added.
(We long ago discussed adding a full mpn_ss_butterfly [or whatever to
call it] which might be a better idea. This is another discussion,
> While __gmpn_add_nc makes more sense as public, I didn't suggest it to
> be that for more practical reasons. Many asm implementations do not
> provide this entry point.
> I am not against making it public, but it cannot be done without
> additional work.
I see. I hope adding the entry points should be easy.
Shouldn't be too hard.
I'd suggest to:
* Rewrite the C functions to accept carry-in, and of course rename to _nc.
* Provide macros (or inlines) for mpn_add_n (mpn_sub_n)
* Provide fall-back mpn_add_n (mpn_sub_n) for the library (needed for
link compatibility, these functions have long been public). These
fallbacks could just call _nc, or ave the current code.
* Conditionally provide _nc for when asm procides _n.
This is some hours of work to get it all right, and test it.
Until somebody fixes it, we just keep _nc non-public.
More information about the gmp-devel