对有符号整数进行逻辑右移操作

Question

在有符号整数-28上对逻辑右移3次操作。什么是正确的答案？

1. 203
2. 83
3. 3
4. -3

-28的2的补码是11100100。 现在，如果我应用逻辑右移操作，我没有得到上述任何一个答案。

Answer 1

我几乎肯定这是一个棘手的问题。

面试官看到你是否回答“-3”。如果你有（错误的推理，因为28>＆gt;＆gt;＆gt; 3是3然后-28＆gt;＆gt;＆gt; 3是-3），他会意识到你不理解两个补码。

他希望你回答说四种选择中没有一种是正确的。他想要你

1. 解释逻辑右移是怎样的， 不像算术右移，会 将一个小的neg号变成一个巨大的 转动标志的正数 进入量级的一部分
2. 指出答案取决于 用于表示的字节数 一个int

Answer 2

也许诀窍不是假设两个补码表示。假设sign-and-magnitude表示，答案可以是-3，因为大多数移位实现都不涉及符号位。

Answer 3

这是一个愚蠢的问题：

• 是否在左侧添加0或1并不是普遍定义的负数（维基百科说“空位位置填充，通常用零” - 我的重点）< / LI>
• 未讨论所涉及的整数大小，
• 正在使用负数的多个按位表示。

有些语言（比如Java，我相信）新的最重要的位，这样任何没有合适的CPU指令的平台都必须发出几个来计算所需的答案，而其他语言可能会定义一个实现在CPU原生提供的行为之间进行选择。

2的补码是负数最常见的表示。你的问题是“2的补码是-28是11100100。”......我猜这不是作为问题的一部分提供的（如果有的话，有点奇怪，因为它是在答案之后）。仍然...

如果我们使用2的补码...

11100100 >> 3 = 00011100 or 11111100 = 28 or -4

如果表示是1的补码：

11100011 >> 3 = 00011100 or 11111100 = 28 or -3

如果表示是符号位，绝对值：

10011100 >> 3 = 00010011 or 11110011 = 19 or -(127-12)=-115

(note that the question says a logical bit shift, which by definition ignores any possible interpretation of the bits, so the sign bit is shifted along with others)

在一个int中重新#bit ...我认为很明显，这会导致一个太大而无法匹配任何选项的值，否则就不会产生任何差异（如果添加1个）在左边为1或2的补码），我们可以忽略这个问题。

所以，除非我上面的快速计算结果下滑，否则-3是唯一可能在任何合理的架构上都是正确的答案，但仍然不太可能。总而言之，我想知道他们是否真的没有进行测试，看看谁有信心让这个问题得不到回答，或者注释说答案都不正确......

Answer 4

向右移动有符号整数可以做很多事情：

1. 如果数字是负数，它将签名扩展结果（左侧1位移位），这应该会使数字看起来像一个较小的负数。
2. 如果数字是正数，那么对于你移动的每一位，它都会将它除以2。

但这种行为在技术上是“实现定义的”。

请参阅此帖：Are the shift operators (<<, >>) arithmetic or logical in C?