MPSADBW instruction (SSE4.1)

MPSADBW compares one 4-byte block against eight others at once. The block is a doubleword of the source, picked by imm8[1:0]; the eight candidates are the 4-byte windows of the destination that start at byte p, p + 1, up to p + 7, where imm8[2] sets p to 0 or 4. Each word of the result is the sum of the absolute differences between the block and one window, so word i tells how far the window at byte p + i is from the block. Eleven consecutive bytes of the destination take part. A sum is at most 4 times 255, 1020, so nothing saturates: Zen 5 recorded 03FCh in every word for a block of FFh bytes against zeros. Bits 7:3 of the immediate are ignored; recorded cases with C5h and 1Eh acted as 5 and 6.

A row of a block search

This is the step of motion estimation that slides a block across a row of pixels. A 4x4 block covers four rows: one MPSADBW per row, against the matching row of the reference picture, and three PADDW give the SADs of the whole block at eight horizontal positions. PHMINPOSUW then returns the smallest of them and its position in one instruction. Intel’s optimization manual names that pair as the SSE4.1 path for motion estimation, with fewer data shuffles and more sums per iteration than PSADBW (Section 6.6.10). AMD’s Zen 5 guide lists MPSADBW as four macro-ops with a latency of 5 cycles, against one macro-op and 3 cycles for PSADBW, which gives one sum per quadword.

In compiled code

The instruction comes from _mm_mpsadbw_epu8 in GCC 14 and Clang 23. Written as plain loops, the eight sums are not recognized: at -O2, GCC 14 keeps them scalar, and Clang 23 computes each window with its own PSADBW on four bytes loaded with MOVD.

Legacy, VEX and EVEX

The legacy form overwrites its first operand, keeps bits 128 and up, and needs a memory operand aligned to 16 bytes. VMPSADBW is the VEX form, which takes a separate destination; its 256-bit form of AVX2 repeats the work in the upper lane with its own controls in imm8[5:3], and AVX10.2 adds EVEX forms with masking. VDBPSADBW of AVX-512 is a related four-byte SAD with a shuffle in place of the sliding window.

Forms

Every encoding of MPSADBW that Intel XED knows, one row per XED instruction form (iform). How to read the notation.

Instruction	Encoding	Requires
`MPSADBW xmm, m128, imm8` MPSADBW_XMMdq_MEMdq_IMMb	`66 0F 3A 42 /r ib`	SSE4.1
`MPSADBW xmm, xmm, imm8` MPSADBW_XMMdq_XMMdq_IMMb	`66 0F 3A 42 /r ib`	SSE4.1

Data flow

Where the elements of the sources go, element 0 on the right; results that depend on a control value are drawn for an example. How to read.

Sums of absolute differences over sliding windows: word i of the result adds up the absolute differences between bytes p + i to p + i + 3 of xmm1 (a window, a byte further on for each word) and the four bytes of a block of xmm2; imm8[2] puts p at byte 0 or 4, and imm8[1:0] picks the block's doubleword.

Example: imm8 = 0x06: the windows from byte 4, the block doubleword 2. The sources are drawn in doublewords, with a tick between bytes; each bar under xmm1 is a window, joined to the word it makes.

With imm8 = 0x06, result word i is the sum of the absolute differences between bytes 4+i to 7+i of xmm1 and bytes 8 to 11 of xmm2, byte by byte. Result words 7 to 0: r7, r6, r5, r4, r3, r2, r1, r0.

Operation

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

src1 = xmm1.read()
p = 4 * (imm8 >> 2 & 1)          # the windows: from byte p
q = 4 * (imm8 & 3)               # the block: bytes q to q + 3
for i in range(8):
    s = 0
    for j in range(4):           # window i: bytes p + i on
        x = src1.b[p + i + j]
        s += abs(x - src2.b[q + j])
    xmm1.w[i] = s
# imm8[7:3] are ignored
# bits 128 and up of the register are unchanged

Run on AMD Zen 5 (EPYC 9645): 5 cases.

Operands

What each form reads and writes, as Intel XED records it: the operands of its syntax, in order, and the implicit ones that the syntax does not name. How to read.

Operand	Kind	Action
`MPSADBW xmm, xmm/m128, imm8`
`xmm`	explicit	read, write
`xmm/m128`	explicit	read
`imm8`	explicit	read

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.

All forms: SSE_TYPE_4

Attributes

What else XED records about the forms. How to read.

Memory forms: aligned memory operand

Intrinsics

The C intrinsics of Clang 23.1.2 that compile to MPSADBW, 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.

Intrinsic	Compiles to
`_mm_mpsadbw_epu8` `__m128i _mm_mpsadbw_epu8(__m128i X, __m128i Y, const int M)`	`MPSADBW xmm, xmm, imm8` Legacy -msse4.1

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.

CPUID requirements and processors of the XED ISA sets above. Alternatives are separated by “or”; processors follow XED’s chip model, whose AMD processors end with Zen 2, and the CPU data of this site for Zen 3 to Zen 6.

ISA set	CPUID	Processors
`SSE4` SSE4.1	SSE4.1 `CPUID.01H:ECX[19]` SSE4.1	Penryn, Nehalem, Westmere, Sandy Bridge, Ivy Bridge, Haswell, Broadwell, Skylake, Comet Lake, Cannon Lake, Ice Lake (client), Tiger Lake, Alder Lake, Arrow Lake, Panther Lake, Nova Lake, Skylake-SP, Cascade Lake, Cooper Lake, Ice Lake (server), Sapphire Rapids, Emerald Rapids, Granite Rapids, Diamond Rapids, Silvermont, Goldmont, Goldmont Plus, Tremont, Snow Ridge, Lakefield, Sierra Forest, Clearwater Forest, Knights Landing, Knights Mill, K10 (Family 10h), Bulldozer, Piledriver, Zen, Zen+, Zen 2, Zen 3, Zen 4, Zen 5, Zen 6 Note: XED's AMD_K10 inherits everything from its Westmere chip, including SSSE3, SSE4.1, SSE4.2, AES-NI and PCLMULQDQ; GCC's -march=amdfam10 has none of them.

More SSE4.1 instructions

All 49 SSE4.1 instructions

A row of a block search#

In compiled code#

Legacy, VEX and EVEX#