x86-64.net

Instruction

VCVTBF62HF8

Converts packed 6-bit E3M2 floating-point values to E4M3 FP8, which is exact.

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

VCVTBF62HF8 widens 6-bit E3M2 values to E4M3 bytes, exactly. The source is a register whose low three quarters hold the values packed with no gaps, element i in bits 6i+5:6i; its top quarter is not read. Byte i of the destination, a register of the same size, gets element i, under a write mask of one bit per byte: 16, 32 or 64 values for an xmm, ymm or zmm register. There is no memory operand. It belongs to AVX10_V2_AUX of the ACE specification, opcode 37h with the 66 prefix in EVEX map 5, W1; with W0 it is VCVTHF62HF8, from E2M3. It undoes VCVTBF82BF6S, but into E4M3, not into the E5M2 that the values came from.

Why E4M3 holds them all

E3M2 reaches 28 at most, far below E4M3’s 448, and its two fraction bits fit into E4M3’s three. Its denormals, 0.0625 to 0.1875, are normal numbers in E4M3, whose normals start at 2^-6. So nothing is rounded: 1Fh (28) gives 5Eh, 01h (0.0625) gives 18h, and 0Ch (1.0) gives 38h. The sign moves from bit 5 to bit 7. E3M2 has no infinity or NaN, MXCSR is neither read nor written, and nothing is flagged. VCVTHF82PS widens the result further to singles.

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_cvtf6_hf8 is missing from Clang 23’s headers. Zen 5, whose CPUID reports no AVX10, raised #UD in all six recorded cases.

Forms

Every encoding of VCVTBF62HF8 that Intel XED knows, one row per XED instruction form (iform). How to read the notation.
InstructionEncodingRequires
VCVTBF62HF8 xmm {k}{z}, xmm VCVTBF62HF8_XMMhf8_MASKmskw_XMMbf6_AVX512EVEX.128.66.MAP5.W1 37 /rAVX10_V2_AUX + AVX10
VCVTBF62HF8 ymm {k}{z}, ymm VCVTBF62HF8_YMMhf8_MASKmskw_YMMbf6_AVX512EVEX.256.66.MAP5.W1 37 /rAVX10_V2_AUX + AVX10
VCVTBF62HF8 zmm {k}{z}, zmm VCVTBF62HF8_ZMMhf8_MASKmskw_ZMMbf6_AVX512EVEX.512.66.MAP5.W1 37 /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 from 6 bits: each 6-bit element of the source, packed with no gaps, element i in bits 6i+5:6i, becomes a byte, converted, in the same order; the source's bits above them are not read.
VCVTBF62HF8: 6-bit elements packedResult byte i is 6-bit element i of xmm2, from its bits 6i+5:6i, converted. Result bytes 7 to 0: a7, unchanged (bit 6 of k1 is 0), a5, a4, a3, a2, a1, a0.5:011:617:1223:1829:2435:3041:3647:42bits…01234567xmm2a11111110k1…a0a1a2a3a4a5a7xmm1

Shown: the elements 7 to 0 of xmm2, in its bits 47:0, each under its bits, and bytes 7 to 0 of xmm1. Every element works alike: 16, 32 and 64 in the xmm, ymm and zmm forms, from bits 95:0, 191:0 and 383:0. The forms write under a mask: where its bit is 0, the element keeps its old value, or zeroes it with {z}.

Result byte i is 6-bit element i of xmm2, from its bits 6i+5:6i, converted. Result bytes 7 to 0: a7, unchanged (bit 6 of k1 is 0), 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.

if not cpuid_leaf(7, 1)[3] >> 19 & 1:
    fault(UD)                    # CPUID: no AVX10
if not cpuid_leaf(0x24, 1)[2] >> 3 & 1:
    fault(UD)                    # CPUID: no AVX10_V2_AUX
for i in range(VL // 8):         # bits 6i+5:6i to byte i
    x = to_hf8(zmm2.bf6[i])      # exact
    if k1[i]:                    # 1 without a write mask
        zmm1.hf8[i] = x
    elif zeroing:
        zmm1.hf8[i] = 0
    # else: zmm1.hf8[i] keeps its value
# no flags, MXCSR unused
# zmm1 is zeroed from bit VL up

Run on AMD Zen 5 (EPYC 9645): 6 cases. Its cases ran where CPUID reported no AVX10.2, and every one raised an exception.

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
VCVTBF62HF8 xmm {k}{z}, xmm VCVTBF62HF8 ymm {k}{z}, ymm VCVTBF62HF8 zmm {k}{z}, zmm
xmm, ymm, zmmexplicitwrite (masked)
{k}explicitread (write mask)
xmm, ymm, zmmexplicitread

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-E7NM

Attributes

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

All forms
write masking

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.