¿Por qué las instrucciones x86-64 en registros de 32 bits ponen a cero la parte superior del registro completo de 64 bits?

En el Tour x86-64 de los manuales de Intel , leí

Quizás el hecho más sorprendente es que una instrucción como MOV EAX, EBXautomáticamente pone a cero los 32 bits superiores del RAXregistro.

La documentación de Intel (3.4.1.1 Registros de propósito general en modo de 64 bits en la arquitectura básica manual) citada en la misma fuente nos dice:

• Los operandos de 64 bits generan un resultado de 64 bits en el registro de propósito general de destino.
• Los operandos de 32 bits generan un resultado de 32 bits, ampliado a cero a un resultado de 64 bits en el registro de propósito general de destino.
• Los operandos de 8 y 16 bits generan un resultado de 8 o 16 bits. Los 56 bits o 48 bits superiores (respectivamente) del registro de propósito general de destino no son modificados por la operación. Si el resultado de una operación de 8 bits o de 16 bits está destinado al cálculo de direcciones de 64 bits, extienda explícitamente el signo del registro a los 64 bits completos.

En el ensamblaje x86-32 y x86-64, instrucciones de 16 bits como

mov ax, bx

no muestre este tipo de comportamiento "extraño" de que la palabra superior de eax se ponga a cero.

Entonces: ¿cuál es la razón por la que se introdujo este comportamiento? A primera vista, parece ilógico (pero la razón podría ser que estoy acostumbrado a las peculiaridades del ensamblaje x86-32).

No soy AMD ni hablo por ellos, pero lo habría hecho de la misma manera. Debido a que poner a cero la mitad alta no crea una dependencia del valor anterior, la CPU tendría que esperar. El mecanismo de cambio de nombre de registros esencialmente se anularía si no se hiciera de esa manera.

De esta manera, puede escribir código rápido utilizando valores de 32 bits en modo de 64 bits sin tener que romper explícitamente las dependencias todo el tiempo. Sin este comportamiento, cada instrucción de 32 bits en modo de 64 bits tendría que esperar a algo que sucedió antes, aunque esa parte alta casi nunca se usaría. (Hacer int64 bits desperdiciaría la huella de caché y el ancho de banda de la memoria; x86-64 admite tamaños de operandos de 32 y 64 bits de manera más eficiente )

El comportamiento de los operandos de 8 y 16 bits es extraño. La locura de la dependencia es una de las razones por las que ahora se evitan las instrucciones de 16 bits. x86-64 heredó esto de 8086 para 8 bits y 386 para 16 bits, y decidió que los registros de 8 y 16 bits funcionaran de la misma manera en el modo de 64 bits que en el modo de 32 bits.

Consulte también ¿Por qué GCC no usa registros parciales? para obtener detalles prácticos sobre cómo las escrituras en registros parciales de 8 y 16 bits (y lecturas posteriores del registro completo) son manejadas por CPU reales.

Simplemente ahorra espacio en las instrucciones y el conjunto de instrucciones. Puede mover pequeños valores inmediatos a un registro de 64 bits mediante las instrucciones existentes (32 bits).

También le evita tener que codificar valores de 8 bytes para MOV RAX, 42cuándo MOV EAX, 42se pueden reutilizar.

Esta optimización no es tan importante para operaciones de 8 y 16 bits (porque son más pequeñas), y cambiar las reglas allí también rompería el código antiguo.

Sin que el cero se extienda a 64 bits, significaría que una instrucción que lee raxtendría 2 dependencias para su raxoperando (la instrucción que escribe eaxy la instrucción que escribe raxantes), esto significa que 1) el ROB debería tener entradas para múltiples dependencias para un solo operando, lo que significa que el ROB requeriría más lógica y transistores y ocuparía más espacio, y la ejecución sería más lenta esperando una segunda dependencia innecesaria que podría tardar años en ejecutarse; o alternativamente 2), que supongo que sucede con las instrucciones de 16 bits, la etapa de asignación probablemente se detiene (es decir, si la RAT tiene una asignación activa para una axescritura y eaxaparece una lectura, se detiene hasta que la axescritura se retira).

mov rdx, 1
mov rax, 6
imul rax, rdx
mov rbx, rax
mov eax, 7 //retires before add rax, 6
mov rdx, rax // has to wait for both imul rax, rdx and mov eax, 7 to finish before dispatch to the execution units, even though the higher order bits are identical anyway

El único beneficio de no extenderse a cero es garantizar que raxse incluyan los bits de orden superior de , por ejemplo, si originalmente contiene 0xffffffffffffffff, el resultado sería 0xffffffff00000007, pero hay muy pocas razones para que la ISA haga esta garantía a tal costo, y es más probable que se requiera más el beneficio de la extensión cero, por lo que ahorra la línea adicional de código mov rax, 0. Al garantizar que siempre será cero extendido a 64 bits, los compiladores pueden trabajar con este axioma en mente mientras están dentro mov rdx, rax, raxsolo tienen que esperar su dependencia única, lo que significa que puede comenzar la ejecución más rápido y retirarse, liberando unidades de ejecución. Además, también permite modismos cero más eficientes, como xor eax, eaxa cero, raxsin requerir un byte REX.