PACKUSWB instruction (MMX, SSE2)

PACKUSWB narrows words to bytes: it reads every word of both operands as a signed number, clamps it to the range 0 to 255, and writes the destination’s words to the low half of the result and the source’s to the high half. A negative word gives 00h and anything above 255 gives FFh. In _mm_packus_epi16(a, b), the bytes from a come first.

The usual job is the way back from widened arithmetic. Byte data is unpacked to words with PUNPCKLBW or PMOVZXBW, worked on in 16 bits where a sum or a product cannot overflow, and packed again. The clamp is then exactly what pixel arithmetic needs. How GCC 14 and Clang 23 use it at -O2, compiling for the SSE2 baseline:

Truncating uint16_t elements to uint8_t is not what PACKUSWB does, so both compilers first clear each word’s high byte with PAND against a vector of 00FFh, after which the clamp changes nothing.
Clamping an int16_t to 0..255 in C is one PACKUSWB per 16 results for Clang. GCC clamps with PMINSW and PMAXSW, masks with PAND and then packs.

The signed reading is the trap, and Intel’s optimization manual points out that every pack instruction reads its sources as signed (Section 6.4.3). A word of 8000h or more counts as negative, so an unsigned value such as 300 gives FFh as expected but 40000 gives 00h. Only AVX-512’s VPMOVUSWB treats words as unsigned, and VPMOVWB truncates.

The 256-bit VPACKUSWB of AVX2 packs each 128-bit lane on its own, so the result holds eight bytes of the first source, eight of the second, then the next eight of each: data packed across a whole register comes out with its middle quarters swapped. Compiling the truncating loop with -mavx2, GCC repairs the order with VPERMQ and the immediate D8h; Clang instead packs the two halves of each 256-bit vector as 128-bit operands.

The legacy SSE2 form needs a memory operand aligned to 16 bytes. PACKSSWB clamps words to signed bytes, PACKSSDW doublewords to signed words, and PACKUSDW, which came only with SSE4.1, doublewords to unsigned words.

Forms

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

Instruction	Encoding	Requires
`PACKUSWB mm, m64` PACKUSWB_MMXq_MEMq	`NP 0F 67 /r`	MMX
`PACKUSWB mm, mm` PACKUSWB_MMXq_MMXq	`NP 0F 67 /r`	MMX
`PACKUSWB xmm, m128` PACKUSWB_XMMdq_MEMdq	`66 0F 67 /r`	SSE2
`PACKUSWB xmm, xmm` PACKUSWB_XMMdq_XMMdq	`66 0F 67 /r`	SSE2

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.

Pack: the words of both sources are narrowed to bytes with saturation; those of xmm1 fill the low half, those of xmm2 the high half.

Result bytes 15 to 0: b7, b6, b5, b4, b3, b2, b1, b0, a7, a6, a5, a4, a3, a2, a1, a0.

Operation

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

PACKUSWB mm, mm/m64

src1 = mm1.read()  # mm1 as it was
for i in range(8):
    j = i % 4
    if i < 4:
        mm1.b[i] = usat(src1.sw[j], 8)
    else:
        mm1.b[i] = usat(src2.sw[j], 8)
# x87: TOP = 0, all tags valid, bits 79:64 of mm1's register all ones

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

PACKUSWB xmm, xmm/m128

src1 = xmm1.read()  # xmm1 as it was
for i in range(16):
    j = i % 8
    if i < 8:
        xmm1.b[i] = usat(src1.sw[j], 8)
    else:
        xmm1.b[i] = usat(src2.sw[j], 8)
# bits 128 and up of the register are unchanged

Run on AMD Zen 5 (EPYC 9645): 2 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
`PACKUSWB mm, mm/m64`
`mm`	explicit	read, write
`mm/m64`	explicit	read
`PACKUSWB xmm, xmm/m128`
`xmm`	explicit	read, write
`xmm/m128`	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.

PACKUSWB mm, m64: mmx-mem
PACKUSWB mm, mm: none in XED
PACKUSWB xmm, xmm/m128: SSE_TYPE_4

Attributes

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

PACKUSWB mm, mm/m64: may abort a TSX transaction
PACKUSWB xmm, m128: aligned memory operand

Intrinsics

The C intrinsics of Clang 23.1.2 that compile to PACKUSWB, 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_packus_epi16` `__m128i _mm_packus_epi16(__m128i __a, __m128i __b)`	`PACKUSWB xmm, xmm` Legacy -msse2

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
`PENTIUMMMX` MMX	MMX `CPUID.01H:EDX[23]` MMX	Every x86-64 processor in XED’s model and Zen 3 to Zen 6
`SSE2` SSE2	SSE2 `CPUID.01H:EDX[26]` SSE2	Every x86-64 processor in XED’s model and Zen 3 to Zen 6

More MMX instructions

All 47 MMX instructions

More SSE2 instructions

All 124 SSE2 instructions