We already know that 2147483648 % 7559=1984 so w31 is out. However PEAC63 still passes the sieve so it could be a good candidate. The question is : how good ?

PEAC63 is equivalent to 126 bits of signature, the MSB work as carry bits so we get 128 bits just after the additions. There is quite little mixing so hashing is out of question but it's still very good for rough checksumming of files on a 64-bit platform, using 32-bit data at every cycle. Furthermore, it's not very different at all from the existing code. Getting bit 63 maybe done by sign extension or simply a shift, or even testing the sign bit of an unsigned number.

Another funky thing to test is whether clearing the MSB/sign bit after it's copied back to the LSB, would affect the orbit's size. NOT clearing the MSB could save one operation and at this stage, it's pretty critical. Though with modern CPUs with OOO, it could not matter so much. So it must be tested.

But exhaustive scans are out of question. I should run a sequential scan on the primary orbit, for the sake of it, but 2^126 states is not realistic, not even parallelizeable because even an arc is larger than the 2^52 states of PEAC26. That's why the sieve was so critical...

The code would go like this:

#define WIDTH (63)
#define MASK (0x7FFFFFFFFFFFFFFFULL)

uint64_t C, X, Y;
uint32_t data;

C += X + Y;
Y = X + (uint64_t)data;
X = C & MASK;  <= can we remove this ?
C = C >> WIDTH;

I'm not sure of the numerical properties but that code looks damn fast, with few instructions and able to gobble 32 bits at once per cycle. Fingers crossed.