MPIR build and assembler used

[Jean-Pierre Flori]

Dear all,

It's not completely clear to me when which assembler is used at MPIR build time, i.e. when is it the shipped YASM, and when is it the system default assembler?
Could someone provide me some hints?
I'm asking cause I had to update the Sage's spkg hack we use and  which consists in deleting some asm files containing @GOT used in PIC code in order to build MPIR on Mac OS 10.4/5  where the Apple's AS doesn't understand this macro (or whatever this is).

Best,
JP

[Bill Hart]

Hi JP,

Yasm should only be used on x86 and x86_64. However, it is my
understanding that we long ago got rid of the necessity to delete asm
files for apple. We now have an mpn/x86/applenopic directory which is
used on these machines. So I think that patch can be removed from
Sage.

Bill.

> --
> You received this message because you are subscribed to the Google Groups
> "mpir-devel" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/mpir-devel/-/b4Z7yOYPxv8J.
> To post to this group, send email to mpir-...@googlegroups.com.
> To unsubscribe from this group, send email to
> mpir-devel+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/mpir-devel?hl=en.

[Jean-Pierre Flori]

On Monday, December 3, 2012 2:09:10 PM UTC+1, Bill Hart wrote:

Hi JP,

Yasm should only be used on x86 and x86_64. However, it is my
understanding that we long ago got rid of the necessity to delete asm
files for apple. We now have an mpn/x86/applenopic directory which is
used on these machines. So I think that patch can be removed from
Sage.

Strange because it seems it is still needed, see this post in particular on sage-devel:
https://groups.google.com/d/msg/sage-devel/R43tQAKI8gA/8uyBkY67Tu4J
Maybe the machine is not correctly detected?

[Jean-Pierre Flori]

With your hints I found
https://groups.google.com/forum/?fromgroups=#!msg/mpir-devel/iSzn88nJO58/4efX1gWB5kIJ

I'll ask for a full log on sage-devel.

[Bill Hart]

There's a lot of mention of PPC in that thread. Obviously the
applenopic stuff is for x86, not PPC. But then again, deleting the
assembly files wouldn't work there either.

So we really need the person who reported that to tell us the output
of ./config.guess. And of course to tell us if the problem still
happens when MPIR gets to choose the build target for itself.

Bill.

[leif]

Bill Hart wrote:
> There's a lot of mention of PPC in that thread. Obviously the
> applenopic stuff is for x86, not PPC. But then again, deleting the
> assembly files wouldn't work there either.
>
> So we really need the person who reported that to tell us the output
> of ./config.guess. And of course to tell us if the problem still
> happens when MPIR gets to choose the build target for itself.

According to his log, Apple's assembler bails out on divexact_1.s, which
is [made from] mpn/x86/divexact_1.asm (or x86/core2/divexact_1.asm),
which contains

...
ifdef(`PIC',`
call L(movl_eip_edx)
addl $_GLOBAL_OFFSET_TABLE_, %edx
movl modlimb_invert_table@GOT(%edx), %edx
movzbl (%eax,%edx), %eax C inv 8 bits
',`
dnl non-PIC
movzbl modlimb_invert_table(%eax), %eax C inv 8 bits
')
...

Unfortunately, -DPIC is passed to m4 on his system:


/bin/sh ../libtool --mode=compile --tag=CC ../mpn/m4-ccas --m4="m4"
/usr/bin/gcc-4.2 -std=gnu99 -c -DHAVE_CONFIG_H -m32 -O2
-fomit-frame-pointer -mtune=core2 -march=core2 -g -D__GMP_WITHIN_GMP
-I.. -DOPERATION_`echo divexact_1 | sed 's/_$//'` -I. -I.. `test -f
'divexact_1.asm' || echo './'`divexact_1.asm
libtool: compile: ../mpn/m4-ccas --m4=m4 /usr/bin/gcc-4.2 -std=gnu99 -c
-DHAVE_CONFIG_H -m32 -O2 -fomit-frame-pointer -mtune=core2 -march=core2
-g -D__GMP_WITHIN_GMP -I.. -DOPERATION_divexact_1 -I. -I..
divexact_1.asm -fno-common -DPIC -o .libs/divexact_1.o
m4 -DHAVE_CONFIG_H -D__GMP_WITHIN_GMP -DOPERATION_divexact_1 -DPIC
divexact_1.asm >tmp-divexact_1.s
/usr/bin/gcc-4.2 -std=gnu99 -c -DHAVE_CONFIG_H -m32 -O2
-fomit-frame-pointer -mtune=core2 -march=core2 -g -D__GMP_WITHIN_GMP
-I.. -DOPERATION_divexact_1 -I. -I.. tmp-divexact_1.s -fno-common -DPIC
-o .libs/divexact_1.o
tmp-divexact_1.s:119:junk `@GOT' after expression
make[2]: *** [divexact_1.lo] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
Error building MPIR.



-leif

> On 3 December 2012 13:19, Jean-Pierre Flori <jpf...@gmail.com> wrote:
>> With your hints I found
>> https://groups.google.com/forum/?fromgroups=#!msg/mpir-devel/iSzn88nJO58/4efX1gWB5kIJ
>>
>> I'll ask for a full log on sage-devel.
>

--
() The ASCII Ribbon Campaign
/\ Help Cure HTML E-Mail

[Bill Hart]

I assume you mean divexact_1.asm.

I don't think we set -DPIC anywhere, so I think this is an autotools
bug. How recent is the report? It might have been fixed by the latest
autotools upgrade that we did.

Bill.

> --
> You received this message because you are subscribed to the Google Groups
> "mpir-devel" group.

[Bill Hart]

Actually, in MPIR's aclocal.m4 there looks to be code to use -DPIC
only when it is meaningful.

Somewhere between lines 4433 and 4463 we can probably add something.

It looks like it does a test to make sure -DPIC actually works, which
for some reason passes on this platform.

Unfortunately, I don't know m4, so it is going to take me ages to fix
this issue. I'll add it to the todo list, but if anyone comes up with
a patch in the mean time, I'd be delighted.

Bill.

[Jean-Pierre Flori]

On Monday, December 3, 2012 3:55:50 PM UTC+1, Bill Hart wrote:

I assume you mean divexact_1.asm.

I don't think we set -DPIC anywhere, so I think this is an autotools
bug. How recent is the report? It might have been fixed by the latest
autotools upgrade that we did.

It's quite recent, from a few days ago, been tested with MPIR 2.6.0 (and 2.4.x with similar results).

To make things clear :
- this is with mac os 10.4 and 5 running in 32 bits mode on 64 bit intel hardware, so there is no PPC involved here,
- we do not set PIC in the sage spkg, nor does MPIR itself, so it seems that some autotools magic decide to add it by default,
- the problem is that MPIR then wants to use the corresponding asm files with PIC defined and these files use the @GOT construction that Apple's AS in this Mac OSes does not understand

Here is how we dealt with that before: delete all the problematic asm files, so that there is no @GOT anywhere and that did the trick.
According to Bill, and if I understood correctly, that should not be necessary because autotools should detect its building MPIR on Mac OS on intel hardware and should choose the x86/applenopic subdirectory rather than the files from the x86 toplevel or say from the x86/core2 subdirectory which contain the @GOT construction.
But that does not seem to be the case, files from other directories than the applenopic one are picked up here.

Not sure what to think of the PIC thing.
I guess it's quite natural that autotools tries to build PIC code by default if the system should be capable.
The problem here is really that it also chooses files in a wrong directory and in the case of PIC code, the assembly files in this directory contain instructions that the assembler does not understand.

[Jean-Pierre Flori]

On Monday, December 3, 2012 4:01:41 PM UTC+1, Bill Hart wrote:

Actually, in MPIR's aclocal.m4 there looks to be code to use -DPIC
only when it is meaningful.

Somewhere between lines 4433 and 4463 we can probably add something.

It looks like it does a test to make sure -DPIC actually works, which
for some reason passes on this platform.

Unfortunately, I don't know m4, so it is going to take me ages to fix
this issue. I'll add it to the todo list, but if anyone comes up with
a patch in the mean time, I'd be delighted.

Hmm, we cross-posted.

I don't think the -DPIC thing is the real issue, see below.

I think the report we got rather shows that:
- either the system it runs on is not correctly detected,
- or it is, but it is not one amongst the one for which x86/* is replaced by x86/applenopic.

[leif]

Bill Hart wrote:
> I assume you mean divexact_1.asm.

?

> I don't think we set -DPIC anywhere, so I think this is an autotools
> bug.

Presumably... ;-)

> How recent is the report? It might have been fixed by the latest
> autotools upgrade that we did.

Well, the log is from an attempt to build Sage 5.4.1, which ships with
MPIR 2.4.0[.p6.spkg], a few hours old IIRC...

I actually haven't looked into the 2.6.0 sources, although I don't
expect changes there (to the relevant asm files). The behavior appears
to be the same with 2.4.0 and JP's 2.6.0 (I think).

[Jean-Pierre Flori]

On Monday, December 3, 2012 4:14:45 PM UTC+1, leif wrote:

Bill Hart wrote:
> I assume you mean divexact_1.asm.

?


> I don't think we set -DPIC anywhere, so I think this is an autotools
> bug.

Presumably... ;-)

Not sure it is really a problem that PIC gets defined, although I must although admit I don't no if PIC code makes sense on Mac OS system or if they are able to produce such code.
If by default autotools wants to define PIC code, why not, it even seems a good choice to me.

For me the problem is that some asm file which contains code (related to PIC indeed) and that the Apple's AS does not understand, gets picked up whereas it should not.

Preventing PIC from being defined would solve the problem, but it looks like a hack for me.

> How recent is the report? It might have been fixed by the latest
> autotools upgrade that we did.

Well, the log is from an attempt to build Sage 5.4.1, which ships with
MPIR 2.4.0[.p6.spkg], a few hours old IIRC...

I think the sage report is with MPIR 2.4.x (first report without log) and 2.6.0 (updated report at our request) as well

I actually haven't looked into the 2.6.0 sources, although I don't
expect changes there (to the relevant asm files).  The behavior appears
to be the same with 2.4.0 and JP's 2.6.0 (I think).

Indeed, no changes in these files.

-leif

[leif]

Jean-Pierre Flori wrote:
>
>
> On Monday, December 3, 2012 3:55:50 PM UTC+1, Bill Hart wrote:
>
> I assume you mean divexact_1.asm.
>
> I don't think we set -DPIC anywhere, so I think this is an autotools
> bug. How recent is the report? It might have been fixed by the latest
> autotools upgrade that we did.
>
> It's quite recent, from a few days ago, been tested with MPIR 2.6.0 (and
> 2.4.x with similar results).
>
> To make things clear :
> - this is with mac os 10.4 and 5 running in 32 bits mode on 64 bit intel
> hardware, so there is no PPC involved here,
> - we do not set PIC in the sage spkg, nor does MPIR itself, so it seems
> that some autotools magic decide to add it by default,

Presumably. The problem is (at least) that it gets passed to m4 as
well. [Not sure whether divexact_1 is incidentally just the *first*
file (of probably a couple) Apple's as bails out.]

> - the problem is that MPIR then wants to use the corresponding asm files
> with PIC defined and these files use the @GOT construction that Apple's
> AS in this Mac OSes does not understand

Not sure. Did you see his full log (i.e., the setting of MPN_PATH)?

Note that there's no version of divexact_1 in the mpn/applenopic path,
so [either mpn/x86/core2/divexact_1.asm or] mpn/x86/divexact_1.asm is
chosen, no matter what.

Both files contain conditional code, depending on the setting of the
(m4) PIC macro. The error is apparently caused by autotools passing
-DPIC[=1] to *m4*.

> Here is how we dealt with that before: delete all the problematic asm
> files, so that there is no @GOT anywhere and that did the trick.
> According to Bill, and if I understood correctly, that should not be
> necessary because autotools should detect its building MPIR on Mac OS on
> intel hardware and should choose the x86/applenopic subdirectory rather
> than the files from the x86 toplevel or say from the x86/core2
> subdirectory which contain the @GOT construction.
> But that does not seem to be the case, files from other directories than
> the applenopic one are picked up here.

See above. MPN_PATH (almost) always contains multiple directories, the
files/implementations from the first which contains a
file/implementation get chosen.

> Not sure what to think of the PIC thing.
> I guess it's quite natural that autotools tries to build PIC code by
> default if the system should be capable.
> The problem here is really that it also chooses files in a wrong
> directory and in the case of PIC code, the assembly files in this
> directory contain instructions that the assembler does not understand.

Nope, I don't think so. (That's at least not the case for divexact_1.)


As a temporary hack for the spkg, we could just patch out the
conditional "manually" (as if PIC was set to zero) when building on that
platform. Or invalidate -DPIC for m4 by other means... (m4-ccas script?)

As mentioned, not sure whether it's just the *first* error Apple's as
raises, but my guess is no. [Passing -DPIC to GCC doesn't hurt I think,
as it knows how to properly handle that.]


-leif

[Bill Hart]

Just to clarify, MPIR can pick up files from x86 even on Apple 32. But these all have alternative code paths depending whether -DPIC is passed or not. So -DPIC must not be passed on this system.

The only correct fix here is to fix aclocal.m4 to not add -DPIC to the list of options on this system.

Bill.

[Jean-Pierre Flori]

On Monday, December 3, 2012 5:06:43 PM UTC+1, Bill Hart wrote:

Just to clarify, MPIR can pick up files from x86 even on Apple 32. But these all have alternative code paths depending whether -DPIC is passed or not. So -DPIC must not be passed on this system.

Ok now I'm confused.
What's the point of the applenopic directory?
The files it contains are all exact copies  of the one from x86, except for some tuning parameters in headers, and for the fact that files which contains things depending on PIC are not present?
It's true as well for the core2 subdirs.

I though that the applenopic was then meant to completely replace the x86 one.
If the x86 one is looked at as fallback, the applenopic seems quite useless.

To unsubscribe from this group, send email to mpir-devel+unsubscribe@googlegroups.com.

[Jean-Pierre Flori]

And I don't understand why PIC should not be defined on such systems.
I don't consider that "it makes the build fail because files which cannot be compiled get picked" is not a good answer in my mind.
Doing "if we set PIC, it fails, so lets undefine PIC at some depth so that is works" seems like a workaround, not a proper fix.

You may want PIC code, and it may or may not make sense on different systems.
As far as I understand, on the problematic you can produce PIC code, its just that the assembler does not like some instructions that the MPIR build system feeds it with.
So you should be able to let PIC be defined and the job of the build system is to pick files without  not understandable instructions, not to undefine PIC somewhere in between so that in the problematic files it gets uses the not PIC branches of the tests.

Moreover, do these non PIC branches become PIC on the problematic system whereas they are not on other systems?
That looks kind of magical (but as I'm not an assembly hacker, far from that, in fact I must admit I know nothing), or would mean there is no need for the tests from the beginning whatever the system is (that seems less magical but senseless)?
So in fact undefining PIC at some point and pretending the produced files are PIC might lead to further problems.

[Bill Hart]

Well that certainly reveals one possible way around the problem, namely to preprocess the other needed files so they only follow the nopic path then put them in the applenopic directory.

I'm not sure why they aren't all there in the first place. If as you say, the files that are there are just preprocessed versions of the other files, then that doesn't make sense. But then, the applenopic directory also makes no sense in that case to me. Why not just fix the -DPIC thing in aclocal.m4?

Bill.

[Jean-Pierre Flori]

Further info:
- the result of ./config.guess is nehalem-apple-darwin9.8.0, which is not one dealt with in MPIR configure.in for the "32 bit apple darwin doesn't like our PIC format asm code".
- and so we get MPN_PATH=" x86/nehalem x86 generic"

[Jean-Pierre Flori]

On Monday, December 3, 2012 5:38:17 PM UTC+1, Bill Hart wrote:

Well that certainly reveals one possible way around the problem, namely to preprocess the other needed files so they only follow the nopic path then put them in the applenopic directory. 

I'm not sure why they aren't all there in the first place. If as you say, the files that are there are just preprocessed versions of the other files, then that doesn't make sense. But then, the applenopic directory also makes no sense in that case to me. Why not just fix the -DPIC thing in aclocal.m4?

Maybe the idea was to create a directory without the bad files and only use this directory instead of the x86 one.
I still insists but for me the PIC flag should only be used to decide wether we want PIC or not PIC flag, and that's a choice the user made.
It should not be undefed by the build system to rule out the inclusion of files which will kill the assembler.
And once again the problem is not the ability of producing PIC code, its really the ability of understanding a macro used by MPIR in a PIC branch: so I don't think that because in some PIC branch we don't understand some isntruction, then the solution is not to try at all.
In that sense, what I feel the original purpose of the new applenopic directory was makes more sense.

[Bill Hart]

Ah, well that almost certainly has something to do with it.

Could we try adding that option in the relevant part of configure.in,
run autoreconf -i on eno and see if that does the trick on his system.

Unfortunately I cannot issue a new version of MPIR for this. We are
stuck at 2.6.0 until we add a certain function required by another
library (they already added the test for library version in
anticipation).

At some point I could add a diff patch to the website which can be
applied to fix this issue. And of course it will get merged into the
next release.

Bill.

[Bill Hart]

The assembler here is gas, not yasm, and it doesn't allow GOT
addressing. Thus, I would say the system is not PIC capable.

It is possible to write the assembly files in another style which
doesn't require jumping into the middle of a loop, and that obviates
the need to use the GOT. But I wouldn't say that makes the system PIC
capable.

Bill.

>>>>> mpir-devel+...@googlegroups.com.

[Jean-Pierre Flori]

On Monday, December 3, 2012 5:48:40 PM UTC+1, Bill Hart wrote:

Ah, well that almost certainly has something to do with it.

Could we try adding that option in the relevant part of configure.in,
run autoreconf -i on eno and see if that does the trick on his system.

I don't have access to eno (or skynet in general), so I can't.
I've given instruction on sage-devel to update configure.in and recraft a new spkg.
If not I'll do that myself on some other computer hoping it works and send an spkg with an updated MPIR.

Unfortunately I cannot issue a new version of MPIR for this. We are
stuck at 2.6.0 until we add a certain function required by another
library (they already added the test for library version in
anticipation).

That's not a real problem, I think that the problem went unnoticed for some years.
It's just when I explicitly asked someone to test this setup on sage-devel that the issue came back.

[Jean-Pierre Flori]

On Monday, December 3, 2012 5:55:38 PM UTC+1, Bill Hart wrote:

The assembler here is gas, not yasm, and it doesn't allow GOT
addressing. Thus, I would say the system is not PIC capable.

You mean GNU as?
I though all the GOT problem was that it understood @GOT but the Apple as (surely derivated from the previous one) did not.

[leif]

... then the -march=core-i7 was pretty correct.

Who t** f*** runs a 32-bit operating system on such a machine? (Dual
quad-core Xeon even IIRC) ;-)

[Jean-Pierre Flori]

On Monday, December 3, 2012 6:13:57 PM UTC+1, leif wrote:

Jean-Pierre Flori wrote:
> Further info:
> - the result of ./config.guess is nehalem-apple-darwin9.8.0, which is
> not one dealt with in MPIR configure.in for the "32 bit apple darwin
> doesn't like our PIC format asm code".
> - and so we get MPN_PATH=" x86/nehalem x86 generic"

... then the -march=core-i7 was pretty correct.

Who t** f*** runs a 32-bit operating system on such a machine?  (Dual
quad-core Xeon even IIRC) ;-)

I agree :)
And that's the reason nobody complained until we explicitely pushed people to do so :)

[Bill Hart]

Yes, I guess it is Apples version of as.

Bill.

[leif]

Jean-Pierre Flori wrote:
>
>
> On Monday, December 3, 2012 6:13:57 PM UTC+1, leif wrote:
>
> Jean-Pierre Flori wrote:
> > Further info:
> > - the result of ./config.guess is nehalem-apple-darwin9.8.0,
> which is

> > not one dealt with in MPIR configure.in <http://configure.in> for

> the "32 bit apple darwin
> > doesn't like our PIC format asm code".
> > - and so we get MPN_PATH=" x86/nehalem x86 generic"
>
> ... then the -march=core-i7 was pretty correct.
>
> Who t** f*** runs a 32-bit operating system on such a machine? (Dual
> quad-core Xeon even IIRC) ;-)
>
> I agree :)
> And that's the reason nobody complained until we explicitely pushed
> people to do so :)

Well, YOU asked for it, so it's definitely your fault... ;-)

[Bill Hart]

Time to apply the crumb test to JP's beard with a fine-toothed comb!

By the way, shouldn't Sage be a little faster on my Amstrad PC1512?

Bill.

> --
> You received this message because you are subscribed to the Google Groups
> "mpir-devel" group.
> To post to this group, send email to mpir-...@googlegroups.com.
> To unsubscribe from this group, send email to

> mpir-devel+...@googlegroups.com.

[Jean-Pierre Flori]

In fact I just wanted to get rid of the dirty piece of code in sage spkg install script and hoped that nobody would actually answer on sage-devel so that the removal gets undetected.

[Bill Hart]

Yeah I know. I had the same hope of course.

I just hope this won't affect any 64 bit Darwinphiles.

Bill.

[leif]

Jean-Pierre Flori wrote:
> On Monday, December 3, 2012 6:35:15 PM UTC+1, Bill Hart wrote:
>
> Time to apply the crumb test to JP's beard with a fine-toothed comb!
>
> By the way, shouldn't Sage be a little faster on my Amstrad PC1512?
>
> Bill.
>

> On 3 December 2012 17:29, leif <not.r...@online.de <javascript:>>

> wrote:
> > Jean-Pierre Flori wrote:
> >>
> >>
> >>
> >> On Monday, December 3, 2012 6:13:57 PM UTC+1, leif wrote:
> >>
> >> Jean-Pierre Flori wrote:
> >> > Further info:
> >> > - the result of ./config.guess is nehalem-apple-darwin9.8.0,
> >> which is
> >> > not one dealt with in MPIR configure.in

> <http://configure.in> <http://configure.in> for

> >>
> >> the "32 bit apple darwin
> >> > doesn't like our PIC format asm code".
> >> > - and so we get MPN_PATH=" x86/nehalem x86 generic"
> >>
> >> ... then the -march=core-i7 was pretty correct.
> >>
> >> Who t** f*** runs a 32-bit operating system on such a
> machine? (Dual
> >> quad-core Xeon even IIRC) ;-)
> >>
> >> I agree :)
> >> And that's the reason nobody complained until we explicitely pushed
> >> people to do so :)
> >
> >
> > Well, YOU asked for it, so it's definitely your fault... ;-)
> >
> >
> >
> > -leif
>

> In fact I just wanted to get rid of the dirty piece of code in sage spkg
> install script and hoped that nobody would actually answer on sage-devel
> so that the removal gets undetected.

How about changing

# 32bit apple darwin doesn't like our PIC format asm code
case $host in
core2-apple-darwin* | penryn-apple-darwin*)
path="x86/applenopic/core2 x86/applenopic" ;;
prescott-apple-darwin* | pentium4-apple-darwin*)
path="x86/applenopic" ;;
pentium3-apple-darwin* | pentium2-apple-darwin*)
path="x86/applenopic" ;;
i686-apple-darwin* | pentiumpro-apple-darwin*)
path="x86/applenopic" ;;
core-apple-darwin*)
path="x86/applenopic" ;;
*) ;;
esac

to just

# 32bit apple darwin doesn't like our PIC format asm code
case $host in
core2-apple-darwin* | penryn-apple-darwin*)
path="x86/applenopic/core2 x86/applenopic" ;;
*-apple-darwin*)
path="x86/applenopic" ;;
*) ;;
esac

? (As far as I can see, the above snippet is in the x86/x86_64 (and
32-bit OS/ABI) branch, so we don't have to deal with other archs than
these there.)

Otherwise the build will (sooner or later) fail in exactly the same way
on newer CPUs on 32-bit Darwin.

Btw, it would probably be better to use the applenopic/core2 path on any
post-Core2 CPU as well. Then we'd have to invert the logic, such that
the x86/applenopic/core2 path is *not* chosen / added on
i[34567]86-|pentium*-|prescott-|core- (all with 'apple-darwin*'
appended), but on everything else, hoping that the former list is
complete. (We won't have to add CPUs to that list as time goes by, in
contrast to the post-Core2 list.)


For the sake of Sage, it's probably better to patch MPIR 2.6.0's
'configure' (i.e., the *generated* file) rather than 'configure.in'
(autoreconfing afterwards, which usually causes lots of file changes)
until 2.6.1 (with such a fix) is out.

[Jean-Pierre Flori]

It should be ok thanks to Jeroen spkg which choose the same version autotools as the one used, so producing minimal diffs.

[Jean-Pierre Flori]

I think its a good idea.
In fact, as I autoreconfed MPIR, now config.guess spits i386... instead of nehalem-... before and of course this was not caught by the updated configure and I had to craft a new spkg for testing (in which I put *-apple-darwin* just to be sure to get everything).

[leif]

> <http://configure.in>'

> (autoreconfing afterwards, which usually causes lots of file changes)
> until 2.6.1 (with such a fix) is out.
>
>
> It should be ok thanks to Jeroen spkg which choose the same version
> autotools as the one used, so producing minimal diffs.

Well, in general even small changes to the autoconf source files can
result in huge diffs for the generated files, no matter whether you're
using the exact same versions of autotools (including libtool) or not.

But if that's not the case here, I won't object patching the whole
source tree in 'spkg-install'.

[Bill Hart]

You can make that change if you want, but obviously it will slow things down for the many 32 bit apple users out there.

I have no problem with that though, as they obviously don't care about speed.

Patching configure only in sage seems ok. I doubt the diff will be large. Probably a handful of lines. It shouldn't change any other files as far as I'm aware.

Bill.

[Bill Hart]

autoreconf -I should not have changed the output of config.guess. Something has gone very wrong.

We supply our own config.guess as the generic one is useless for MPIR

Bill.

--

You received this message because you are subscribed to the Google Groups "mpir-devel" group.

To view this discussion on the web visit https://groups.google.com/d/msg/mpir-devel/-/sIIBdcS7TmcJ.

[Bill Hart]

I mean autoreconf -i. Stupid predictive texting. Since when was -I in the dictionary!

[leif]

Bill Hart wrote:
> You can make that change if you want, but obviously it will slow things
> down for the many 32 bit apple users out there.
>
> I have no problem with that though, as they obviously don't care about
> speed.

:-)

That's why I also suggested inverting the logic:

# 32bit apple darwin doesn't like our PIC format asm code
case $host in

i[34567]86-apple-darwin*|
pentium*-apple-darwin*|
prescott-apple-darwin*|
core-apple-darwin*)
path="x86/applenopic" ;;
*-apple-darwin*) # assume Core2 or later
path="x86/applenopic/core2 x86/applenopic" ;;
*) ;;
esac


Not sure whether we also have to add some old AMDs as well. (Reading
config.guess would perhaps enlight me... Although AFAIK Apple only used
Opterons in some machines, which hopefullyTM run 64-bit MacOS only.)


-leif

> i[34567]86-|pentium*-|__prescott-|core- (all with 'apple-darwin*'

> appended), but on everything else, hoping that the former list is
> complete. (We won't have to add CPUs to that list as time goes by,
> in contrast to the post-Core2 list.)
>
>
> For the sake of Sage, it's probably better to patch MPIR 2.6.0's
> 'configure' (i.e., the *generated* file) rather than 'configure.in

> <http://configure.in>' (autoreconfing afterwards, which usually

> causes lots of file changes) until 2.6.1 (with such a fix) is out.
>
>
> -leif
>
> --
> () The ASCII Ribbon Campaign
> /\ Help Cure HTML E-Mail
>
> --
> You received this message because you are subscribed to the Google
> Groups "mpir-devel" group.
> To post to this group, send email to mpir-...@googlegroups.com.
> To unsubscribe from this group, send email to
> mpir-devel+...@googlegroups.com.
> For more options, visit this group at

> http://groups.google.com/__group/mpir-devel?hl=en
> <http://groups.google.com/group/mpir-devel?hl=en>.

[Bill Hart]

It just occurred to me you probably want to run autoconf only if it changes more than configure.

[Bill Hart]

On 3 December 2012 19:39, leif <not.r...@online.de> wrote:
> Bill Hart wrote:
>>
>> You can make that change if you want, but obviously it will slow things
>> down for the many 32 bit apple users out there.
>>
>> I have no problem with that though, as they obviously don't care about
>> speed.
>
>
> :-)
>
> That's why I also suggested inverting the logic:

That won't be necessary as of later tonight (hopefully). I have been
writing a new "littlenum" library in C++ for people who require such
performance tradeoffs. It is guaranteed that this new library will be
sufficient for all 32 bit Apple user's needs. I'll put it up on my
github later tonight and announce it on mpir-devel, so stay tuned.

I think I will call the library SLOWMATH (Super Ludicrously Optimised
Werkzeug). I currently call it SIMPLE (stupidly implemented
mathematics platform light edition), but that just doesn't have the
right ring to it.

Anyway, I best get back to it. I still have more than 30 functions to
write before it is done! And I need some timing comparisons with MPIR
before I can be truly happy...

Bill.

[leif]

Bill Hart wrote:
> On 3 December 2012 19:39, leif <not.r...@online.de> wrote:
>> Bill Hart wrote:
>>>
>>> You can make that change if you want, but obviously it will slow things
>>> down for the many 32 bit apple users out there.
>>>
>>> I have no problem with that though, as they obviously don't care about
>>> speed.
>>
>>
>> :-)
>>
>> That's why I also suggested inverting the logic:
>
> That won't be necessary as of later tonight (hopefully). I have been
> writing a new "littlenum" library in C++ for people who require such
> performance tradeoffs. It is guaranteed that this new library will be
> sufficient for all 32 bit Apple user's needs. I'll put it up on my
> github later tonight and announce it on mpir-devel, so stay tuned.

Probably best to use popen("bc ...") in the C functions (and parse its
output). Alternatively call Python instead of bc, which might perform
even "better". And/or implement the functions operating on single limbs
with shell scripts using 'expr'.


-leif

[Bill Hart]

Damn, I just did my first timing, and I have completely failed. Adding
100M integers together results in times just about identical with the
assembly optimised version of MPIR and significantly faster than the
generic C version.

I have failed woefully.

Bill.

[Bill Hart]

Perhaps I can redeem myself. The code contains such gems of clarity as:

if ((*this).nat_t::operator<(b))
{
r = znat_t(b.nat_t::operator-(*this));
r.sign = b.sign;
} else

Don't ya just gotta love C++.

Bill.

[Jean-Pierre Flori]

On Monday, December 3, 2012 7:10:47 PM UTC+1, Bill Hart wrote:

Yeah I know. I had the same hope of course.

I just hope this won't affect any 64 bit Darwinphiles.

To conclude this thread, correctly detecting the system fixed the issue, so I think leif solution is the one we need.
Indeed, with it, we get:
MPN_PATH=" x86/applenopic generic"
so the x86 dir is not used and the purpose of the applenopic seems to be to replace the x86 dir without files involving PIC.

[Bill Hart]

That's great. Thanks for the report and your hard work tracking this
down! I have added this issue to the mpir todo list, to be sorted out
once the next release it done.

As you will see from my announcement on mpir-devel, I have been
distracted by something else for a couple of days. :-)

Bill.

[Jean-Pierre Flori]

On Monday, December 3, 2012 11:58:39 PM UTC+1, Bill Hart wrote:

That's great. Thanks for the report and your hard work tracking this
down! I have added this issue to the mpir todo list, to be sorted out
once the next release it done.

As you will see from my announcement on mpir-devel, I have been
distracted by something else for a couple of days. :-)

Bill.

I saw that!

To finish with the applenopic stuff, last reports from sage-devel:
https://groups.google.com/d/msg/sage-devel/R43tQAKI8gA/UW4SKqk5oVcJ
seem to indicate that the problem is really not with PIC code, but just the @GOT construction.
Putting back the asm files involving specific PIC branches but not using @GOT in the applenopic directory (IIRC it is add_n.asm and sub_n.asm) does not prevent MPIR to build, nor to pass its test suite.
So maybe we should rename the directory to applenogot and put the few files back in :)
Not that anybody will really care about the performance difference if there is any.

As I said, I've no experience in asm/PIC programming so cannot really say this analysis is right, but that's just experimental guesses.

Best,
JP

[Bill Hart]

Thanks very much for the report.

I'm not sure what they mean by PIC specific. But glad to hear it
worked for them.

Bill.