#include <stdio.h>
#include <stdlib.h>

int main(int argc,char **argv)
{
  int size = atoi(argv[1]);
  unsigned long pow2 = ((unsigned long)1)<<size;
  unsigned long bits1 = pow2-1;
  unsigned long bits2 = (((unsigned long)1)<<size)-1;
  printf("%d %d %08lx %08lx %08lx\n",
    (int)sizeof(unsigned long),size,pow2,bits1,bits2);
  return 0;
}

*test 32 (or seemingly any other value >=32)
4 32 00000000 ffffffff ffffffff
*test -1 (or seemingly any other value <=-1)
4 -1 00000000 ffffffff ffffffff

$ ./test 32
4 32 00000001 00000000 00000000
$ ./test 33
4 33 00000002 00000001 00000001
(etc.)
$ ./test -1
4 -1 80000000 7fffffff 7fffffff
$ ./test -2
4 -2 40000000 3fffffff 3fffffff
(etc.)

And after searching around a bit, it looks like it's the fault of the C standard, whereby out-of-range shifts have undefined behaviour. Grr!

And after searching around a bit, it looks like it's the fault of the C standard, whereby out-of-range shifts have undefined behaviour. Grr!

Does it warn you if you shift by a too large constant?

One of the most obscure bits of ARM minutiae I've ever encountered. I have no idea why they designed it like that.

I found out not too long ago - while attempting to untangle some code which it emerged was relying on this behaviour - that ARM does indeed have a similar problem with out-of-range shifts to x86. The difference is that the cut-off point is bit 8, not bit 5. So shifting left by any value between 32 and 255 will produce zero, just as you'd expect, but when you reach 256 it suddenly wraps around.

One of the most obscure bits of ARM minutiae I've ever encountered. I have no idea why they designed it like that.

Just spotted these unpredictable instructions in Fire & Ice, I'm not sure which C compiler version it was created under though:

I've yet to get it into the game, so haven't come across that lovely sequence yet...however I was considering adding fixup code when the JIT hits a certain address - you've highlighted that that's actually a good idea.

There should be a NOP between those instructions, as the CPU isn't guaranteed to be in SVC at the time (I think it's in UND).

Martin : some (partial) good news for you, I hope ... soon.

The C compiler has appended "rcc 3.00" to the end of the file.