（a％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または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 * floor（a / b）

これはここで解決します。整数の除算はfloor（a / b）と同等であるため、整数のfloorを削除できます。ただし、コンパイラーが提案するような一般的なトリックを使用する場合は、すべてのaとすべてのbで機能する必要があります。残念ながら、これは事実ではありません。数学的に言えば、あなたのトリックは符号なし整数に対して100％正しいです（私は、符号付き整数が壊れていると答えますが、-a％bは正でなければならないので、これを確認または否定できます）。しかし、あなたはすべてのbに対してこのトリックを行うことができますか？おそらく違います。そのため、コンパイラーはそれを行いません。結局のところ、モジュロを1つのビット単位の演算として簡単に記述できる場合は、加算やその他の演算のようにモジュロ回路を追加するだけです。