PUSH

In 64-bit code PUSH appears mostly in function prologues, saving the callee-saved registers a function is about to use; the epilogue restores them with POP in the reverse order. Each push moves RSP by 8, which matters for the ABIs’ rule that RSP is a multiple of 16 at every call: a function entered with RSP 8 past a multiple of 16 is aligned again after an odd number of pushes, and after an even number must move RSP by another 8 before it calls anything (see stack frames). For that slot GCC 14 subtracts 8 from RSP, while Clang 23 may push RAX instead, whose value does not matter.

Operand sizes in 64-bit mode:

• 64 bits by default, without a REX prefix.
• 16 bits with a 66 prefix, which moves RSP by only 2 and leaves it misaligned.
• 32 bits cannot be encoded, as Intel’s and AMD’s manuals both say.

An immediate is sign-extended to 64 bits. push -1 stores eight FFH bytes, and no PUSH stores 0000000080000000H, because the 32-bit immediate 80000000H becomes FFFFFFFF80000000H; such a constant goes through a register.

Two cases involve RSP itself. PUSH RSP stores the value RSP had before the instruction, as both manuals say and Zen 5 recorded. A memory operand addressed through RSP, such as push qword [rsp+8], is read at the address computed before RSP moves, by Intel’s manual; AMD’s does not say.

PUSH FS and PUSH GS remain in 64-bit mode and store the selector zero-extended to 8 bytes (Zen 5 writes all 8); PUSH of CS, DS, ES and SS is invalid there.

AMD’s optimization guide for Zen 5 says the processor tracks the stack pointer when it renames registers, so a run of PUSH, POP, CALL and RET does not wait for each RSP update. An instruction that uses RSP outside the forms the guide lists, PUSH RSP among them, costs an extra operation and restarts the tracking.

APX adds PUSH2, which pushes two registers at once, and PUSHP, a PUSH with a hint that a matching POPP will follow.

In the optimization guide

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

Out of order

• Renaming and the window: A stack engine lets PUSH, POP, CALL and RET change RSP with no execution unit and no wait, though an explicit use of RSP between them can cost an extra micro-op.

Jaguar and Puma

• Front end: A sideband stack optimizer in the decoder tracks the stack pointer, so a chain of PUSH and POP instructions does not wait on each update of rSP.

Silvermont to Goldmont Plus

• Front end: On Silvermont these instructions come from the microcode ROM; Goldmont decodes them directly, except an indirect call through memory.
• Out-of-order and in-order execution: Goldmont tracks the stack pointer of push, pop, call and ret without spending allocation or execution slots on it, and runs push and pop three a cycle where Silvermont runs one.
• Out-of-order and in-order execution: LLVM’s tuning for all four cores loads the operand of push and call into a register first, and prefers movbe to a load and a bswap.

Tremont

• Integer execution: LLVM’s tuning treats push, pop and call with a memory operand as slow on this core and loads the operand into a register first.

Zen and Zen+

• Integer execution: The decoder tracks RSP, so chains of PUSH and POP do not wait for each other; Agner Fog found PUSH, POP and RET to be one macro-op each, with no latency on RSP.

Zen 2

• Integer execution: A stack engine tracks RSP, so chains of PUSH and POP do not wait for each other; Agner Fog found PUSH, POP and RET to be one macro-op each with no latency on RSP.

Zen 3

• Integer execution: PUSH, POP, CALL and RET update RSP without a dependency, and loads, stores, lea and mov from RSP can use the tracked value.

Zen 4

• Integer execution: PUSH, POP, CALL and RET update RSP without a dependency, and loads, stores, lea and mov from RSP can use the tracked value.

Zen 5

• Integer execution: PUSH, POP, CALL and RET update RSP without a dependency, and loads, stores, lea and add or sub of a small immediate through RSP can use the tracked value.

Forms

Latency and throughput

Operation

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

v = sext(src)                    # an immediate is sign-extended to OSIZE
a = rsp - OSIZE // 8             # 8 bytes, or 2 with a 66 prefix
store(a, OSIZE, v)               # PUSH RSP pushes RSP from before
rsp = a

a = rsp - OSIZE // 8
store(a, OSIZE, src)             # the selector, zero-extended
rsp = a

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

• LOOP
• LOOPE
• LOOPNE
• LSS
• MOV
• MOVS
• MOVSX
• MOVSXD
• MOVZX
• MUL
• NEG
• NOP
• NOT
• OR
• OUT
• OUTS
• PAUSE
• POP
• POPA
• POPF
• PUSHA
• PUSHF
• RCL
• RCR
• RET
• ROL
• ROR
• SALC
• SAR
• SBB
• SCAS
• SETcc
• SHL
• SHLD
• SHR
• SHRD
• STC
• STD
• STI
• STOS

All 109 General-purpose instructions