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

[Richard Henderson]

On 02/28/2013 12:50 AM, Torbjorn Granlund wrote:
> Richard Henderson  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

Register r9 in the ARM ABI

[Niels Möller]

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)?

[Richard Henderson]

On 02/28/2013 03:14 AM, bodr...@mail.dm.unipi.it wrote:
>> We could start there, and wait for the screams.  :-)
> 
> Our own test-suite will let the first scream out !-D

Yes, I know.  The solution that I like best is to do such unit testing
statically, rather than disturbing symbols exported from the shared library.


r~
___
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]

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: Extending the mpn interface

[Marc Glisse]

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)?

[Vincent Lefevre]

On 2013-02-28 12:51:29 +0100, Niels Möller wrote:
> Vincent Lefevre  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.

Of course, I meant except the obvious compatibility problems.

BTW, if this is decided, since this is going to break things, such
a change should be announced several months before starting it, so
that (almost) every one has a chance to be ready when it occurs in
a release version.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
___
gmp-devel mailing list
gmp-devel@gmplib.org
http://gmplib.org/mailman/listinfo/gmp-devel

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

[Niels Möller]

Vincent Lefevre  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

[Niels Möller]

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)?

[Torbjorn Granlund]

bodr...@mail.dm.unipi.it writes:

  Il Gio, 28 Febbraio 2013 9:50 am, Torbjorn Granlund ha scritto:
  > Richard Henderson  writes:
  > We are at least aware of these things ("Calls and linkage"):
  > https://gmplib.org/devel/GMPng.html
  
  >   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.  :-)
  
  Our own test-suite will let the first scream out !-D
  
Hmm.  I never understood why people cannot stay away from internal
functions!

  The first thing to do IMO is to define the levels of visibility we need:
  we have documented functions, functions that are not documented but are
  used by other programs (we should probably document many of those),
  functions and tables that are used both internally and by the test-suite
  (would be nice to somehow hide them... is it possible?), functions and
  tables for internal use only...
  Next step, let the configure process define pertinent macros...
  
  Then, the hiding/aliasing game can start :-)
  
As a start, I automatically made a list of symbols.  The doc moniker
means that a grep in gmp.texi matched it; the decl matched means that a
greo in gmp-h.in matched it.  Here:



gmp-func-list
Description: Binary data

For reference, this is the silly script:



sc.sh
Description: Bourne shell script

-- 
Torbjörn
___
gmp-devel mailing list
gmp-devel@gmplib.org
http://gmplib.org/mailman/listinfo/gmp-devel

Re: Extending the mpn interface

[bodrato]

Ciao!

A comment about roinit...

Il Sab, 23 Febbraio 2013 5:45 pm, Niels Möller ha scritto:
> +mpz_srcptr
> +mpz_roinit_n (mpz_ptr x, mp_srcptr xp, mp_size_t xs)
> +{
> +  ALLOC (x) = 0;
> +  SIZ (x) = xs;
> +  PTR (x) = xp;
> +  return x;
> +}

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.

Regards,
m

-- 
http://bodrato.it/papers/

___
gmp-devel mailing list
gmp-devel@gmplib.org
http://gmplib.org/mailman/listinfo/gmp-devel

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

[bodrato]

Ciao,

Il Gio, 28 Febbraio 2013 9:50 am, Torbjorn Granlund ha scritto:
> Richard Henderson  writes:
> We are at least aware of these things ("Calls and linkage"):
> https://gmplib.org/devel/GMPng.html

>   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.  :-)

Our own test-suite will let the first scream out !-D

The first thing to do IMO is to define the levels of visibility we need:
we have documented functions, functions that are not documented but are
used by other programs (we should probably document many of those),
functions and tables that are used both internally and by the test-suite
(would be nice to somehow hide them... is it possible?), functions and
tables for internal use only...
Next step, let the configure process define pertinent macros...

Then, the hiding/aliasing game can start :-)

Regards,
m

-- 
http://bodrato.it/software/

___
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]

On 2013-02-28 10:43:20 +0100, Torbjorn Granlund wrote:
> ni...@lysator.liu.se (Niels Möller) writes:
>   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.  :-)

I don't understand why changing the __ prefix to a gmp_ or libgmp_
namespace would be a problem.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
___
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]

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)?

[Niels Möller]

Torbjorn Granlund  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)?

[David Miller]

From: Torbjorn Granlund 
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: ARM Neon popcount

[Torbjorn Granlund]

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)?

[Torbjorn Granlund]

Richard Henderson  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