Assembly: perché alcuni codici opzionali x86 non sono validi in x64?

Question

La mia domanda nasce da una semplice curiosità:

Perché in x64 alcuni degli opcode non sono validi (06, 07 per esempio), mentre in x86 vengono utilizzati per istruzioni abbastanza semplici (06 e 07 sono push e pop)? Pensavo che quelle istruzioni più semplici avrebbero funzionato bene in entrambe le architetture.

Perché disabilitate alcune di queste semplici istruzioni a 64? Perché non dovrebbero lavorare? Perché hanno disattivato alcuni opcode, creando buchi nella lista dei codici operativi, quando invece potevano assegnarli alle versioni x64 delle istruzioni?

Riferimento:

http://ref.x86asm.net/coder32.html

http://ref.x86asm.net/coder64.html

Answer 1

I 06 e 07 codici operativi in ​​modalità a 32 bit sono le istruzioni PUSH ES e POP ES. Nella modalità a 64 bit, il segmento registra CS, DS, ES e SS non sono più utilizzati per determinare gli indirizzi di memoria: il processore assume un indirizzo di base di 0 e nessun limite di dimensione. Poiché di solito non esiste alcuna ragione per le applicazioni (diverse dal sistema operativo stesso) per accedere a questi registri, sono stati rimossi gli opcode per la modifica e l'accesso a tali registri.

I registri di segmento FS e GS possono ancora impostare l'indirizzo di base in modalità a 64 bit, per cui non sono stati rimossi i codici operativi ad essi connessi.

Answer 2

per tutte le CPU c'è qualcosa di simile a uno "spazio codice operativo". Ad esempio, se una CPU utilizza opcode a 8 bit, allora ci sarebbe un max. di 256 istruzioni che potrebbe avere. Gli opcode più grandi sono più opcode che puoi avere, ma più difficile è recuperarli e decodificarli rapidamente.

80x86 è un'architettura relativamente vecchia. È iniziato con un modesto spazio di opcode composto principalmente da opcode di 1 byte e 2 byte. Ogni volta che i produttori di CPU aggiungono una nuova funzionalità ci vogliono più opcode dallo spazio opcode. Hanno finito gli opcode. Si sono esauriti rapidamente.

Per aggirare lo hanno iniziato a fare le cose come l'aggiunta di codici di escape e prefissi per esteso artificialmente lo spazio codice operativo. Per un esempio, per le recenti istruzioni AVX stai guardando un prefisso VEX seguito da un vecchio codice di escape riciclato (ad esempio 0xF0), seguito da un vecchio prefisso di dimensioni degli operandi/indirizzo riciclato (ad esempio 0x66), seguito da altri 4 byte . Non è carino

Allo stesso tempo ci sono vecchie istruzioni che vengono utilizzate raramente ora (AAD, AAM, ecc.) E istruzioni con opcodes multipli/ridondanti (INC/DEC) che stavano consumando opcode di tipo "1 byte". Questi non possono/non possono essere rimossi completamente a causa della retrocompatibilità.

Tuttavia; quando 64-bit veniva progettato, semplicemente non c'era alcun codice a 64 bit per essere compatibile con - la compatibilità all'indietro non aveva importanza. Gli opcode a 1 byte consumati da istruzioni "non molto importanti" potrebbero essere riciclati; rendendo tali istruzioni non valide nel codice a 64 bit (ma liberando alcuni dei preziosi opcode di 1 byte).

La maggior parte di questi codici opzionali da 1 byte (l'intero gruppo INC/DEC da 1 byte se ricordo bene) è stata immediatamente riciclata per il prefisso REX necessario per supportare operandi a 64 bit. Alcuni non erano e sono diventati "gratuiti per estensioni future" (con la limitazione che l'estensione può funzionare solo con codice a 64 bit poiché tali istruzioni sono ancora valide nel codice a 16 e 32 bit).