为什么（％256）与（a＆0xFF）不同？

我一直认为执行(a % 256)优化程序时自然会使用高效的按位运算，就像我写的那样(a & 0xFF)。

在编译器资源管理器gcc-6.2（-O3）上进行测试时：

// Type your code here, or load an example.
int mod(int num) {
    return num % 256;
}

mod(int):
    mov     edx, edi
    sar     edx, 31
    shr     edx, 24
    lea     eax, [rdi+rdx]
    movzx   eax, al
    sub     eax, edx
    ret

当尝试其他代码时：

// Type your code here, or load an example.
int mod(int num) {
    return num & 0xFF;
}

mod(int):
    movzx   eax, dil
    ret

似乎我完全错过了一些东西。有任何想法吗？

这是不一样的。尝试使用num = -79，这两种操作都会得到不同的结果。(-79) % 256 = -79，虽然(-79) & 0xff是一些正数。

使用unsigned int，操作相同，代码也可能相同。

PS-有人评论

它们不应相同，a % b定义为a - b * floor (a / b)。

这不是在C，C ++，Objective-C（即问题中的代码将在其中编译的所有语言）中定义的方式。

简短答案

-1 % 256产生-1，而不是255它是-1 & 0xFF。因此，优化将是不正确的。

长答案

C ++遵循惯例(a/b)*b + a%b == a，这似乎很自然。a/b总是返回不带小数部分的运算结果（截断为0）。结果，a%b具有等于a或为0的符号。

分割-1/256产率0，并因此-1%256必须是-1为了满足上述条件（(-1%256)*256 + -1%256 == -1）。这显然是不同的-1&0xFF这是0xFF。因此，编译器无法优化所需的方式。

从N4606开始的C ++标准[expr.mul§4]中的相关部分指出：

对于整数操作数，/运算符得出除掉任何小数部分的代数商。如果商a/b在结果类型中可表示，(a/b)*b + a%b则等于a[...]。

启用优化

但是，使用unsigned类型，优化将完全正确，满足上述约定：

unsigned(-1)%256 == 0xFF

另请参见本。

其他语言

您可以在Wikipedia上查找，这在不同的编程语言中的处理方式非常不同。

从C ++ 11开始，num % 256如果num为负，则必须为非正。

因此，位模式将取决于系统上有符号类型的实现：对于第一个负数的参数，结果不是提取最低有效8位。

如果num您的情况是unsigned这样，那将是另一回事：如今，我几乎希望编译器做出您引用的优化。

我对编译器的推理没有心灵感应，但在这种情况下，%有必要处理负值（除法舍入为零），而&结果始终是低8位。

在sar我看来，该指令听起来像“右移算术”，用符号位值填充空出的位。

从数学上讲，模的定义如下：

a％b = a-b *底数（a / b）

这里的权利应该为您清除它。我们可以消除整数的下限，因为整数除法等于下限（a / b）。但是，如果编译器使用您建议的通用技巧，则它必须适用于所有a和所有b。不幸的是，事实并非如此。从数学上讲，您的技巧对于无符号整数是100％正确的（我看到一个答案指出有符号整数坏了，但我可以确认也不否认，因为-a％b应该是正数）。但是，您能为所有b做到这一点吗？可能不是。这就是为什么编译器不这样做。毕竟，如果将模简单地写成一个按位运算，那么我们只需添加一个模电路，如加法和其他运算。