Perché (a% 256) è diverso da (a & 0xFF)?

Ho sempre pensato che, quando facevo (a % 256)l'ottimizzatore, avrei naturalmente usato un'operazione bit a bit efficiente, come se avessi scritto (a & 0xFF).

Durante i test su compilatore explorer 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

E quando provi l'altro codice:

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

mod(int):
    movzx   eax, dil
    ret

Sembra che mi manchi completamente qualcosa. Qualche idea?

Non è lo stesso. Prova num = -79e otterrai risultati diversi da entrambe le operazioni. (-79) % 256 = -79, mentre (-79) & 0xffè un numero positivo.

Utilizzando unsigned int, le operazioni sono le stesse e il codice sarà probabilmente lo stesso.

PS- Qualcuno ha commentato

Non dovrebbero essere gli stessi, a % bè definito come a - b * floor (a / b).

Non è così che viene definito in C, C ++, Objective-C (cioè tutti i linguaggi in cui il codice nella domanda verrebbe compilato).

Risposta breve

-1 % 256cede -1e non 255quale sia -1 & 0xFF. Pertanto, l'ottimizzazione sarebbe errata.

Risposta lunga

Il C ++ ha la convenzione che (a/b)*b + a%b == a, che sembra abbastanza naturale. a/brestituisce sempre il risultato aritmetico senza la parte frazionaria (troncando verso 0). Di conseguenza, a%bha lo stesso segno di ao è 0.

La divisione -1/256produce 0e quindi -1%256deve essere -1al fine di soddisfare la condizione di cui sopra ( (-1%256)*256 + -1%256 == -1). Questo è ovviamente diverso da quello -1&0xFFche è 0xFF. Pertanto, il compilatore non può ottimizzare nel modo desiderato.

La sezione pertinente nella norma C ++ [expr.mul §4] a partire da N4606 afferma:

Per gli operandi integrali l' /operatore fornisce il quoziente algebrico con qualsiasi parte frazionaria scartata; se il quoziente a/bè rappresentabile nel tipo di risultato, (a/b)*b + a%bè uguale a a[...].

Abilitazione dell'ottimizzazione

Tuttavia, utilizzando i unsignedtipi, l'ottimizzazione sarebbe completamente corretta , soddisfacendo la convenzione di cui sopra:

unsigned(-1)%256 == 0xFF

Si veda anche questo .

Altre lingue

Questo è gestito in modo molto diverso nei diversi linguaggi di programmazione, come puoi cercare su Wikipedia .

Dal C ++ 11, num % 256deve essere non positivo se numè negativo.

Quindi il modello di bit dipende dall'implementazione dei tipi con segno sul tuo sistema: per un primo argomento negativo, il risultato non è l'estrazione degli 8 bit meno significativi.

Sarebbe una questione diversa se numnel tuo caso è stato unsigned: in questi giorni mi piacerebbe quasi si aspettano un compilatore per rendere l'ottimizzazione che lei cita.

Non ho una visione telepatica del ragionamento del compilatore, ma nel caso %c'è la necessità di trattare valori negativi (e arrotondamenti di divisione verso lo zero), mentre con &il risultato sono sempre gli 8 bit inferiori.

L' saristruzione mi suona come "sposta l'aritmetica a destra", riempiendo i bit vuoti con il valore del bit di segno.

Matematicamente parlando, modulo è definito come il seguente:

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

Questo qui dovrebbe chiarirlo per te. Possiamo eliminare floor per numeri interi perché la divisione dei numeri interi è equivalente a floor (a / b). Tuttavia, se il compilatore dovesse usare un trucco generale come suggerisci, dovrebbe funzionare per tutti a e tutti b. Sfortunatamente, questo non è il caso. Dal punto di vista matematico, il tuo trucco è corretto al 100% per numeri interi senza segno (vedo che una risposta indica che gli interi con segno si interrompono, ma non posso confermarlo né negarlo poiché -a% b dovrebbe essere positivo). Tuttavia, puoi fare questo trucco per tutti b? Probabilmente no. Ecco perché il compilatore non lo fa. Dopotutto, se modulo fosse facilmente scritto come un'operazione bit a bit, aggiungeremmo un circuito modulo come per l'aggiunta e le altre operazioni.