Hacker News new | past | comments | ask | show | jobs | submit login

The x86 shift instructions do the same, so I'd guess that's why the JVM does it that way.



Sure, 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.


x % 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).


So what?


...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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: