Perché le istruzioni x86-64 sui registri a 32 bit azzerano la parte superiore del registro a 64 bit completo?

Nel tour x86-64 dei manuali Intel , ho letto

Forse il fatto più sorprendente è che un'istruzione come MOV EAX, EBXazzera automaticamente i 32 bit di RAXregistro superiori.

La documentazione Intel (3.4.1.1 General-Purpose Registers in 64-Bit Mode in manual Basic Architecture) citata nella stessa fonte ci dice:

• Gli operandi a 64 bit generano un risultato a 64 bit nel registro generico di destinazione.
• Gli operandi a 32 bit generano un risultato a 32 bit, esteso da zero a un risultato a 64 bit nel registro generico di destinazione.
• Gli operandi a 8 e 16 bit generano un risultato a 8 o 16 bit. I 56 bit superiori o 48 bit (rispettivamente) del registro di destinazione generale non vengono modificati dall'operazione. Se il risultato di un'operazione a 8 o 16 bit è destinato al calcolo dell'indirizzo a 64 bit, estendi con segno esplicito il registro a 64 bit completi.

Nell'assembly x86-32 e x86-64, istruzioni a 16 bit come

mov ax, bx

non mostrare questo tipo di comportamento "strano" che la parola superiore di eax sia azzerata.

Quindi: qual è il motivo per cui è stato introdotto questo comportamento? A prima vista sembra illogico (ma il motivo potrebbe essere che sono abituato alle stranezze dell'assembly x86-32).

Non sono AMD né parlo per loro, ma l'avrei fatto allo stesso modo. Perché l'azzeramento della metà alta non crea una dipendenza dal valore precedente, su cui la CPU dovrebbe attendere. Il meccanismo di ridenominazione dei registri verrebbe sostanzialmente annullato se non fosse stato fatto in questo modo.

In questo modo è possibile scrivere codice veloce utilizzando valori a 32 bit in modalità 64 bit senza dover interrompere esplicitamente le dipendenze per tutto il tempo. Senza questo comportamento, ogni singola istruzione a 32 bit in modalità 64 bit dovrebbe attendere qualcosa che è accaduto prima, anche se quella parte alta non verrebbe quasi mai utilizzata. (Fare int64 bit sprecherebbe il footprint della cache e la larghezza di banda della memoria; x86-64 supporta in modo più efficiente le dimensioni degli operandi a 32 e 64 bit )

Il comportamento per le dimensioni degli operandi a 8 e 16 bit è strano. La follia della dipendenza è uno dei motivi per cui le istruzioni a 16 bit vengono ora evitate. x86-64 lo ha ereditato da 8086 per 8 bit e 386 per 16 bit e ha deciso che i registri a 8 e 16 bit funzionassero allo stesso modo in modalità 64 bit come in modalità 32 bit.

Vedi anche Perché GCC non usa registri parziali? per dettagli pratici su come le scritture su registri parziali a 8 e 16 bit (e le successive letture del registro completo) siano gestite da CPU reali.

Risparmia semplicemente spazio nelle istruzioni e nel set di istruzioni. È possibile spostare piccoli valori immediati in un registro a 64 bit utilizzando le istruzioni esistenti (a 32 bit).

Inoltre ti evita di dover codificare valori di 8 byte per MOV RAX, 42, quando MOV EAX, 42possono essere riutilizzati.

Questa ottimizzazione non è così importante per le operazioni a 8 e 16 bit (perché sono più piccole) e la modifica delle regole potrebbe anche rompere il vecchio codice.

Senza che lo zero si estenda a 64 bit, significherebbe che un'istruzione che legge da raxavrebbe 2 dipendenze per il suo raxoperando (l'istruzione che scrive eaxe l'istruzione che scrive raxprima di essa), ciò significa che 1) il ROB dovrebbe avere voci per più dipendenze per un singolo operando, il che significa che ROB richiederebbe più logica e transistor e occuperebbe più spazio, e l'esecuzione sarebbe più lenta in attesa di una seconda dipendenza non necessaria che potrebbe richiedere anni per essere eseguita; o in alternativa 2), cosa che immagino accada con le istruzioni a 16 bit, la fase di allocazione probabilmente si blocca (cioè se il RAT ha un'allocazione attiva per una axscrittura e eaxappare una lettura, si blocca fino a quando la axscrittura non si ritira).

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

L'unico vantaggio di non estendere zero è garantire che i bit di ordine superiore raxsiano inclusi, ad esempio, se originariamente contiene 0xffffffffffffffff, il risultato sarebbe 0xffffffff00000007, ma c'è pochissimo motivo per l'ISA di rendere questa garanzia a tale costo, e è più probabile che il vantaggio dell'estensione zero sia effettivamente richiesto di più, quindi salva la riga di codice aggiuntiva mov rax, 0. Garantendo che sarà sempre zero esteso a 64 bit, i compilatori possono lavorare con questo assioma in mente mentre sono dentro mov rdx, rax, raxdevono solo aspettare la sua singola dipendenza, il che significa che può iniziare l'esecuzione più velocemente e ritirarsi, liberando unità di esecuzione. Inoltre, consente anche idiomi zero più efficienti come xor eax, eaxzero raxsenza richiedere un byte REX.