Assembly: Warum sind einige x86 Opcodes in x64 ungültig?

Question

Meine Frage ergibt sich aus einer einfachen Kuriosität:

Warum sind in x64 einige der Opcodes ungültig (06, 07 zum Beispiel), während in x86 für ziemlich grundlegende Anweisungen verwendet werden (06 und 07 ist Push-und Pop)? Ich denke, dass diese einfachsten Anweisungen in beiden Architekturen gut funktionieren würden.

Warum haben sie einige dieser einfachen Anweisungen in x64 deaktiviert? Warum sollten sie nicht arbeiten? Warum haben sie einige Opcodes deaktiviert und Löcher in der Opcodeliste erzeugt, als sie sie stattdessen den x64-Versionen von Befehlen zuweisen konnten?

Referenz:

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

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

Answer 1

Die 06 und 07 OP-Codes in 32-Bit-Modus sind die Anweisungen PUSH ES und POP ES. Im 64-Bit-Modus werden die Segmentregister CS, DS, ES und SS nicht mehr verwendet, um Speicheradressen zu bestimmen: Der Prozessor nimmt eine Basisadresse von 0 und keine Größenbeschränkungen an. Da es nun normalerweise keinen Grund gibt, dass Anwendungen (außer dem Betriebssystem selbst) auf diese Register zugreifen, wurden die Opcodes zum Ändern und Zugreifen auf diese entfernt.

Die FS- und GS-Segmentregister können weiterhin die Basisadresse im 64-Bit-Modus festlegen, sodass die zugehörigen Opcodes nicht entfernt wurden.

Answer 2

Für alle CPUs gibt es so etwas wie einen "Opcode Space". Zum Beispiel, wenn eine CPU 8-Bit Opcodes verwendet, dann würde es eine max. von 256 Anweisungen könnte es haben. Je größer die Opcodes, desto mehr Opcodes können Sie haben, aber desto schwieriger ist es, sie schnell zu holen und zu decodieren.

80x86 ist eine relativ alte Architektur. Es begann mit einem bescheidenen Opcode-Platz, der hauptsächlich aus 1-Byte- und 2-Byte-Opcodes bestand. Jedes Mal, wenn CPU-Hersteller eine neue Funktion hinzufügen, werden mehr Opcodes aus dem Opcode-Bereich benötigt. Sie hatten keine Opcodes mehr. Sie sind schnell hinausgelaufen.

Um es zu umgehen, fingen sie Dinge wie das Hinzufügen von Escape-Codes und Präfixe an, um den Opcode-Raum künstlich zu erweitern. Als Beispiel betrachten Sie für aktuelle AVX-Anweisungen ein VEX-Präfix, gefolgt von einem alten/recycelten Escape-Code (z. B. 0xF0), gefolgt von einem alten/rezyklierten Adressen-/Operandengrößen-Präfix (z. B. 0x66), gefolgt von weiteren 4 Byte . Es ist nicht schön.

Zur gleichen Zeit gibt es alte Anweisungen, die jetzt selten verwendet werden (AAD, AAM, etc) und Anweisungen mit mehreren/redundanten Opcodes (INC/DEC), die wertvolle "1-Byte" Opcodes verbrauchten. Diese können/können aufgrund der Abwärtskompatibilität nicht vollständig entfernt werden.

Jedoch; Als 64-Bit entwickelt wurde, war einfach kein 64-Bit-Code kompatibel - Rückwärtskompatibilität spielte keine Rolle. Die 1-Byte-Opcodes, die von "nicht sehr wichtigen" Anweisungen verbraucht werden, könnten wiederverwertet werden; diese Anweisungen im 64-Bit-Code ungültig machen (aber einige der wertvollen 1-Byte-Opcodes freigeben).

Die meisten dieser 1-Byte-Opcodes (die gesamte 1-Byte-INC/DEC-Gruppe, wenn ich mich recht erinnere) wurden sofort für das REX-Präfix recycelt, das zur Unterstützung von 64-Bit-Operanden benötigt wurde. Einige waren nicht und wurden "frei für zukünftige Erweiterungen" (mit der Einschränkung, dass die Erweiterung nur in 64-Bit-Code funktionieren kann, da diese Anweisungen immer noch in 16-Bit- und 32-Bit-Code gültig sind).