Sr2sieve on PPC/Linux

[BlisteringSheep]

FYI, sr5sieve-1.5.8 passes the sr5check test.

Thanks for the clarification on the command-line.txt option. Using that is easier for me in one way because I can create finer grained ranges (I never have the same number of CPUs to run with, so I can't get even splits on G boundaries when divying up ranges).

1.5.9 doesn't compile when EXPERIMENTAL is set to 1. I get errors starting with:
gcc412 -O3 -ffast-math -mtune=G5 -mcpu=970 -m64 -fomit-frame-pointer -maltivec -mabi=altivec -Wall -Xassembler -mregnames -DDEFAULT_L1_CACHE_SIZE=32 -DDEFAULT_L2_CACHE_SIZE=512 -DUSE_ASM -DUSE_INLINE_MULMOD -DNDEBUG -c -o bsgs.o bsgs.c
bsgs.c: In function 'climb_ladder_2':
bsgs.c:603: error: impossible register constraint in 'asm'

I've attached the full error list. I get the same errors with gcc-3.4.6.

[geoff]

Originally Posted by BlisteringSheep

bsgs.c:603: error: impossible register constraint in 'asm'

This is probably to do with the condition registers. I will write a version that uses fixed registers cr4, cr5, cr6, cr7 instead of trying to get GCC to choose them. Until then you could try changing the definition of CONDITION_REGISTER_T from `uint64_t' to `char', or `int' and see if it makes a difference.

[BlisteringSheep]

Originally Posted by geoff

Until then you could try changing the definition of CONDITION_REGISTER_T from `uint64_t' to `char', or `int' and see if it makes a difference.

That changed some of the specific values in the error messages, but the errors are still all the same.

[rogue]

Originally Posted by geoff

GCC doesn't know that addze depends on adde, it might reorder these operations or schedule another instruction between them that clobbers the carry flag. I don't think there is a way to tell GCC about the dependancy, so it is necessary to combine both instructions into one asm().

If gcc does, then it would be very easy to write an inline function that combines those two instructions and only those two. The point is that it is easier to write the C code than the ASM code and it is easier for anyone looking at the code to understand. Unless gcc screws up the optimization, there should be little if any cost to writing the mulmod in C.

Originally Posted by geoff

In version 1.5.9 I have tried to use the idea from this code to modify the existing code. Set EXPERIMENTAL to 1 in asm-ppc64.h to enable it. The definition for CONDITION_REGISTER_T might need to be changed. I have also fixed the malloc.h issues for OS X.

I have same same problems as BlisteringSheep with compiling.

Originally Posted by geoff

How many condition registers does the PPC64 have?

8

[geoff]

I think I know what caused the compile errors in verison 1.5.9 -- register "cc" refers to all condition registers, not just cr0. I think if you replaced each "cc" with "cr0" then it would compile.

In version 1.5.10 I have used fixed condition registers instead of getting GCC to choose which ones to use. There are two options in asm-ppc64.h: EXPERIMENTAL=1 uses just one condition register for all conditional branches, EXPERIMENTAL=2 uses up to 4 condition registers.

[BlisteringSheep]

With EXPERIMENTAL set to 1 or 2:


gcc412 -O3 -ffast-math -mtune=G5 -mcpu=970 -m64 -fomit-frame-pointer -maltivec -mabi=altivec -Wall -Xassembler -mregnames -DDEFAULT_L1_CACHE_SIZE=32 -DDEFAULT_L2_CACHE_SIZE=512 -DUSE_ASM -DUSE_INLINE_MULMOD -DNDEBUG -c -o bsgs.o bsgs.c
bsgs.c: In function 'baby_steps_4':
bsgs.c:263: error: expected string literal before ')' token
bsgs.c: In function 'baby_steps_1':
bsgs.c:340: error: expected string literal before ')' token
bsgs.c: In function 'giant_steps_1':
bsgs.c:511: error: expected string literal before ')' token
bsgs.c: In function 'climb_ladder_4':
bsgs.c:617: error: expected string literal before ')' token
bsgs.c: In function 'climb_ladder_1':
bsgs.c:659: error: expected string literal before ')' token
bsgs.c: In function 'setup64':
bsgs.c:763: error: expected string literal before ')' token
bsgs.c:796: error: expected string literal before ')' token
bsgs.c:848: error: expected string literal before ')' token
make: *** [bsgs.o] Error 1

[BlisteringSheep]

The output from the preprocessor for the part of baby_steps_4() with the error:

  for (j = 0; j < 3; j++)
    BJ64[j+1] = ({ register uint64_t ret, s, t; asm ("mulhdu  %0, %8, %3" "\n\t" "mulld   %1, %9, %3" "\n\t" "mulhdu  %2, %9, %3" "\n\t" "adde    %1, %0, %1" "\n\t" "addze   %2, %2" "\n\t" "srd     %1, %1, %6" "\n\t" "sld     %2, %2, %7" "\n\t" "or      %1, %1, %2" "\n\t" "mulld   %0, %3, %4" "\n\t" "mulld   %2, %1, %5" "\n\t" "sub     %0, %0, %2" "\n\t" "cmpdi   cr6, %0, 0" "\n\t" "bge+    cr6, 0f" "\n\t" "add     %0, %0, %5" "\n" "0:" : "=&r" (ret), "=&r" (s), "=&r" (t) : "r" (BJ64[j]), "r" (b), "r" (p), "r" (pShift), "r" (64-pShift), "r" (bLO), "r" (bHI) : "cr0", "cr6", ); ret; });

[geoff]

Originally Posted by BlisteringSheep

bsgs.c:263: error: expected string literal before ')' token

This probably just means there is a missing quote, comma, etc. somewhere :-( I will have a look now and see if I can spot it.

[BlisteringSheep]

As best as I can see, it's complaining because after preprocessing, the last line of the assembly code:

       : "r7", "r8", "r9", "r10", "cr0", "cr6" ); \

is getting turned in to:

"r" (bLO), "r" (bHI) : "cr0", "cr6", ); ret; });

which ends up with a comma between "cr6" and the closing parentheses.

[geoff]

Originally Posted by BlisteringSheep

As best as I can see, it's complaining because after preprocessing, the last line of the assembly code:

       : "r7", "r8", "r9", "r10", "cr0", "cr6" ); \

is getting turned in to:

"r" (bLO), "r" (bHI) : "cr0", "cr6", ); ret; });

which ends up with a comma between "cr6" and the closing parentheses.

Yes the following line in asm-ppc64.h is a problem, try removing the trailing comma:

       : "cr0", "cr6", ); \

[BlisteringSheep]

The difficulty for me is that the trailing comma isn't in asm-ppc64.h; it's in the preprocessed code. I can't see what it is in asm-ppc64.h that is causing it to appear after preprocessing.

Never mind. I found it (I was looking in the wrong place).