2

This fails to compile, despite being valid Intel assembler syntax:

.intel_syntax noprefix
mov rax, 10h

Whereas this succeeds:

.intel_syntax noprefix
mov rax, 16

I'm using version 2.26.1 of gas.

  • With some assemblers (even Intel ones) it is possibly they don't support the hexadecimal suffix `h`. With GAS and Intel syntax use `0x` prefix like `0x10` for hex. `mov rax, 0x10` – Michael Petch Sep 20 '16 at 18:02

1 Answers1

2

.intel_syntax noprefix doesn't switch it to NASM syntax. Directives stay the same, numeric and string constant syntax stays the same.

See How to represent hex value such as FFFFFFBB in x86 inline assembly programming? for how different assemblers let you write constants.

The only things that change are:

  • the obvious major stuff like operand order, and % and $ decorators
  • a few mnemonics, e.g. movsbl %al, %ecx becomes movsx ecx, al
  • how to specify operand-size for memory operands: DWORD PTR instead of b/w/l/q suffixes
  • bare symbol names are still memory refs (MASM-style). To get an immediate, use mov eax, offset symbol_name instead of mov $symbol_name, %eax.

Everything else is still as documented in the manual.

GAS .intel_syntax (and objdump -Mintel) even still has the AT&T syntax design bug that the fsubr %st, %st(i) and fsub %st, %st(i) mnemonics are reversed, same for other non-commutative x87 instructions with that pattern of operands. Thanks, AT&T.

See also the tag wiki for other assembler manuals. If you really like trailing-h syntax for hex constants, I'd recommend NASM or YASM. They support both 0DEADBEEFh and 0xDEADBEEF (and similar for binary and octal).

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847