x86_64 ASM – maximale Bytes für eine Anweisung?

Lesezeit: 3 Minuten

Was ist die maximale Anzahl von Bytes, die eine vollständige Anweisung im x64-ASM-Code benötigen würde?

So etwas wie ein Sprung zur Adresse könnte bis zu 9 Bytes belegen, nehme ich an: FF 00 00 00 00 11 12 3F 1F aber ich weiß nicht, ob das die maximale Anzahl von Bytes ist, die ein x64-Befehl verwenden kann

  • Die längstmögliche Anweisung auf x86 ist 15 Bytes

    – 500 – Interner Serverfehler

    5. Februar 2013 um 0:50 Uhr

  • Beachten Sie, dass es zwar möglich ist, eine einzelne Anweisung zu erstellen, die länger als 15 Bytes sein sollte (durch Verwendung einer Reihe von Präfixen), das x86-Befehlsdecoder-Frontend jedoch daran erstickt. 15 Byte ist eine harte Grenze.

    Benutzer149341

    5. Februar 2013 um 0:57 Uhr

  • @duskwuff: Im Intel-Handbuch steht “Bis zu vier Präfixe mit jeweils 1 Byte”. Nach der Spezifikation nehme ich an, dass der Decoder Anweisungen mit mehr als vier Präfixen ablehnen sollte, selbst wenn die Anweisung insgesamt kürzer als 15 Bytes ist. Habe es aber nicht getestet.

    – Jakow Galka

    4. Juni 2018 um 3:01 Uhr

  • Es gibt auch Formen von mov die eine vollständige 64-Bit-Adresse nehmen können, diejenigen, die nehmen moffsals Operand. Sie können sich jedoch nur zum/vom Akkumulator bewegen, sodass die maximal nutzbare Länge für sie immer noch nur 11 Bytes beträgt (8 für die Adresse, 1 für den Opcode, 1 für eine 64- oder 16-Bit-Operandengröße und 1 für a fs- oder gs-Segmentüberschreibung).

    – ughoavgfhw

    5. Februar 2013 um 2:04 Uhr

  • Nebenbei gesagt hat Computer Architecture A Quantitative Approach 17 und jetzt in der 6. Ausgabe 18 Bytes (S. 14). Intel sagt 15 und ich bleibe bei 15.

    – Olsonist

    7. April 2018 um 5:10 Uhr

  • @Olsonist: Es ist möglich, Fälle zu erfinden, in denen eine Anweisung ohne redundante oder nicht anwendbare Präfixe mehr als 15 Bytes zum Codieren erfordern könnte. Solche Anweisungen sind nicht codierbar und fehlerhaft (getestet auf Skylake, Linux liefert SIGSEGV, nicht SIGILL); Sie müssen einen anderen Weg finden, um Ihr Problem zu lösen, z lea eine Adresse bzw mov eine sofortige in ein Register zuerst. Es ist nicht einfach, wirklich plausible Fälle zu finden, z fs xacquire lock add qword [r8d + edx + 1234], 0x1234 wäre 16 Bytes, wenn es gültig wäre. (NASM und YASM bauen es leider beide ohne Vorwarnung zusammen).

    – Peter Cordes

    24. März 2020 um 6:50 Uhr

  • Der Befehlssatz erlegte der Befehlslänge keine Begrenzung auf. Die Grenze wird durch den Befehlsdecodierer definiert

    – phuklv

    8. Juni 2015 um 4:57 Uhr

  • Die ISA für 386 und höher legt eine 15-Byte-Grenze fest. 286 hat eine 10-Byte-Grenze auferlegt. Die Sache mit der “unendlichen” Länge von Insn funktioniert nur auf 8086, nicht auf x86 (oder x86-64), nicht einmal auf einer modernen x86-CPU im Real-Modus. Die zweite Hälfte Ihrer Antwort sollte “andernfalls gültig” lauten. Sie haben das Ende dieser Fußnote ausgelassen, in der es heißt Es ist Sache des Benutzers, diese Fälle (und die daraus resultierende #GP-Ausnahme) zu vermeiden.

    – Peter Cordes

    24. August 2016 um 1:40 Uhr


  • @LưuVĩnhPhúc: mit welchem ​​Assembler baut manlwpins rax,[fs:eax+ebx+disp32],imm32? gnu as erkennt dies nicht.

    – Benutzer2284570

    27. Oktober 2016 um 15:26 Uhr


  • @LưuVĩnhPhúc Da hast du ein besonders schlechtes Beispiel gewählt lwpins hat es nie in Silikon geschafft. Allerdings kenne ich keine andere übermäßig lange Anleitung; VEX hat dieses Problem ziemlich gut gemildert.

    – fuz

    14. September 2017 um 9:49 Uhr

1390320cookie-checkx86_64 ASM – maximale Bytes für eine Anweisung?

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy