c++ - 是否有任何 2 补码平台/编译器，其中 signed shift 不做通常的事情？

Question

左移的结果可以是undefined behavior :

The value of E1 << E2 is E1 left-shifted E2 bit positions; vacated bits are zero-filled. If E1 has an unsigned type, the value of the result is E1×2^E2, reduced modulo one more than the maximum value representable in the result type. Otherwise, if E1 has a signed type and non-negative value, and E1×2^E2 is representable in the corresponding unsigned type of the result type, then that value, converted to the result type, is the resulting value; otherwise, the behavior is undefined.

右移的结果可以是implementation-defined :

The value of E1 >> E2 is E1 right-shifted E2 bit positions. If E1 has an unsigned type or if E1 has a signed type and a non-negative value, the value of the result is the integral part of the quotient of E1/2^E2. If E1 has a signed type and a negative value, the resulting value is implementation-defined.

现在，我所知道的所有平台，未定义的行为/实现定义实际上都在这里做了明智的事情:

• 左移一个负数就是乘以 2^E2，就像这个数是正数一样
• 右移负数是“算术移位”，它正常移动数字，但将符号位放入最高有效位。

那么，问题是，是否有任何2-complement 平台/编译器的行为不是这样的？

---

为什么这个问题？大多数编译器 don't emit optimal code (链接由 phuclv 提供，检查 test1 和 test2 之间的反汇编)certain circumstances 中的 2 次方除法(不过，clang 会生成最佳代码)。

Answer 1

某些用于缺少符号扩展右移指令的处理器的编译器历来将所有右移操作处理为零填充。

C89 标准精确定义了在所有补码或补码平台上左移负数的行为，这些平台在其有符号或无符号类型上均未使用填充位。然而，补码机器上的行为并不等同于乘法。此外，尚不清楚符号幅度机器上的正确行为。

C99 标准将负左移更改为未定义行为。基本原理中没有任何内容提供更改的任何理由，甚至也没有承认。基本原理中未提及表明它不被视为重大更改，因为没有理由期望在 C89 下有效定义行为的任​​何实现都不会继续以相同的方式定义行为，无论是否标准继续要求它。唯一有意义的意图是允许 ones'-complement 或 sign-magnitude 实现(如果曾经为 C99 生产过)以一种可能比 C89 要求的更有用的方式运行。

在编写 C89 甚至 C99 时，作者并未察觉到其行为由标准强制执行的操作与无论标准是否要求它们或不是。编译器编写者似乎认为委员会打算从语言中消除后一种形式的所有行为，但我没有看到任何证据表明有任何此类行为。

在实践中，我所知道的唯一编译器目前不遵守关于左移的期望，其结果将表示为不溢出的乘法是那些被明确配置为在负左上发出声音的编译器-转变纯粹是因为标准不再定义他们的行为。然而，如果一些“聪明”的人基于标准不再要求实现此类平台以在他们总是有同样明智和有用的方式。这种偏差可能有两种形式:

1. 编译器可以决定，如果需要清零进位标志的操作之前有带符号的左移，则可以省略通常在后一个操作之前的“清零进位”指令。我使用过可以保存指令的平台，但我见过的所有针对此类平台的编译器都会清除进位，即使标准不需要它。

2. 编译器可以决定左移的结果“不可能”为负，因此可以安全地省略该结果与任何负值之间的任何比较。更进一步，它可以决定操作数同样不可能为负数，并删除任何不会阻止执行左移的与负数的比较。 gcc 和 clang 都没有尝试实现此类优化，但这并不意味着它们永远不会。

二进制补码系统的高质量实现将可预测地处理带符号的左移，除非或直到有特别令人信服的理由让他们不这样做——这似乎不太可能发生。至于低质量的实现可能会造成什么后果，谁知道呢。