Re: GMP symbol naming (and the history thereof)?
Torbjorn Granlund t...@gmplib.org writes: As a start, I automatically made a list of symbols. Here are some comments on a few that stood out. __gmpn_add_n_sub_n __gmpn_add_nc I think these make sense as public (we'd need to investigate how one best does both _n and _nc in C, with duplication or a tail call). __gmpn_addcnd_n And this. (I think I'd prefer mp_limb_t mpn_cnd_add_n (mp_limb_t cnd, mp_ptr rp, mp_srcptr ap, mp_srcptr bp, mp_size_t n) but that's a minor detail, and view the cnd_-prefix as a family of functions. Some other potential members are mpn_cnd_copy, mpn_cnd_neg and mpn_cnd_swap, see http://git.lysator.liu.se/nettle/nettle/blobs/ecc-support/sec-modinv.c for one application). __gmpn_addlsh1_n __gmpn_addlsh2_n __gmpn_addlsh_n Some of these would make sense as public (with some kind of fallback to addmul_1 if no more efficient loop is implemented). __gmpn_divisible_p Would make sense as public, I think. __gmpn_gcdext_lehmer_n I think this would make sense as public, under a different name, e.g., mpn_gcdext_n_basecase. BTW, the other day I realized I'd like to extend the gcdext functions to allow gp == NULL, so callers who use them for modular inversion don't need to allocate space for a potentially large gcd. In this case, the functions should return 1 and produce the cofactor only if the gcd is 1, and otherwise return 0 to indicate failure. __gmpn_hgcd __gmpn_hgcd2 Some hgcd function should be public, possibly with interface tweaks. __gmpn_invert doc The doc flag is a false positive. But it would make sense to have public invert and invertappr. (Or reciprocal, if that's better). __gmpn_mulmod_bnm1 doc Another false positive. But since this function has turned out to be so useful, it would make sense to make it public in some form. __gmpn_powlo __gmpn_powm __gmpn_powm_sec __gmpn_powm_sec_itch Should be public, possibly with interface tweaks. __gmpn_redc_1 __gmpn_redc_2 __gmpn_redc_n Should be public in some form, but since the bdiv interface redesign is not yet integrated, redc interfaces should change a bit too for consistency. __gmpn_sqr_basecase This (and also mul_basecase) should be public. They're useful for crypto applications where numbers are known to be of moderate size and where low code complexity is desired. __gmpn_zero doc decl Missing in the list is mpn_zero_p. Should be public. Since it's easy, that function is at the top of my list when making additional mpn functions public. Not entirely sure how to deal with inline functions, but there are others in gmp-h.in so I should be able to figure that out. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Public mpn_add_nc (was Re: GMP symbol naming (and the history thereof)?)
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 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? 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. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
mpn_cnd_add_n (was: Re: GMP symbol naming (and the history thereof)?)
Torbjorn Granlund t...@gmplib.org writes: And this. (I think I'd prefer mp_limb_t mpn_cnd_add_n (mp_limb_t cnd, mp_ptr rp, mp_srcptr ap, mp_srcptr bp, mp_size_t n) but that's a minor detail, and view the cnd_-prefix as a family of functions. Some other potential members are mpn_cnd_copy, mpn_cnd_neg and mpn_cnd_swap, see http://git.lysator.liu.se/nettle/nettle/blobs/ecc-support/sec-modinv.c for one application). I agree that would be a good naming cleanup. Will you do the honours? I'll put it on my mental TODO list. You did notice that I moved the condition to be the first argument? Will require minor changes to the assembly implementations. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
mpn_gcdext_n_basecase (was: Re: GMP symbol naming (and the history thereof)?)
Torbjorn Granlund t...@gmplib.org writes: __gmpn_gcdext_lehmer_n I think this would make sense as public, under a different name, e.g., mpn_gcdext_n_basecase. Maybe. We need to worry about the itch/scratch interface. For user interface code, it seems to make sense to have scratch parameter less functions. Like __gmpn_divisible_p. Unless we decide that the itch/scratch interface is a failed experiment (I don't think it is), I think we should strive for itch/scratch also in the public mpn interface. For convenience, we can allow NULL scratch pointer (except for low-level loops which really need all registers they can get; this needs to be documented for each function). For example, I'd like the ecdsa_verify function I'm writing to be itchified, and then if I call mpn_gcdext_n_basecase do to the modular inversion, I really want to pass in all needed storage. Ideally, I'd like it to be possible to write programs using gmp for cryptographic operations on known sizes, and do all allocation statically. Should a mpn_gcd_n_basecase also be available, for symmetry? Would make sense. Currently, there is no such function. Does the gcdext functions need a large gp area also when the caller knows the gcd = 1? I don't think so, but it gives a very ugly failure behaviour. And I think I'm *almost* sure this element is invertible is also an important usecase. Regardss, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: GMP symbol naming (and the history thereof)?
Richard Henderson r...@twiddle.net writes: Excellent. That's more or less exactly what I want to do. That would be another welcome contribution! I believe that IFUNC and the fallback fat system can live side-by side, sharing most of the actual logic. The choice of which implementation to build into the shared library can be made by configure. Good! Fair enough. While you can't override the mpn routines in libc.so (they're hidden), there is a potential issue with static linking. FWIW, glibc uses __mpn as the prefix. FWIW, on another library I wrote recently I used pfx_ for the external names and PFX_ for the internal names. I suggest that we do it like the following in GMP: In a static lib, I suppose nothing should change. In a shared lib, make all symbols by just the logical call name, like mpn_addmul_1, mpz_mul, gmp_printf, mpn_strangeinternalfunction. Make these hidden. Then for the functions we want to make public, define aliases to __gmpn_addmul_1, __gmpz_mul, __gmp_printf. Motivation: This should be link compatible with existing user programs. Using the plain names internally is a convenience when debugging. About testing of static vs shared lib. Currently 'make check' test either, never both, even if both were built. I consider this a serious flaw, since 'make check' gives a false confidence that the library was not miscompiled. I would like to change this behaviour. I realise the 'hidden' project might create some problems for (unit) testing of internal routines. I am not sure we do that a lot, except that tune/speed, tune/tuneup, tests/devel/try surely need access to everything. I see two solutions: 1. Possibly have a configure option that disables the 'hidden' stuff. 2. Link these three programs statically. That's not at all unreasonable. A side note: I think that we should move towards fat binary builds as the normal build. Our current method of careful compile-time CPU recognition is better for benchmarking than for the real world. Ideally, fat builds should be the default for all configs. Unfortunately CPU manufacturers make CPU recognition difficult. -- Torbjörn ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: GMP symbol naming (and the history thereof)?
Richard Henderson r...@twiddle.net writes: Several times over the past week as I debug my neon routines, it has become painfully apparent (as I accidentally single-step into the dynamic linker) that the shared libgmp could use some help in modernizing its internal linkage. We are at least aware of these things (Calls and linkage): https://gmplib.org/devel/GMPng.html Most important is arranging for calls within GMP to go through private names, so that e.g. mpn_mul doesn't have to go through the PLT in order to reach mpn_addmul_1. Agreed. We're moving towards using fat libraries (--enable-fat) and there we are perhaps paying an even higher price for GOTs and PLTs. There are some specific GNU/Linux loader features which were discusssed here not long ago. I prefer to start portable, then do unportable tweaks. (Yes, the GNU system is the most important goal for the GNU project, but I want GMP to be great on every reasonable platform.) There are several ways to approach this fix, and I can talk about those in followups, but to begin we need to have a discussion as to exactly what the public interface is. This dove tails nicely with the work that Neils has done recently with tidying up mpn. We indeed don't want to make hidden every undocumented function. The plan is to use hidden for every symbol, and add aliases for all undocumented plus any function people use outside of the documented interface. What I'm curious about is the __g prefix associated with 95% of the symbols. Why is gmp defining symbols in the namespace reserved to the compiler and the implementation aka the standard c library? I mean, I guess we're not actually getting into trouble for it, since it's actually working, but I don't think it's very clean. We're staying in a quite limited namespace, not __g but __gmp. One reason for this is that we put some mpn functions in libc. They were there for many years, and last time I looked they where still there. We don't ever want to replace libc's internal routines for people that also link to GMP... Another reason is to stay away from the user name space with our internal routines. Today we can do that more cleanly, at least on ELF systems, but GMP was born in 1991 before these teenage features existed. :-) If at some point we make some change that requires the bumping of the shared library version number, I think it would be a good opportunity to drop the prefix, bringing the API and ABI names back in sync. But until we do make some other incompatible ABI change it's probably not worth it. Hmm. I suppose we could add that to https://gmplib.org/devel/incompatibility.html. (I am thinking GMP 6.0 for an incompatible GMP. We're probably doing GMP 5.2 first. I am trying to step down from my GMP dictator role and instead be a member of a junta, so I'm not going to make this decisions alone.) But the first thing to do is to confirm exactly what API symbols should be exported. I'm going to begin with the assumption that if it isn't declared in gmp-h.in, then it's not public. We could start there, and wait for the screams. :-) -- Torbjörn ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: GMP symbol naming (and the history thereof)?
From: Torbjorn Granlund t...@gmplib.org Date: Thu, 28 Feb 2013 09:50:29 +0100 One reason for this is that we put some mpn functions in libc. They were there for many years, and last time I looked they where still there. We don't ever want to replace libc's internal routines for people that also link to GMP... They should only be being used internally by the vfprintf et al. implementation, and not exported externally in the user visible set of symbols. ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: GMP symbol naming (and the history thereof)?
Torbjorn Granlund t...@gmplib.org writes: There are some specific GNU/Linux loader features which were discusssed here not long ago. I prefer to start portable, then do unportable tweaks. (Yes, the GNU system is the most important goal for the GNU project, but I want GMP to be great on every reasonable platform.) I think it's possible to keep the current fat mechanism mor or less as is, and additionally use IFUNC-relocations where available. The IFUNC hooks should call in to GMP's fat machinery and then return an appropriate function pointer back to the linker. Another reason is to stay away from the user name space with our internal routines. Today we can do that more cleanly, at least on ELF systems, but GMP was born in 1991 before these teenage features existed. :-) I think it make sense with some level of name mangling from API symbols to linker names. First, it's good practice to use a single prefix for all linker symbols, while it's nice to use multiple prefixes for API symbols (mpz_*, mpn_*, gmp_*, ...). Second, and maybe you don't agree, I think it's quite reasonable for users to use the name spaces mpz_* and mpn_* for application functions working with the corresponding types. With some name mangling for gmp symbol names, at least that user doesn't risk collision with the internal gmp functions. Third, I think it's desirable if gmp and mini-gmp keep using different symbol names as seen by the linker. But I don't think using a __ prefix on symbols is appropriate, it would be better to use the namespace gmp_* or maybe libgmp_*. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: GMP symbol naming (and the history thereof)?
ni...@lysator.liu.se (Niels Möller) writes: I think it make sense with some level of name mangling from API symbols to linker names. First, it's good practice to use a single prefix for all linker symbols, while it's nice to use multiple prefixes for API symbols (mpz_*, mpn_*, gmp_*, ...). Agreed. Second, and maybe you don't agree, I think it's quite reasonable for users to use the name spaces mpz_* and mpn_* for application functions working with the corresponding types. With some name mangling for gmp symbol names, at least that user doesn't risk collision with the internal gmp functions. That's indeed one of my motivations. And this *does* happen, it is not a hypothetical problem such as our invasion if the implementation name space. Third, I think it's desirable if gmp and mini-gmp keep using different symbol names as seen by the linker. Agreed. But I don't think using a __ prefix on symbols is appropriate, it would be better to use the namespace gmp_* or maybe libgmp_*. I disagree. Any solution here is a compromise. And there are more drawbacks with dropping the __ than retaining it. Hmm, perhaps we could use the prefix iouyfvhbiqckbfgkuigblkiuyggcuyhfbg, to make things more clean? The risk of an accidental collision should be quite limited, and there is hopefully no paragraph in some standard document somewhere against which we would be in breach. :-) -- Torbjörn ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: GMP symbol naming (and the history thereof)?
Vincent Lefevre vinc...@vinc17.net writes: I don't understand why changing the __ prefix to a gmp_ or libgmp_ namespace would be a problem. It breaks ABI compatibility (but that's no big problem, since I think we all agree the change should be done only when we have some other good reason to break the ABI). And it's going to break some configure scripts, and programs using dlopen to access GMP symbols. These are all transition problems. I'm not aware of any other drawbacks. Regards, /Niels -- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance. ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: GMP symbol naming (and the history thereof)?
I try to classify things on my list a bit further, and correct errors. I stumbed over some functions. I need feedback here. mpn_div_qr_2 is decl but not doc. I suggest we move the declaration to gmp-impl.h. mpn_divrem_2 is decl but not doc. I suggest we move the declaration to gmp-impl.h. mpn_gcdext_1 is decl but not doc. It seems to make sense to have a user-available mpn_gcdext_1. We have mpn_gcd_1 already. mpn_pow_1 is decl but not doc. I suggest we move the declaration to gmp-impl.h. mpn_perfect_power_p is decl but not doc. I suggest we move the declaration to gmp-impl.h. mpn_preinv_mod_1 is decl but not doc. I think it *was* documented in the past, so we should keep it. mpz_limb*, mpz_roinit_n are decl but not doc. I kindly but strongly suggest that the are documented... mpz_millerrabin is decl but not doc. I suppose we might make a Miller-Rabin function public, perhaps this one. mp?_dump are decl but not doc. We might as well make these public. I put the new file at http://gmplib.org/devel/gmp-func-list.txt. Comitters are welcome to keep annotating it. -- Torbjörn ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
Re: GMP symbol naming (and the history thereof)?
On 02/28/2013 12:50 AM, Torbjorn Granlund wrote: Richard Henderson r...@twiddle.net writes: Several times over the past week as I debug my neon routines, it has become painfully apparent (as I accidentally single-step into the dynamic linker) that the shared libgmp could use some help in modernizing its internal linkage. We are at least aware of these things (Calls and linkage): https://gmplib.org/devel/GMPng.html Excellent. That's more or less exactly what I want to do. We're moving towards using fat libraries (--enable-fat) and there we are perhaps paying an even higher price for GOTs and PLTs. There are some specific GNU/Linux loader features which were discusssed here not long ago. I prefer to start portable, then do unportable tweaks. (Yes, the GNU system is the most important goal for the GNU project, but I want GMP to be great on every reasonable platform.) I believe that IFUNC and the fallback fat system can live side-by side, sharing most of the actual logic. The choice of which implementation to build into the shared library can be made by configure. One reason for this is that we put some mpn functions in libc. They were there for many years, and last time I looked they where still there. We don't ever want to replace libc's internal routines for people that also link to GMP... Fair enough. While you can't override the mpn routines in libc.so (they're hidden), there is a potential issue with static linking. FWIW, glibc uses __mpn as the prefix. FWIW, on another library I wrote recently I used pfx_ for the external names and PFX_ for the internal names. r~ ___ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel
