VEX prefix

Last updated

The VEX prefix (from "vector extensions") and VEX coding scheme are an extension to the x86-64 instruction set architecture for microprocessors from Intel, AMD and others. It was introduced with the AVX instruction set.

Contents

The VEX prefix consists of three bytes and can be added to new and existing instructions. It is a superset of the REX prefix and provides 16 bits of payload in total. The VEX prefix can also be encoded into a shorter two-byte variant, if the omitted bits have specific values.

Features

The VEX coding scheme allows the definition of new instructions and the extension or modification of previously existing instruction codes. This serves the following purposes:

The VEX prefix replaces the most commonly used instruction prefix bytes and escape bytes. In many cases, the number of prefix bytes and escape bytes that are replaced is the same as the number of bytes in the VEX prefix, so that the total length of the VEX-encoded instruction is the same as the length of the legacy instruction code. In other cases, the VEX-encoded version is longer or shorter than the legacy code. In 32-bit mode VEX encoded instructions can only access the first 8 YMM/XMM registers; the encodings for the other registers would be interpreted as the legacy LDS and LES instructions that are not supported in 64-bit mode.

SSE Semantic difference

While it is required for 256-bit AVX operations, the VEX prefix simply provides an alternative encoding for 128-bit SSE operations. For the most part, the operation is identical no matter which encoding is used. There is, however, one major difference:

When a VEX prefix is used, the high bits of the destination register are cleared (zeroed), while SSE operations without VEX leave the high bits of destination SIMD registers unmodified.

This does not affect the computation itself, but does affect any required save and restore operations. In particular, a called function written without knowledge of AVX or VEX may save a callee-saved register, use the register, and restore its value, using 128-bit operations, all without disturbing the more-significant bits.

This merging of unmodified and newly-computed portions of a register is difficult for the (now-ubiquitous) optimization of register renaming, as the unchanged portions of the destination register must be copied to the renamed destination register. x86 processors use special techniques to optimize this (such as the vzeroupper instruction), but it still comes at a performance penalty. [1]

Instruction encoding

Instruction format using the VEX prefix
# of bytes0, 2, 3110, 10, 1, 2, 40, 1
Part[Prefixes][VEX]OPCODEModR/M[SIB][DISP][IMM]

The VEX coding scheme uses a opcode prefix consisting of two or three bytes, which may be added to existing or new instruction codes. [2]

Two instructions (that were previously defined as invalid opcodes in 64-bit mode) were repurposed as the leading byte of the new VEX prefixes: 0xC4 for the three-byte variant and 0xC5 for the two-byte variant.

The VEX prefix replaces the 0x66, 0xF2 and 0xF3 opcode prefixes, the REX prefix, and the 0x0F, 0x0F 0x2E or 0x0F 0x3E opcode prefixes. It may not be used with one-byte opcodes which do not begin with 0x0F, nor with the LOCK (0xF0) prefix. It may be preceded only by address size (0x67) or segment (0x26, 0x2E, 0x36, 0x3E, 0x64, 0x65) prefixes.

In the x86 architecture, instructions with a memory operand almost always use the ModR/M byte which specifies the addressing mode. This byte has three bit fields:

The base-plus-index and scale-plus-index forms of 32-bit addressing (encoded with r/m = 100 and mod ≠ 11) require another addressing byte, the SIB byte. It has the following fields:

VEX encoding
ByteBit
VEX3 (3-byte VEX)
76543210
0 (0xC4)11000100
1m4m3m2m1m0
2W3210Lp1p0
VEX2 (2-byte VEX)
76543210
0 (0xC5)11000101
13210Lp1p0

The VEX3 prefix contains all bit-fields from the REX prefix as well as various other prefixes, expanding addressing mode, register enumeration, operand size and width:

The VEX2 prefix is a 2-byte abbreviation of the VEX3 prefix, which may be used when the omitted fields have the following values:

Instructions which require different values for these fields must be encoded with the VEX3 prefix. VEX2 does include an R̅ bit, an L bit, two p bits, and an additional 4-bit source register (v), so is useful for many SSE and AVX instructions as long as the register/memory operand uses only the first 8 registers.

Register addressing in 64-bit mode using VEX prefix
Addressing modeBit 3Bits [2:0]Register typeCommon usage
REGVEX.RModRM.regGeneral purpose, mask, vectorRegister operand
RM (if ModRM.mod = 11)VEX.BModRM.r/mGPR, mask, vectorRegister operand
RMVEX.BModRM.r/mGPRRegister memory address
BASEVEX.BSIB.baseGPRBase + index × scale memory address
INDEXVEX.XSIB.indexGPRBase + index × scale memory address
VIDXVEX.XSIB.indexVectorBase + vector index × scale memory address
NDS/NDDVEX.v3v2v1v0GPR, mask, vectorRegister operand
IS4Imm8[7:4]VectorRegister operand

Technical description

Instructions coded with the VEX prefix can have up to four variable operands (in registers or memory) and one constant operand (immediate value). Instructions that need more than three variable operands use immediate operand bits to specify a 4th register operand (IS4 above). At most one of the operands can be a memory operand; and at most one of the operands can be an immediate constant of 4 or 8 bits. The remaining operands are registers.

The AVX instruction set is the first instruction set extension to use the VEX coding scheme. The AVX instruction set uses the VEX prefix only for instructions using the SIMD XMM registers.

However, the VEX coding scheme has been used for other instruction types as well in subsequent expansions of the instruction set. For example:

The VEX prefix's initial-byte values, 0xC4 and 0xC5, are the same as the opcodes of the LDS and LES instructions. Not supported in 64-bit mode, the ambiguity is resolved in 32-bit mode by exploiting the fact that a legal LDS or LES's ModR/M byte cannot specify a register source operand; i.e., be of the form 11xxxxxx. Various bit-fields in the VEX prefix's second byte are inverted to ensure that the byte is always of this form.

Legacy SIMD instructions with a VEX prefix added are equivalent to the same instructions without VEX prefix with the following differences:

Instructions that use the whole 256-bit YMM register should not be mixed with non-VEX instructions that leave the upper half of the register unchanged, for reasons of efficiency. [6] [7]

The VEX prefix is not supported in real mode and virtual-8086 mode (all instructions with the VEX prefix will cause #UD in these modes).

History

See also

References

  1. Kelly, John Harry (May 2020). "AVX -> SSE transition penalties, VEX encoding, and why they matter".
  2. Intel Corporation (January 2009). "Intel Advanced Vector Extensions Programming Reference".
  3. Intel® Xeon Phi™ Coprocessor Instruction Set Architecture Reference Manual (PDF). Sep 7, 2012. p. 73. 327364-001. Archived (PDF) from the original on Aug 4, 2021.
  4. Intel ® Architecture Instruction Set Extensions and Future Features (PDF). Sep 2023. p. 103. 314933-050. Archived (PDF) from the original on Dec 12, 2023.
  5. Intel, Software Developers Manual, order no. 325462-081, sep 2023, vol 2, section 2.7.11.3, p. 588. Archived on Dec 6, 2023
  6. Intel, Avoiding AVX-SSE Transition Penalties, 2011. Archived on 26 Oct 2023.
  7. Stack Overflow, Why is this SSE code 6 times slower without VZEROUPPER on Skylake?, December 2016. Archived on 6 Jul 2023.
  8. "128-Bit SSE5 Instruction Set". AMD Developer Central. Retrieved 2009-06-02.
  9. Hruska, Joel (November 14, 2008). "AMD Fusion now pushed back to 2011". Ars Technica.
  10. "Intel Software Network". Intel. Archived from the original on 2008-04-07. Retrieved 2008-04-05.
  11. "AMD and Intel incompatible - What to do?". AMD Developer Forums. Retrieved 2012-08-10.[ permanent dead link ]
  12. "AMD64 Architecture Programmer's Manual Volume 4: 128-Bit and 256-Bit Media Instructions" (PDF). AMD. December 22, 2010.
  13. "Striking a balance". Dave Christie, AMD Developer blogs. Archived from the original on 2013-11-09. Retrieved 2012-08-10.