And constructor too restrictive on immediates

[dvanhorn]

The And constructor (and Or, etc) requires an immediate to be at most 32-bits, but it checks this property incorrectly, basically checking the integer as a 32-bit signed integer (thus 31-bits + sign). This means, e.g. #xFFFFFFFF is rejected even though (32-bit-integer? #xFFFFFFFF) produces #t. A better check would be that the argument is either a 32-bit non-negative integer or a negative 31-bit integer, which is exactly what 32-bit-integer? recognizes.

[dvanhorn]

OK so I have a potential fix, but the problem is that clang interprets whether something is signed or unsigned based on the base you use(!). So even though #xFFFFFFF0 and 4294967280 are the same number, if you write and rax, 4294967280, clang will error saying the number is too big for 32-bits, but and rax, 0xFFFFFFF0 is totally fine and does what you expect here, which is equivalent to and rax, -16. UGGH. This really sucks because from Racket's POV the numbers actually read as the same, so the only way to get a sensible and consistent semantics here is to always print in hex.

[dvanhorn]

Just to make matters worse, clang supports the C-style u suffix to indicate unsigned literals, but it still rejects 4294967280u while accepting 0xFFFFFFF0.