MOVBE

MOVBE is a load or a store that reverses the byte order on the way, for data kept big-endian: network headers, many file formats, hash outputs such as SHA-256’s. It replaces a plain move followed or preceded by BSWAP, and the store form leaves its source register untouched, which a BSWAP in place would not. One operand must be memory: there is no register-to-register form outside APX, and BSWAP covers that case. Flags are unchanged.

Compilers find it#

Nobody needs an intrinsic. With -mmovbe or an -march that has it (x86-64-v3, haswell, znver1 and later), GCC 14 and Clang 23 at -O2 turn __builtin_bswap32 of a value loaded with memcpy into a single movbe eax, dword ptr [rdi], and a 64-bit byte-swapped store into movbe qword ptr [rdi], rsi. They even recognize the portable expression p[0] << 24 | p[1] << 16 | p[2] << 8 | p[3] and emit the same single MOVBE. Without the flag they load and BSWAP, or for 16 bits load and rol ax, 8. A swap of a value already in a register stays a BSWAP.

Register widths#

As for other 16-bit writes, MOVBE to a 16-bit register keeps bits 63:16, and to a 32-bit one clears bits 63:32: on Zen 5, movbe cx, word ptr [...] replaced only CX, and movbe ecx, dword ptr [...] left 0 in the upper half of RCX. This is the 16-bit byte swap that BSWAP lacks, whose 16-bit form is undefined. Zen 5 ran every size of both forms with distinct byte patterns, and each came out reversed.

Encoding#

MOVBE is 0F 38 F0 (load) and 0F 38 F1 (store); the same bytes with an F2 prefix are CRC32. APX’s EVEX forms add the register-to-register move. The CPUID bit is leaf 1, ECX bit 22. Intel’s Atom had MOVBE before Intel’s big cores, which gained it with Haswell; AMD’s processors have it from Zen on, and Excavator before. AMD’s Zen 5 guide lists MOVBE as a single macro-op.

In the optimization guide

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

Silvermont to Goldmont Plus

• 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 prefers movbe to a load and bswap, or to bswap and a store, on this core.

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 = src.read()
r = 0
for i in range(OSIZE // 8):
    r = r << 8 | (v >> 8 * i & 0xFF)   # the bytes in reverse order
dest.write(r)                    # a 16-bit register keeps bits 63:16, a
                                 # 32-bit one gets bits 63:32 cleared

Operands

Flags

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

Exceptions

The exception class is XED's name for the set of exception conditions that a form follows. How to read.

Legacy forms

none in XED

EVEX forms

APX-EVEX-INT

Intrinsics

The C intrinsics of Clang 23.1.2 that compile to MOVBE, each with the form it compiles to and the Clang options it needs. The forms come from compiling every intrinsic and decoding the result with Intel XED; all intrinsics A–Z explains the method.

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 APX instructions

• CMPccXADD
• CRC32
• CTESTscc
• DEC
• DIV
• ENQCMD
• ENQCMDS
• IDIV
• IMUL
• INC
• INVEPT
• INVPCID
• INVVPID
• JMPABS
• KMOVB
• KMOVD
• KMOVQ
• KMOVW
• LDTILECFG
• LZCNT
• MOVDIR64B
• MOVDIRI
• MOVRS
• MUL
• MULX
• NEG
• NOT
• OR
• PDEP
• PEXT
• POP2
• POP2P
• POPCNT
• POPP
• PUSH2
• PUSH2P
• PUSHP
• RCL
• RCR
• RDMSR

All 88 APX instructions