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: ARM Neon popcount
ni...@lysator.liu.se (Niels Möller) writes:
What about vldm? Like
vldmup!, {q0,q1,q2,q3}
As far as I understand the manual, it supports a larger number of
registers. The registers must be consecutive, but that's no problem
here.
I added a long list of things to try. A new version is attached.
I consider you to be the A9 optimisation guy, and hope that you will
tweak all great A15 loops into running wonderfully also on A9.
arm-popcount.asm
Description: Binary data
A trick to explore that can make the code much simpler and also give
high degree of alignment is this:
Align pointers by masking, to (say) a 128bit/16byte boundary. Load from
there, reading outside the defined area (unless the pointer was already
aligned). Mask the read data using (ptr mod 16). Then do any feed-in,
looping, and wind-down. Repeat the trick at the end of the operand. It
will be simplest if we arranged for the looping to leave 1-16 bytes, not
0-15 bytes, so that we don't need to add conditions.
We get no love from Valgrind using these tricks, and Vincent will
lecture us that this is C is undefined when doing such things. My
defence against the former is that Valgrind has an option for tolerating
our behaviour, but I must concede that our assembly code is indeed
completely undefined when interpreted as C. :-)
--
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: Extending the mpn interface
bodr...@mail.dm.unipi.it writes: A comment about roinit... This function trusts the caller with regards to normalisation. I'm not sure I like this. I think we should: - normalize (same code as mpz_limbs_finish) before setting SIZ, or - add an ASSERT (xs == 0 || xp[ABS (xs)] != 0), and add a normalize function or macro to the documented interface. I agree it makes sense to let this function do normalization. We might want to have a public MPN_NORMALIZE anyway, but that's a separate issue. And MPN_ROINIT_N can't normalize, of course. 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)?
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: Extending the mpn interface
On Thu, 28 Feb 2013, Niels Möller wrote: And MPN_ROINIT_N can't normalize, of course. I think it could in modern languages (say C++11 for instance), but that's not the point, sorry for the digression. -- Marc Glisse ___ 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
Register r9 in the ARM ABI
I have a general ARM question, that maybe Richard or someone else on the list can answer. From the ABI documentation I've read, register r9 is in some way reserved for implementation of things like thread local storage. If I write a leaf function (not calling anybody else, and not using thread local storage), can a use r9 like any other callee-save register or not? The only potential problem case I see is if my function is interupted by a signal, and the signal handler expects the value in register r9 to be valid. 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)?
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
