PMADDUBSW

PMADDUBSW is SSSE3’s byte multiply-add: it multiplies each unsigned byte of the destination by the signed byte of the source in the same position and adds the two products of each pair into a word, clamped to the signed 16-bit range. VPMADDUBSW, its VEX and EVEX form, describes the saturation and the instruction’s place in 8-bit inference; this page covers what is particular to the legacy encodings.

The destination is the unsigned operand#

The two operands are read differently, and the legacy form overwrites the first one, the unsigned bytes, with the result. The same byte value changes meaning with its side: in a case recorded on Zen 5, the bytes FFh and FFh of the destination, times 7Fh and 80h of the source, gave 255 times 127 plus 255 times -128, or -255 (FF01h). In _mm_maddubs_epi16(a, b), a holds the unsigned bytes. Since the result replaces them, a compiler copies registers whenever they are still needed or sit in the wrong register: for _mm_maddubs_epi16(b, a), with the unsigned bytes in the second argument’s register, GCC 14 at -O2 adds two MOVDQA and Clang 23 one, while the VEX form, with a separate destination, needs none.

Forms and requirements#

• The XMM form needs SSSE3, which the x86-64-v2 level includes and the baseline does not. Its memory operand must be aligned to 16 bytes, as for most legacy SSE instructions; the VEX form drops that rule.
• The MMX form works on four words in an MMX register, with the x87 side effects of every MMX instruction (see MOVD and EMMS). Its intrinsic _mm_maddubs_pi16 does not produce it: GCC 14 and Clang 23 compile it to the XMM form.

Neither compiler turns the C loop shown on the VEX page into PMADDUBSW with -mssse3 or -march=x86-64-v2: the instruction comes from the intrinsic, or, with AVX2, from Clang’s pattern match.

The usual next step is PMADDWD with a vector of ones, which adds pairs of these words into doublewords. AMD’s Zen 5 guide lists PMADDUBSW with a latency of three cycles, like the VEX form.

Forms

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(4):
    x = 0
    for j in range(2 * i, 2 * i + 2):
        x += mm1.b[j] * src2.sb[j]
    mm1.w[i] = ssat(x, 16)
# x87: TOP = 0, all tags valid, bits 79:64 of mm1's register all ones

for i in range(8):
    x = 0
    for j in range(2 * i, 2 * i + 2):
        x += xmm1.b[j] * src2.sb[j]
    xmm1.w[i] = ssat(x, 16)
# bits 128 and up of the register are unchanged

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.

PMADDUBSW mm, mm/m64

mmx-mem

PMADDUBSW xmm, xmm/m128

SSE_TYPE_4

Attributes

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

PMADDUBSW mm, mm/m64

may abort a TSX transaction

PMADDUBSW xmm, m128

aligned memory operand

Intrinsics

The C intrinsics of Clang 23.1.2 that compile to PMADDUBSW, 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 SSSE3 instructions

• PABSB
• PABSD
• PABSW
• PALIGNR
• PHADDD
• PHADDSW
• PHADDW
• PHSUBD
• PHSUBSW
• PHSUBW
• PMULHRSW
• PSHUFB
• PSIGNB
• PSIGND
• PSIGNW