¿Por qué es (a% 256) diferente de (a & 0xFF)?

Siempre supuse que al hacer (a % 256)el optimizador, naturalmente, usaría una operación eficiente a nivel de bits, como si escribiera (a & 0xFF).

Al probar en el explorador del compilador 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

Y al probar el otro código:

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

mod(int):
    movzx   eax, dil
    ret

Parece que me estoy perdiendo algo por completo. ¿Algunas ideas?

No es lo mismo. Intente num = -79y obtendrá resultados diferentes de ambas operaciones. (-79) % 256 = -79, mientras que (-79) & 0xffes un número positivo.

Usando unsigned int, las operaciones son las mismas, y el código probablemente será el mismo.

PD- Alguien comentó

No deberían ser iguales, a % bse define como a - b * floor (a / b).

Así no se define en C, C ++, Objective-C (es decir, todos los lenguajes donde se compilaría el código de la pregunta).

Respuesta corta

-1 % 256cede -1y no 255cual es -1 & 0xFF. Por lo tanto, la optimización sería incorrecta.

Respuesta larga

C ++ tiene la convención que (a/b)*b + a%b == aparece bastante natural. a/bsiempre devuelve el resultado aritmético sin la parte fraccionaria (truncando hacia 0). Como consecuencia, a%btiene el mismo signo que ao es 0.

La división -1/256rinde 0y, por -1%256lo tanto, debe ser -1para satisfacer la condición anterior ( (-1%256)*256 + -1%256 == -1). Esto es obviamente diferente de lo -1&0xFFque es 0xFF. Por lo tanto, el compilador no puede optimizar la forma que desea.

La sección relevante en el estándar C ++ [expr.mul §4] a partir de N4606 establece:

Para operandos integrales, el /operador produce el cociente algebraico con cualquier parte fraccional descartada; si el cociente a/bes representable en el tipo del resultado, (a/b)*b + a%bes igual a a[...].

Habilitando la optimización

Sin embargo, usando unsignedtipos, la optimización sería completamente correcta , satisfaciendo la convención anterior:

unsigned(-1)%256 == 0xFF

Ver también esto .

Otros idiomas

Esto se maneja de manera muy diferente en diferentes lenguajes de programación, ya que puede consultar Wikipedia .

Desde C ++ 11, num % 256tiene que ser no positivo si numes negativo.

Por lo tanto, el patrón de bits dependería de la implementación de tipos con signo en su sistema: para un primer argumento negativo, el resultado no es la extracción de los 8 bits menos significativos.

Sería un asunto diferente si numen su caso lo fuera unsigned: en estos días casi esperaría que un compilador haga la optimización que usted cita.

No tengo una visión telepática del razonamiento del compilador, pero en el caso de %que sea necesario tratar con valores negativos (y las rondas de división hacia cero), mientras que &el resultado es siempre los 8 bits más bajos.

La sarinstrucción me suena como "desplazamiento aritmético a la derecha", llenando los bits desocupados con el valor del bit de signo.

Matemáticamente hablando, el módulo se define como el siguiente:

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

Esto aquí debería aclararlo para ti. Podemos eliminar el piso para enteros porque la división de enteros es equivalente al piso (a / b). Sin embargo, si el compilador usara un truco general como usted sugiere, tendría que funcionar para todos ay todos b. Desafortunadamente, este no es el caso. Hablando matemáticamente, su truco es 100% correcto para enteros sin signo (veo que una respuesta indica que los enteros con signo se rompen, pero puedo confirmar o negar esto ya que -a% b debería ser positivo). Sin embargo, ¿puedes hacer este truco para todos los b? Probablemente no. Es por eso que el compilador no lo hace. Después de todo, si el módulo se escribiera fácilmente como una operación bit a bit, entonces simplemente agregaríamos un circuito de módulo como para la suma y las otras operaciones.