First remember that machine words are of fixed size. Say 4, and that your input is: +—+—+—+—+ | a | b | c | d | +—+—+—+—+ Then pushing everything one position to the left gives: +—+—+—+—+ | b | c | d | X | +—+—+—+—+ Question what to put as X? with a … Read more
Let’s look at the datasheet: http://atmel.com/dyn/resources/prod_documents/8271S.pdf As far as I can see, the ASR (arithmetic shift right) always shifts by one bit and cannot take the number of bits to shift; it takes one cycle to execute. Therefore, shifting right by n bits will take n cycles. Powers of two behave just the same as … Read more
You’re not reading that sentence correctly. The standard defines it if: the left operand has a signed type and a non-negative value and the result is representable (and previously in the same paragraph defines it for unsigned types). In all other cases (notice the use of the semicolon in that sentence), i.e, if any of … Read more
As per the Java Language Specification 15.19. Shift Operators (slightly paraphrased): If the promoted type of the left-hand operand is int, only the five lowest-order bits of the right-hand operand are used as the shift distance. It is as if the right-hand operand were subjected to a bitwise logical AND operator & with the mask … Read more
In C++ as in C, shifts are limited to the size (in bits) of the value shifted. For instance, if unsigned int is 32 bits, then a shift of more than 31 is undefined. In practice, a common result is that the 5 least-significant bits of the shift amount are used and the higher order … Read more
The problem is that all arguments are first promoted to int before the shift operation takes place: byte b = (byte) 0xf1; b is signed, so its value is -15. byte c = (byte) (b >> 4); b is first sign-extended to the integer -15 = 0xfffffff1, then shifted right to 0xffffffff and truncated to … Read more
Computers are binary devices. Because of this, numbers are represented by a sequence of 1s and 0s. Bitshifting is simply moving those sequences of 1s and 0s left or right. So all the >> operator does is shift the bits towards the right one bit. Consider the number 101: // Assuming signed 8-bit integers 01100101 … Read more
The relevant issue is CWG 1457, where the justification is that the change allows 1 << 31 to be used in constant expressions: The current wording of 5.8 [expr.shift] paragraph 2 makes it undefined behavior to create the most-negative integer of a given type by left-shifting a (signed) 1 into the sign bit, even though … Read more
See http://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.19 If the promoted type of the left-hand operand is int, only the five lowest-order bits of the right-hand operand are used as the shift distance. It is as if the right-hand operand were subjected to a bitwise logical AND operator & (ยง15.22.1) with the mask value 0x1f (0b11111). The shift distance actually used … Read more
long may be a 64-bit type, but 1 is still an int. You need to make 1 a long int using the L suffix: unsigned long x = 1UL << 32; (You should also make it unsigned using the U suffix as I’ve shown, to avoid the issues of left shifting a signed integer. There’s … Read more