Public mpn_add_nc (was Re: GMP symbol naming (and the history thereof)?)

2013-03-03 Thread Niels Möller
Torbjorn Granlund t...@gmplib.org writes: ni...@lysator.liu.se (Niels Möller) writes: Here are some comments on a few that stood out. Thanks! I think I'll reply in one mail per function (-group). I didn't list __gmpn_add_n_sub_n as public since I consider it experimental. It seemed

Re: Public mpn_add_nc

2013-03-03 Thread bodrato
Ciao, Il Dom, 3 Marzo 2013 7:13 pm, Torbjorn Granlund ha scritto: ni...@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

Re: Public mpn_add_nc

2013-03-03 Thread Niels Möller
Torbjorn Granlund t...@gmplib.org writes: 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

Re: Public mpn_add_nc

2013-03-03 Thread Torbjorn Granlund
ni...@lysator.liu.se (Niels Möller) writes: As I understand it, that plan would imply that for assembly files currently providing both _n and _nc, the _n entry point gets obsolete That was not the idea, at least not for internal calls. It sometimes have a cycle or two overhead. It does

Re: Public mpn_add_nc

2013-03-03 Thread Niels Möller
Torbjorn Granlund t...@gmplib.org writes: ni...@lysator.liu.se (Niels Möller) writes: As I understand it, that plan would imply that for assembly files currently providing both _n and _nc, the _n entry point gets obsolete That was not the idea, at least not for internal calls. It