NOP

A NOP takes up bytes and does nothing else. Compiled code is full of them, almost never executed: they pad the space before a function or a loop that the compiler aligns to 16 bytes, and they reserve bytes that a tool may patch later. The single byte 90 does for one byte; for longer gaps, the multi-byte form 0F 1F /0 takes a ModRM operand whose addressing bytes make the length, and it neither reads nor writes memory, by Intel’s manual.

Long NOPs#

AMD’s Zen 5 guide advises fewer, longer NOPs rather than many short ones, since every NOP still passes through decode and retirement. Intel’s manual and optimization manual list sequences from 2 to 9 bytes (66 90, 0F 1F 00, up to 66 0F 1F 84 00 00 00 00 00), and AMD’s Zen 5 guide continues to 15 bytes by adding 66 prefixes, while warning that only the first of Zen 5’s four decoders takes instructions longer than 10 bytes. The assemblers our builds used fill longer gaps with a CS-prefixed form: GCC’s (GNU as) wrote 66 66 2E 0F 1F 84 00 ..., Clang’s added up to five 66 prefixes.

For patching, -fpatchable-function-entry=5 reserves 5 bytes at each function’s start: GCC 14 emits five 90s, Clang 23 one 5-byte NOP, 0F 1F 44 00 08.

90 is a true NOP#

90 was once XCHG EAX, EAX. In 64-bit mode that would clear bits 63:32 of RAX, so both vendors make plain 90 a real no-operation, as Zen 5 recorded; with REX.B it is still an exchange: 41 90 is XCHG R8D, EAX, which on Zen 5 cleared bits 63:32 of both (49 90 is XCHG R8, RAX). The ModRM form XCHG EAX, EAX (87 C0) does clear the upper half. F3 90 is PAUSE.

Hint space#

0F 18 to 0F 1F are reserved NOPs that new features take over: the prefetches (0F 18), MPX’s bound instructions (0F 1A, 0F 1B), CLDEMOTE (0F 1C /0) and CET’s ENDBR64 (F3 0F 1E FA). Code that uses them runs unchanged, as NOPs, on processors without the feature. XED also decodes 0F 0D with a register operand as a NOP, but Zen 5 raised #UD for it: 0F 0D is AMD’s PREFETCH group, which takes memory.

By Intel’s optimization manual, only the one-byte NOP is specially handled, and a multi-byte NOP’s register operands count as inputs, so a NOP can wait for the instruction that last wrote them.

In the optimization guide

What the optimization guide says about NOP, a line per claim. Each links to the claim in the guide, with its sources and where they differ.

Front end

• Code alignment and padding: Padding that runs is not free: a NOP uses no execution unit but still passes through decode and the retire queue, so a few long NOPs cost less than many short ones, and only a very long stretch of padding is better jumped over.
• Code alignment and padding: How long a NOP may be depends on the core: up to 15 bytes, made by adding 66h prefixes to the 8-byte form, on Zen 3 to Zen 5 (Zen 5), while AMD’s Family 15h slows down with more than three 66h prefixes, so code for every AMD processor stops at 11 bytes.
• Code alignment and padding: Zen 4 fuses a NOP with the instruction next to it, or two NOPs together, which makes padding that runs cheaper there; Zen 5 fuses no NOPs.

Bulldozer to Excavator

• Front end: An instruction with more than three prefixes decodes over ten times slower, so padding is best made of long NOPs (0F 1F) with at most three 66h prefixes, 11 bytes each at most, as LLVM pads for these cores.

Crestmont and Gracemont

• Front end: LLVM pads code for these cores with NOPs of up to 15 bytes, which it expects them to decode quickly; its Tremont tuning does not.

Jaguar and Puma

• Front end: Unlike some older AMD cores, such as the Bulldozer family, Jaguar decodes a NOP with more than three 66h prefixes at full speed, so padding is best a run of 15-byte NOPs and then a shorter one, as LLVM pads for it.

Sandy Bridge and Ivy Bridge

• What Ivy Bridge changed: Sandy Bridge decodes the multi-byte NOP (0F 1F) only on the first of its four decoders, while a NOP padded with 66H prefixes decodes on any of them; Ivy Bridge removes that limit, decoding either form on all four at up to four a cycle.

Silvermont to Goldmont Plus

• Front end: Goldmont drops NOPs before the reservation stations; LLVM pads Silvermont code with NOPs of up to 7 bytes.

Tremont

• Front end: LLVM pads code for Tremont with NOPs of up to 10 bytes, its default when a processor’s tuning names no other length; it uses 7 for Silvermont and 15 for the later E-cores.

Zen and Zen+

• Front end: Padding costs least as a few long NOPs: Zen decodes NOPs of up to 15 bytes, the 8-byte form with 66h prefixes in front, without a penalty, while code that may also run on Family 15h processors should stop at 11 bytes.

Zen 2

• Front end: Padding is cheapest in a few long NOPs: Zen 2 decodes a NOP of up to 15 bytes, the 8-byte form with 66h prefixes added, without a penalty, while code that also runs on Family 15h processors stops at 11 bytes.

Zen 3

• Front end: Padding is cheapest in a few long NOPs: Zen 3 decodes a NOP of up to 15 bytes, the 8-byte form with 66h prefixes added, without a penalty, while code that also runs on earlier AMD processors such as Family 15h stops at 11 bytes.

Zen 4

• Front end: Padding is cheapest in a few long NOPs: Zen 4 decodes a NOP of up to 15 bytes, the 8-byte form with 66h prefixes added, without a penalty, while code that also runs on earlier AMD processors such as Family 15h stops at 11 bytes.
• Front end: A NOP and the integer instruction next to it, or two NOPs, fuse into one macro-op when together at most 15 bytes long, so padding costs less than on earlier cores. sources differ

Zen 5

• Front end: For padding, fewer and longer NOPs are better than many short ones.

Forms

Latency and throughput

Operation

What the forms do, in pseudocode that our tests run against results recorded on real processors. How to read.

pass                         # nothing changes: 90 is not XCHG EAX, EAX,
                             # which would clear bits 63:32 of RAX

pass                         # no register, flag or memory changes
# 0F 1F /0 is the documented multi-byte NOP. 0F 18 is hint space:
# on processors with PREFETCHRST2 and PREFETCHI, /4, /6 and /7 in
# memory are those prefetches

pass                         # no register, flag or memory changes
# 0F 19 to 0F 1E are hint space: on a processor with MPX, CLDEMOTE
# or CET enabled, some of these encodings are those instructions
# instead

fault(UD)                    # 0F 0D is PREFETCH and PREFETCHW: with a
                             # register operand, #UD (APM Volume 3,
                             # PREFETCH, rev. 3.36; Zen 5). XED
                             # decodes a NOP; Intel's manual
                             # gives 0F 0D with memory only

Operands

Flags

None: XED records no flag that the forms test or change.

CPUID and processors

Each form belongs to an XED ISA set. A form can be used when the processor reports every CPUID bit of one of its ISA set's alternatives.

More General-purpose instructions

• JMP
• JRCXZ
• LDS
• LEA
• LEAVE
• LES
• LFS
• LGS
• LODS
• LOOP
• LOOPE
• LOOPNE
• LSS
• MOV
• MOVS
• MOVSX
• MOVSXD
• MOVZX
• MUL
• NEG
• NOT
• OR
• OUT
• OUTS
• PAUSE
• POP
• POPA
• POPF
• PUSH
• PUSHA
• PUSHF
• RCL
• RCR
• RET
• ROL
• ROR
• SALC
• SAR
• SBB
• SCAS

All 109 General-purpose instructions

More PREFETCHW instructions

• PREFETCH
• PREFETCHW