x86-64.net

Instruction

VCVTBF82PS

Converts packed E5M2 FP8 values to single precision, which is exact.

Extensions
Forms
6 (6 EVEX)
Data
Intel XED v2026.08.23

VCVTBF82PS widens E5M2 bytes to singles: the low 4, 8 or 16 bytes of an xmm register, or 32, 64 or 128 bits of memory, become 4, 8 or 16 singles in an xmm, ymm or zmm register, under a write mask of one bit per single. There is no broadcast. Every E5M2 value is a single, so nothing is rounded: MXCSR is neither read nor written, nothing is flagged, and DAZ does not apply, so E5M2’s denormals become normal singles (01h gives 2^-16). It belongs to AVX10_V2_AUX of the ACE specification: opcode 36h with no prefix in EVEX map 5, W1; with W0 the same opcode is VCVTHF82PS, for E4M3. VCVTPS2BF8 goes the other way.

Specials

Infinities stay infinite. E5M2’s NaNs, 7Dh to 7Fh and FDh to FFh, become quiet single NaNs of the same sign, the quiet bit set and the byte’s last fraction bit moved to bit 21: 7Dh and 7Fh give 7FE00000h, and 7Eh gives 7FC00000h. Zeros keep their sign.

Through halves

An E5M2 byte is the upper byte of a half, so AVX10.2 code can widen it with VPMOVZXBW and a shift left by 8, and then VCVTPH2PS. That gives the same singles, but not quietly: 7Dh becomes the half 7D00h, a signaling NaN, for which VCVTPH2PS sets IE in MXCSR or raises #XM. VCVTBF82PS does the whole widening in one instruction and flags nothing.

In our builds

GCC 14 and Clang 23 have no option for AVX10_V2_AUX: Clang 23’s assembler and GNU as 2.44 reject the mnemonic, and ACE’s intrinsic _mm512_cvtbf8_ps is missing from Clang 23’s headers. This site’s recorded cases include none of VCVTBF82PS.

Forms

Every encoding of VCVTBF82PS that Intel XED knows, one row per XED instruction form (iform). How to read the notation.
InstructionEncodingRequires
VCVTBF82PS xmm {k}{z}, xmm VCVTBF82PS_XMMf32_MASKmskw_XMMbf8_AVX512EVEX.128.NP.MAP5.W1 36 /rAVX10_V2_AUX + AVX10
VCVTBF82PS xmm {k}{z}, m32 VCVTBF82PS_XMMf32_MASKmskw_MEMbf8_AVX512EVEX.128.NP.MAP5.W1 36 /rAVX10_V2_AUX + AVX10
VCVTBF82PS ymm {k}{z}, xmm VCVTBF82PS_YMMf32_MASKmskw_XMMbf8_AVX512EVEX.256.NP.MAP5.W1 36 /rAVX10_V2_AUX + AVX10
VCVTBF82PS ymm {k}{z}, m64 VCVTBF82PS_YMMf32_MASKmskw_MEMbf8_AVX512EVEX.256.NP.MAP5.W1 36 /rAVX10_V2_AUX + AVX10
VCVTBF82PS zmm {k}{z}, xmm VCVTBF82PS_ZMMf32_MASKmskw_XMMbf8_AVX512EVEX.512.NP.MAP5.W1 36 /rAVX10_V2_AUX + AVX10
VCVTBF82PS zmm {k}{z}, m128 VCVTBF82PS_ZMMf32_MASKmskw_MEMbf8_AVX512EVEX.512.NP.MAP5.W1 36 /rAVX10_V2_AUX + AVX10

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.

Widen: each byte becomes a single, converted, in the same order.
VCVTBF82PS: each element widenedResult singles 15 to 0: a15, unchanged (bit 14 of k1 is 0), a13, a12, a11, a10, a9, a8, a7, a6, a5, a4, a3, a2, a1, a0.0123456789101112131415xmm2or m128a1111111111111110k1a0a1a2a3a4a5a6a7a8a9a10a11a12a13a15zmm1

Shown for the zmm form; the xmm and ymm forms work the same on 4 and 8 bytes. The forms write under a mask: where its bit is 0, the element keeps its old value, or zeroes it with {z}.

Result singles 15 to 0: a15, unchanged (bit 14 of k1 is 0), a13, a12, a11, a10, a9, a8, 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.

for i in range(VL // 32):
    if k1[i]:
        zmm1.f32[i] = to_f32(src2.bf8[i])
    elif zeroing:
        zmm1.f32[i] = 0
    # else: zmm1.f32[i] keeps its value
# BF8: exact, no flags; MXCSR unused
# zmm1 is zeroed from bit VL up

Not run on a processor: none of these processors has AVX10.2. The tests check its arithmetic against MPFR.

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.
OperandKindAction
VCVTBF82PS xmm {k}{z}, xmm/m32 VCVTBF82PS ymm {k}{z}, xmm/m64 VCVTBF82PS zmm {k}{z}, xmm/m128
xmm, ymm, zmmexplicitwrite (masked)
{k}explicitread (write mask)
xmm/m32/64/128explicitread

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
AVX512-E4

Attributes

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

All forms
write masking
Memory forms
memory fault suppression

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 setCPUIDProcessors
AVX10_V2_AUX_128

AVX10_V2_AUX + AVX10
CPUID.(EAX=24H,ECX=1):ECX[3] AVX10_V2_AUX
CPUID.(EAX=07H,ECX=1):EDX[19] AVX10

None in XED’s chip model, which lists these instructions only under its placeholder for future processors.
AVX10_V2_AUX_256
Same as AVX10_V2_AUX_128None in XED’s chip model, which lists these instructions only under its placeholder for future processors.
AVX10_V2_AUX_512
Same as AVX10_V2_AUX_128None in XED’s chip model, which lists these instructions only under its placeholder for future processors.

More AVX10_V2_AUX instructions

Sources

  1. Intel XED v2026.08.23 (commit 0bcb6237345c): forms, encodings, operands, flags, exception classes, attributes, ISA sets, CPUID bits and chip model.
  2. x86 Ecosystem Advisory Group: AI Compute Extensions (ACE) Specification, version 1.16.2 (July 2026)

The tables are derived from Intel XED, Copyright Intel Corporation, licensed under the Apache License 2.0; x86-64.net converted and reformatted them. The text is our own.