Is there any good reason for why GMP does this?

[ShiningArcanine]

I was browsing gmp's powm_ui.c file in its generic C library. After dechipering it enough to understand part of what it is doing, I noticed the following lines:

Originally Posted by GMP

e = el;
count_leading_zeros (c, e);
e = (e << c) << 1; /* shift the exp bits to the left, lose msb */
c = BITS_PER_MP_LIMB - 1 - c;

Is there any good reason why this is not:

count_leading_zeros (c, el);
e = (el << ++c); /* shift the exp bits to the left, lose msb */
c = BITS_PER_MP_LIMB - c;

[jasonp]

My guess is the code is as written because the C standard does not specify what happens to shifts when the shift amount exceeds the bits in a word. For a 32-bit machine, if x is 1 then c is 31 and (x << c) << 1 will be zero, as expected. However, the result of x << (c+1) depends on the processor. x86 machines only look at the bottom 5 bits of the shift amount, so x << 32 becomes x. 32-bit powerPC looks at the bottom 6 bits, so x << 32 is zero.

Variable shifts are a challenge to portable code that many C programmers are not aware of.

[ShiningArcanine]

Wow, you are right. I had no idea that the shifts were different on different platforms.

I guess this makes my question why GMP does not use preprocessor definitions to give x86 machines the slow workaround code and other machines the fast code.