(A% 256) neden (a & 0xFF) seçeneğinden farklıdır?

Her zaman (a % 256)optimize ediciyi yaparken doğal olarak verimli bir bitsel işlem kullanacağını varsaymıştım, sanki yazmışım gibi (a & 0xFF).

Derleyici gezgini gcc-6.2 (-O3) üzerinde test ederken:

// 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

Ve diğer kodu denerken:

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

mod(int):
    movzx   eax, dil
    ret

Görünüşe göre bir şeyleri tamamen kaçırıyorum. Herhangi bir fikir?

Aynı şey değil. Deneyin num = -79ve her iki işlemden de farklı sonuçlar alacaksınız. (-79) % 256 = -79İken (-79) & 0xffbazı olumlu sayıdır.

Kullanım unsigned int, işlemler aynıdır ve kod muhtemelen aynı olacaktır.

PS- Birisi yorum yaptı

Aynı olmamaları gerekir, a % bolarak tanımlanır a - b * floor (a / b).

Bu, C, C ++, Objective-C'de (yani sorudaki kodun derleneceği tüm diller) böyle tanımlanmaz.

Kısa cevap

-1 % 256verim -1, 255hangisi değil -1 & 0xFF. Bu nedenle optimizasyon yanlış olur.

Uzun cevap

C ++, (a/b)*b + a%b == aoldukça doğal görünen bir kurala sahiptir. a/bher zaman kesirli kısım olmadan aritmetik sonucu verir (0'a doğru kırpılır). Sonuç a%bolarak a, 0 ile aynı işarete sahiptir .

Bölünme -1/256getirileri 0ve dolayısıyla yukarıdaki koşulu ( ) karşılamak için -1%256olmalıdır . Bu açıkça hangisinden farklıdır . Bu nedenle, derleyici istediğiniz şekilde optimize edemez.-1(-1%256)*256 + -1%256 == -1-1&0xFF0xFF

C ++ standardının [ifade §4] N4606 itibariyle ilgili bölümü şunları belirtir:

İntegral işlenenler için /operatör, herhangi bir kesirli kısım atılmış olarak cebirsel bölümü verir; bölüm a/bsonuç türünde gösterilebilirse, [...] 'ye (a/b)*b + a%beşittir a.

Optimizasyonu etkinleştirmek

Bununla birlikte, türleri kullanarak unsigned, optimizasyon tamamen doğru olur ve yukarıdaki kuralı yerine getirir:

unsigned(-1)%256 == 0xFF

Ayrıca buna bakın .

Diğer diller

Wikipedia'da bakabileceğiniz gibi bu, farklı programlama dillerinde çok farklı şekilde ele alınır .

C ++ 11 num % 256olduğundan num, negatifse pozitif olmamalıdır .

Dolayısıyla, bit örüntüsü, sisteminizdeki işaretli türlerin uygulanmasına bağlı olacaktır: negatif bir ilk argüman için, sonuç en az önemli olan 8 bitin çıkarılması değildir.

numSizin durumunuzda olsaydı farklı bir konu olurdu unsigned: Bu günlerde neredeyse bir derleyicinin alıntı yaptığınız optimizasyonu yapmasını beklerdim .

Derleyicinin mantığına dair telepatik bir anlayışa sahip değilim, ancak bu durumda %negatif değerlerle (ve sıfıra doğru bölme yuvarlamalarını) ele alma zorunluluğu varken &, sonuç her zaman daha düşük 8 bittir.

sarİşaret bit değeri ile boşalan bit dolduruyor, "aritmetik hakkı shift" gibi bana talimat sesler.

Matematiksel olarak, modulo şu şekilde tanımlanır:

a% b = a - b * kat (a / b)

Bu tam burada sizin için açıklığa kavuşturmalı. Tamsayılar için tabanı ortadan kaldırabiliriz çünkü tamsayı bölmesi floor (a / b) ile eşdeğerdir. Ancak, derleyici önerdiğiniz gibi genel bir numara kullanacaksa, tüm a ve tümü b için çalışması gerekir. Maalesef durum bu değil. Matematiksel olarak konuşursak, numaranız işaretsiz tamsayılar için% 100 doğrudur (bir cevap durumunun işaretli tamsayılar kırıldığını görüyorum, ancak bunu onaylayabilir veya reddedebilirim - a% b pozitif olmalıdır). Ancak, bu numarayı tüm b için yapabilir misiniz? Muhtemelen değil. Bu yüzden derleyici bunu yapmaz. Sonuçta, eğer modulo kolayca bitsel bir işlem olarak yazılsaydı, o zaman ekleme ve diğer işlemler için olduğu gibi bir modulo devresi eklerdik.