Public mpn_add_nc

[Niels Möller]

Torbjorn Granlund <tg at 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
>   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.

Sounds reasonable.

As I understand it, that plan would imply that for assembly files
currently providing both _n and _nc, the _n entry point gets obsolete
(will be used only by applications compiled with gmp.h from an older
version of the library), and assembly files only _n only will be unused
by code compiled with new gmp.h? All _n entry points should then be
*deleted* once we do an ABI change for GMP-6 or so?

It does make sense to me to have the _nc functions as the only assembly
entry points.

It would be nice to just fix all the missing entry points, but that's a
dozen or two of files. The files providing add_n but not add_nc seem to
be:

  alpha/ev6/nails/aors_n.asm
  m68k/aors_n.asm
  vax/add_n.asm
  cray/add_n.c
  power/add_n.asm
  a29k/add_n.s
  generic/add_n.c
  powerpc64/mode32/add_n.asm
  m88k/add_n.s
  m88k/mc88110/add_n.S
  sparc32/add_n.asm
  sparc32/v9/add_n.asm
  sh/add_n.asm
  i960/add_n.s
  mips32/add_n.asm
  pa32/add_n.asm
  pa32/hppa1_1/pa7100/add_n.asm
  pa32/hppa2_0/add_n.asm
  ns32k/add_n.s
  pyr/add_n.s
  z8000/add_n.s
  clipper/add_n.s

I imagine not all these platforms are tested regularly...

Something similar could be done with addmul_1/addmul_1c, but let us take
one step at a time.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.