Warum funktioniert das hexadezimale 'h' Suffix nicht im GNU Assembler, selbst wenn intel_syntax aktiviert ist?

Question

Dies schlägt fehl, obwohl gültige Intel Assembler Syntax zu kompilieren:

.intel_syntax noprefix 
mov rax, 10h 

Während dies gelingt: Ich bin mit Version 2.26.1 Gas

.intel_syntax noprefix 
mov rax, 16 

.

Answer 1

.intel_syntax noprefix schaltet nicht auf NASM-Syntax. Direktiven bleiben gleich, numerische und String-Konstanten bleiben gleich.

Siehe How to represent hex value such as FFFFFFBB in x86 inline assembly programming? für wie verschiedene Assembler lassen Sie Konstanten schreiben.

Die einzigen Dinge, die ändern:

• die offensichtliche großen Sachen wie Operanden um und% und Dekorateure $
• ein paar Mnemotechnik, z.B. movsbl %al, %ecx wird movsx ecx, al
• , wie für den Speicheroperanden, Operand-Größe angeben: DWORD PTR anstelle von S/W/l/q Suffixe
• bloßen Symbolnamen noch refs Speicher sind (MASM-style). Verwenden Sie mov eax, offset symbol_name statt mov $symbol_name, %eax, um sofort zu erhalten.

Alles andere ist immer noch wie dokumentiert in the manual.

GAS .intel_syntax (und objdump -Mintel) hat sogar noch die AT&T syntax design bug, dass die fsubr %st, %st(i) und fsub %st, %st(i) Mnemotechnik umgekehrt sind, auch für andere nichtkommutative x87 Anweisungen mit diesem Muster der Operanden. Danke, AT & T.

Siehe auch x86 Tag Wiki für andere Assembler Handbücher. Wenn Sie die trailing-h-Syntax für hex-Konstanten wirklich mögen, würde ich NASM oder YASM empfehlen. Sie unterstützen sowohl 0DEADBEEFh als auch 0xDEADBEEF (und ähnlich für binär und oktal).