VPMOVUSWB

VPMOVUSWB narrows unsigned words to bytes, clamping each to 255: 32 words of a ZMM register become 32 bytes in a YMM register or in memory, 16 from a YMM register and 8 from an XMM one. It is the saturating unsigned form of VPMOVWB, whose page shows the masked store and the merge into a register, and the word form of VPMOVUSDB, whose page explains the unsigned source; VPMOVSWB saturates signed words to -128 and 127. It needs AVX512BW.

Recorded on Zen 5#

• Unsigned limits. {evex} vpmovuswb xmmword ptr [mem], ymm5 turned 007Fh, 0080h and 0081h into 7Fh, 80h and 81h, and FF80h, 00FFh, 0100h and 8000h all into FFh: a word read as signed, such as FF80h for -128, is large here.
• Register form. vpmovuswb xmm0, xmm31 wrote eight bytes, FFh five times, then 55h, 00h and 01h, and cleared XMM0 above bit 63.
• Masked store. vpmovuswb qword ptr [mem]{k2}, xmm0, with C9h in the low byte of K2, wrote bytes 0, 3, 6 and 7 and left the other four as they were.

In compiled code#

For d[i] = x > 255 ? 255 : x over uint16_t and uint8_t arrays, Clang 23 at -O2 with -march=x86-64-v4 stores 16 bytes at a time with vpmovuswb xmmword ptr [...], ymm0, also in a loop of unknown length, and for int16_t input clamped to 0 to 255 it takes VPMAXSW against zero first. GCC 14 clamps with VPMINUW against 255, or VPMAXSW and VPMINSW, then truncates with VPMOVWB and joins two halves with VINSERTI64X4, as VPMOVWB’s page shows; the loop of unknown length goes one element at a time. Both compile _mm512_cvtusepi16_epi8 to vpmovuswb ymm0, zmm0. With PACKUSWB, the source is signed and a negative word becomes 0.

AMD’s Zen 5 latency spreadsheet gives the register forms one macro-op on pipe FP1 or FP2, with 2 cycles from an XMM source and 4 from a YMM or ZMM one, and the memory forms two macro-ops, 5 cycles from a YMM or ZMM register, as VPMOVWB.

Forms

Latency and throughput

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.

Operation

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

for i in range(VL // 16):
    if k1[i]:
        ymm1.b[i] = usat(zmm2.w[i], 8)
    elif zeroing:
        ymm1.b[i] = 0
    # else: ymm1.b[i] keeps its value
for i in range(VL // 16, 16):
    ymm1.b[i] = 0
# ymm1 is zeroed from bit 128 (xmm) or 256 (ymm) up

for i in range(VL // 16):
    if k1[i]:
        mem.b[i] = usat(zmm2.w[i], 8)
    # else: mem.b[i] is not written

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.

Register forms

AVX512-E6NF

Memory forms

AVX512-E6

Attributes

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

All forms

write masking

Memory forms

memory fault suppression

Intrinsics

The C intrinsics of Clang 23.1.2 that compile to VPMOVUSWB, 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 AVX10.1 instructions

• VPMOVQB
• VPMOVQD
• VPMOVQW
• VPMOVSDB
• VPMOVSDW
• VPMOVSQB
• VPMOVSQD
• VPMOVSQW
• VPMOVSWB
• VPMOVSXBD
• VPMOVSXBQ
• VPMOVSXBW
• VPMOVSXDQ
• VPMOVSXWD
• VPMOVSXWQ
• VPMOVUSDB
• VPMOVUSDW
• VPMOVUSQB
• VPMOVUSQD
• VPMOVUSQW
• VPMOVW2M
• VPMOVWB
• VPMOVZXBD
• VPMOVZXBQ
• VPMOVZXBW
• VPMOVZXDQ
• VPMOVZXWD
• VPMOVZXWQ
• VPMULDQ
• VPMULHRSW
• VPMULHUW
• VPMULHW
• VPMULLD
• VPMULLQ
• VPMULLW
• VPMULTISHIFTQB
• VPMULUDQ
• VPOPCNTB
• VPOPCNTD
• VPOPCNTQ

All 686 AVX10.1 instructions