4 ms·
The x86 shift instructions do the same, so I'd guess that's why the JVM does it that way.
by taejo 11y ago
The x86 shift instructions do the same, so I'd guess that's why the JVM does it that way.
- thaumasiotes 11y agoSure, the JVM can use a 5-bit value for doing shifts on 32-bit integers, there's no problem there. But why would Java compile "x << 37" to "x << 5"? If you're working raw in the JVM, there's no such concept as x << 37, because 37 requires more than 5 bits to specify. Java explicitly allows you to say x << 37, but secretly defines it to do something insane.
- aftbit 11y agox % 32 === x & 31 So if they use a 5-bit number, they can just stick your second operand into that slot after it's been ANDed with 31 (which might even be implicit in how the x86 shift instructions work). To do otherwise would require them to branch (just like you did in your solution).
- thaumasiotes 11y agoSo what?
- userbinator 11y ago...except on the 8086/8088, where it will continue shifting and filling the register with 0s or sign bits (it's done in a microcode loop) up to 255, the maximum encodable shift amount. Intel changed the behaviour to mask off the shift count to the low 5 bits, starting with the 80186/80188.