Por que as instruções x86-64 em registros de 32 bits zeram a parte superior do registro de 64 bits completo?

No Tour do x86-64 dos manuais da Intel , li

Talvez o fato mais surpreendente seja que uma instrução como essa MOV EAX, EBXzera automaticamente os 32 bits superiores do RAXregistro.

A documentação da Intel (3.4.1.1 Registros de uso geral no modo de 64 bits no manual Arquitetura básica) citada na mesma fonte nos diz:

• Operandos de 64 bits geram um resultado de 64 bits no registrador de uso geral de destino.
• Operandos de 32 bits geram um resultado de 32 bits, estendido por zero para um resultado de 64 bits no registrador de uso geral de destino.
• Operandos de 8 e 16 bits geram um resultado de 8 ou 16 bits. Os 56 bits ou 48 bits superiores (respectivamente) do registrador de uso geral de destino não são modificados pela operação. Se o resultado de uma operação de 8 ou 16 bits se destinar ao cálculo do endereço de 64 bits, estenda explicitamente o registro para 64 bits completos.

Em montagem x86-32 e x86-64, instruções de 16 bits, como

mov ax, bx

não mostre esse tipo de comportamento "estranho" de que a palavra superior de eax seja zerada.

Assim: qual é o motivo pelo qual esse comportamento foi introduzido? À primeira vista, parece ilógico (mas o motivo pode ser que estou acostumado com as peculiaridades do assembly x86-32).

Não sou AMD ou falando por eles, mas teria feito da mesma forma. Porque zerar a metade superior não cria uma dependência do valor anterior, que a CPU teria que esperar. O mecanismo de renomeação de registro seria essencialmente derrotado se não fosse feito dessa forma.

Dessa forma, você pode escrever código rápido usando valores de 32 bits no modo de 64 bits sem ter que quebrar as dependências explicitamente o tempo todo. Sem esse comportamento, cada instrução de 32 bits no modo de 64 bits teria que esperar por algo que aconteceu antes, mesmo que essa parte alta quase nunca fosse usada. (Fazer int64 bits desperdiçaria espaço de cache e largura de banda de memória; x86-64 suporta de forma mais eficiente tamanhos de operando de 32 e 64 bits )

O comportamento para tamanhos de operando de 8 e 16 bits é estranho. A loucura da dependência é uma das razões pelas quais as instruções de 16 bits são evitadas agora. O x86-64 herdou isso de 8086 para 8 bits e 386 para 16 bits, e decidiu fazer os registradores de 8 e 16 bits funcionarem da mesma maneira no modo de 64 bits e no modo de 32 bits.

Veja também Por que o GCC não usa registros parciais? para detalhes práticos de como as gravações em registros parciais de 8 e 16 bits (e leituras subsequentes do registro completo) são tratadas por CPUs reais.

Ele simplesmente economiza espaço nas instruções e no conjunto de instruções. Você pode mover pequenos valores imediatos para um registro de 64 bits usando as instruções existentes (32 bits).

Também evita que você tenha que codificar valores de 8 bytes para MOV RAX, 42quando MOV EAX, 42puder ser reutilizado.

Essa otimização não é tão importante para operações de 8 e 16 bits (porque são menores) e alterar as regras também quebraria o código antigo.

Sem zero estendendo-se para 64 bits, isso significaria que uma instrução de leitura raxteria 2 dependências para seu raxoperando (a instrução que escreve eaxe a instrução que escreve raxantes dela), isso significa que 1) o ROB teria que ter entradas para múltiplas dependências para um único operando, o que significa que o ROB exigiria mais lógica e transistores e ocuparia mais espaço, e a execução seria mais lenta aguardando uma segunda dependência desnecessária que poderia levar anos para ser executada; ou alternativamente 2), que suponho que aconteça com as instruções de 16 bits, o estágio de alocação provavelmente para (ou seja, se o RAT tiver uma alocação ativa para uma axgravação e uma eaxleitura aparecer, ele para até que a axgravação seja retirada).

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

O único benefício de extensão diferente de zero é garantir que os bits de ordem superior raxsejam incluídos, por exemplo, se originalmente contiver 0xffffffffffffffff, o resultado seria 0xffffffff00000007, mas há muito pouca razão para o ISA fazer essa garantia com tal despesa, e é mais provável que o benefício da extensão zero seja realmente mais necessário, portanto, ele economiza a linha de código extra mov rax, 0. Garantindo que ele sempre será estendido de zero a 64 bits, os compiladores podem trabalhar com este axioma em mente enquanto estão ligados mov rdx, rax, raxapenas tem que esperar por sua dependência única, o que significa que pode começar a execução mais rápido e se retirar, liberando unidades de execução. Além disso, também permite expressões idiomáticas zero mais eficientes, como xor eax, eaxzero, raxsem exigir um byte REX.