x86-64.net

Instruction

VCVTBF42HF8

Converts packed 4-bit E2M1 floating-point values to E4M3 FP8, which is exact.

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

VCVTBF42HF8 widens 4-bit E2M1 values to E4M3 bytes, exactly. The source holds two values per byte, element i in bits 4i+3:4i: 64, 128 or 256 bits of an xmm or ymm register or of memory give 16, 32 or 64 bytes in an xmm, ymm or zmm register, under a write mask of one bit per byte. There is no broadcast. It belongs to AVX10_V2_AUX of the ACE specification, opcode 37h with no prefix in EVEX map 5, W0. It undoes VCVTBF82BF4S and VCVTHF82BF4S, but always to E4M3: no form gives E5M2.

Eight values

E2M1 has eight magnitudes, and each has an E4M3 encoding: 0 gives 00h, 0.5 gives 30h, 1 gives 38h, 1.5 gives 3Ch, 2 gives 40h, 3 gives 44h, 4 gives 48h and 6 gives 4Ch. The sign, bit 3 of the nibble, becomes bit 7, so 8h, a negative zero, gives 80h, and Fh, -6, gives CCh. E2M1 has no infinity or NaN to carry over, nothing is rounded, MXCSR is neither read nor written, and nothing is flagged. The single denormal of E2M1, 0.5, is a normal number in E4M3.

Widening once more with VCVTHF82PS gives singles, and with VCVTHF82PH halves, both exactly.

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_cvtbf4_hf8 is missing from Clang 23’s headers. This site’s recorded cases include none of VCVTBF42HF8.

Forms

Every encoding of VCVTBF42HF8 that Intel XED knows, one row per XED instruction form (iform). How to read the notation.
InstructionEncodingRequires
VCVTBF42HF8 xmm {k}{z}, xmm VCVTBF42HF8_XMMhf8_MASKmskw_XMMbf4_AVX512EVEX.128.NP.MAP5.W0 37 /rAVX10_V2_AUX + AVX10
VCVTBF42HF8 xmm {k}{z}, m64 VCVTBF42HF8_XMMhf8_MASKmskw_MEMbf4_AVX512EVEX.128.NP.MAP5.W0 37 /rAVX10_V2_AUX + AVX10
VCVTBF42HF8 ymm {k}{z}, xmm VCVTBF42HF8_YMMhf8_MASKmskw_XMMbf4_AVX512EVEX.256.NP.MAP5.W0 37 /rAVX10_V2_AUX + AVX10
VCVTBF42HF8 ymm {k}{z}, m128 VCVTBF42HF8_YMMhf8_MASKmskw_MEMbf4_AVX512EVEX.256.NP.MAP5.W0 37 /rAVX10_V2_AUX + AVX10
VCVTBF42HF8 zmm {k}{z}, ymm VCVTBF42HF8_ZMMhf8_MASKmskw_YMMbf4_AVX512EVEX.512.NP.MAP5.W0 37 /rAVX10_V2_AUX + AVX10
VCVTBF42HF8 zmm {k}{z}, m256 VCVTBF42HF8_ZMMhf8_MASKmskw_MEMbf4_AVX512EVEX.512.NP.MAP5.W0 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: each 4-bit element becomes a byte, converted, in the same order.
VCVTBF42HF8: each element widenedResult bytes 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 m64a1111111111111110k1a0a1a2a3a4a5a6a7a8a9a10a11a12a13a15xmm1

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

Result bytes 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 // 8):
    if k1[i]:
        zmm1.hf8[i] = to_hf8(src2.bf4[i])
    elif zeroing:
        zmm1.hf8[i] = 0
    # else: zmm1.hf8[i] keeps its value
# BF4: 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
VCVTBF42HF8 xmm {k}{z}, xmm/m64 VCVTBF42HF8 ymm {k}{z}, xmm/m128 VCVTBF42HF8 zmm {k}{z}, ymm/m256
xmm, ymm, zmmexplicitwrite (masked)
{k}explicitread (write mask)
xmm/m64, xmm/m128, ymm/m256explicitread

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

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.