x86 integer instructions

Main article: x86 assembly language

Below is the full 8086/8088 instruction set of Intel (81 instructions total).² These instructions are also available in 32-bit mode, in which they operate on 32-bit registers (eax, ebx, etc.) and values instead of their 16-bit (ax, bx, etc.) counterparts. The updated instruction set is grouped according to architecture (i186, i286, i386, i486, i586/i686) and is referred to as (32-bit) x86 and (64-bit) x86-64 (also known as AMD64).

Original 8086/8088 instructions

This is the original instruction set. In the 'Notes' column, r means register, m means memory address and imm means immediate (i.e. a value).

Added in specific processors

Added with 80186/80188

Added with 80286

The new instructions added in 80286 add support for x86 protected mode. Some but not all of the instructions are available in real mode as well.

Added with 80386

The 80386 added support for 32-bit operation to the x86 instruction set. This was done by widening the general-purpose registers to 32 bits and introducing the concepts of OperandSize and AddressSize – most instruction forms that would previously take 16-bit data arguments were given the ability to take 32-bit arguments by setting their OperandSize to 32 bits, and instructions that could take 16-bit address arguments were given the ability to take 32-bit address arguments by setting their AddressSize to 32 bits. (Instruction forms that work on 8-bit data continue to be 8-bit regardless of OperandSize. Using a data size of 16 bits will cause only the bottom 16 bits of the 32-bit general-purpose registers to be modified – the top 16 bits are left unchanged.)

The default OperandSize and AddressSize to use for each instruction is given by the D bit of the segment descriptor of the current code segment - D=0 makes both 16-bit, D=1 makes both 32-bit. Additionally, they can be overridden on a per-instruction basis with two new instruction prefixes that were introduced in the 80386:

• 66h: OperandSize override. Will change OperandSize from 16-bit to 32-bit if CS.D=0, or from 32-bit to 16-bit if CS.D=1.
• 67h: AddressSize override. Will change AddressSize from 16-bit to 32-bit if CS.D=0, or from 32-bit to 16-bit if CS.D=1.

The 80386 also introduced the two new segment registers FS and GS as well as the x86 control, debug and test registers.

The new instructions introduced in the 80386 can broadly be subdivided into two classes:

• Pre-existing opcodes that needed new mnemonics for their 32-bit OperandSize variants (e.g. CWDE, LODSD)
• New opcodes that introduced new functionality (e.g. SHLD, SETcc)

For instruction forms where the operand size can be inferred from the instruction's arguments (e.g. ADD EAX,EBX can be inferred to have a 32-bit OperandSize due to its use of EAX as an argument), new instruction mnemonics are not needed and not provided.

Added with 80486

Added in P5/P6-class processors

Integer/system instructions that were not present in the basic 80486 instruction set, but were added in various x86 processors prior to the introduction of SSE. (Discontinued instructions are not included.)

Added as instruction set extensions

Added with x86-64

These instructions can only be encoded in 64 bit mode. They fall in four groups:

• original instructions that reuse existing opcodes for a different purpose (MOVSXD replacing ARPL)
• original instructions with new opcodes (SWAPGS)
• existing instructions extended to a 64 bit address size (JRCXZ)
• existing instructions extended to a 64 bit operand size (remaining instructions)

Most instructions with a 64 bit operand size encode this using a REX.W prefix; in the absence of the REX.W prefix, the corresponding instruction with 32 bit operand size is encoded. This mechanism also applies to most other instructions with 32 bit operand size. These are not listed here as they do not gain a new mnemonic in Intel syntax when used with a 64 bit operand size.

Bit manipulation extensions

Main article: X86 Bit manipulation instruction set

Bit manipulation instructions. For all of the VEX-encoded instructions defined by BMI1 and BMI2, the operand size may be 32 or 64 bits, controlled by the VEX.W bit – none of these instructions are available in 16-bit variants. The VEX-encoded instructions are not available in Real Mode and Virtual-8086 mode - other than that, the bit manipulation instructions are available in all operating modes on supported CPUs.

Added with Intel TSX

Main article: Transactional Synchronization Extensions

Added with Intel CET

Intel CET (Control-Flow Enforcement Technology) adds two distinct features to help protect against security exploits such as return-oriented programming: a shadow stack (CET_SS), and indirect branch tracking (CET_IBT).

Added with XSAVE

The XSAVE instruction set extensions are designed to save/restore CPU extended state (typically for the purpose of context switching) in a manner that can be extended to cover new instruction set extensions without the OS context-switching code needing to understand the specifics of the new extensions. This is done by defining a series of state-components, each with a size and offset within a given save area, and each corresponding to a subset of the state needed for one CPU extension or another. The EAX=0Dh CPUID leaf is used to provide information about which state-components the CPU supports and what their sizes/offsets are, so that the OS can reserve the proper amount of space and set the associated enable-bits.

Added with other cross-vendor extensions

Added with other Intel-specific extensions

Added with other AMD-specific extensions

x87 floating-point instructions

The x87 coprocessor, if present, provides support for floating-point arithmetic. The coprocessor provides eight data registers, each holding one 80-bit floating-point value (1 sign bit, 15 exponent bits, 64 mantissa bits) – these registers are organized as a stack, with the top-of-stack register referred to as "st" or "st(0)", and the other registers referred to as st(1), st(2), ...st(7). It additionally provides a number of control and status registers, including "PC" (precision control, to control whether floating-point operations should be rounded to 24, 53 or 64 mantissa bits) and "RC" (rounding control, to pick rounding-mode: round-to-zero, round-to-positive-infinity, round-to-negative-infinity, round-to-nearest-even) and a 4-bit condition code register "CC", whose four bits are individually referred to as C0, C1, C2 and C3). Not all of the arithmetic instructions provided by x87 obey PC and RC.

Original 8087 instructions

x87 instructions added in later processors

SIMD instructions

Main article: x86 SIMD instruction listings

Cryptographic instructions

Main article: List of x86 cryptographic instructions

Virtualization instructions

Main article: List of x86 virtualization instructions

Other instructions

See also: List of discontinued x86 instructions

x86 also includes discontinued instruction sets which are no longer supported by Intel and AMD, and undocumented instructions which execute but are not officially documented.

Undocumented x86 instructions

The x86 CPUs contain undocumented instructions which are implemented on the chips but not listed in some official documents. They can be found in various sources across the Internet, such as Ralf Brown's Interrupt List and at sandpile.org

Some of these instructions are widely available across many/most x86 CPUs, while others are specific to a narrow range of CPUs.

Undocumented instructions that are widely available across many x86 CPUs include

Undocumented instructions that appear only in a limited subset of x86 CPUs include

Undocumented x87 instructions

See also

• CLMUL
• RDRAND
• Advanced Vector Extensions 2
• AVX-512
• x86 Bit manipulation instruction set
• CPUID
• List of discontinued x86 instructions

• Intel Corporation (April 2022). "Intel 64 and IA-32 Architectures Software Developer's Manual, Combined Volumes: 1, 2A, 2B, 2C, 2D, 3A, 3B, 3C, 3D and 4". Intel. Retrieved 21 June 2022.

External links

• Free IA-32 and x86-64 documentation, provided by Intel
• AMD64 Architecture Programmer's Manual, Volumes 1-5, provided by AMD
• x86 Opcode and Instruction Reference
• x86 and amd64 instruction reference
• Instruction tables: Lists of instruction latencies, throughputs and micro-operation breakdowns for Intel, AMD and VIA CPUs
• Netwide Assembler Instruction List (from Netwide Assembler)

References

1. "Re: Intel Processor Identification and the CPUID Instruction". Retrieved 2013-04-21. http://www.intel.com/content/www/us/en/processors/processor-identification-cpuid-instruction-note.html?wapkw=processor-identification-cpuid-instruction ↩

2. "Intel 80x86 Instruction Set Summary" (PDF). eecs.wsu.edu. https://eecs.wsu.edu/~ee314/handouts/x86ref.pdf ↩

3. "Intel x85 JUMP quick reference". Retrieved 2025-04-01.. http://unixwiz.net/techtips/x86-jumps.html ↩

4. The descriptors used by the LGDT, LIDT, SGDT and SIDT instructions consist of a 2-part data structure. The first part is a 16-bit value, specifying table size in bytes minus 1. The second part is a 32-bit value (64-bit value in 64-bit mode), specifying the linear start address of the table.For LGDT and LIDT with a 16-bit operand size, the address is ANDed with 00FFFFFFh. On Intel (but not AMD) CPUs, the SGDT and SIDT instructions with a 16-bit operand size is – as of Intel SDM revision 079 – documented to write a descriptor to memory with the last byte being set to 0. However, observed behavior is that bits 31:24 of the descriptor table address are written instead.[4] ↩

5. The LGDT, LIDT, LLDT and LTR instructions are serializing on Pentium and later processors. /wiki/Pentium_(original) ↩

6. The descriptors used by the LGDT, LIDT, SGDT and SIDT instructions consist of a 2-part data structure. The first part is a 16-bit value, specifying table size in bytes minus 1. The second part is a 32-bit value (64-bit value in 64-bit mode), specifying the linear start address of the table.For LGDT and LIDT with a 16-bit operand size, the address is ANDed with 00FFFFFFh. On Intel (but not AMD) CPUs, the SGDT and SIDT instructions with a 16-bit operand size is – as of Intel SDM revision 079 – documented to write a descriptor to memory with the last byte being set to 0. However, observed behavior is that bits 31:24 of the descriptor table address are written instead.[4] ↩

7. The LGDT, LIDT, LLDT and LTR instructions are serializing on Pentium and later processors. /wiki/Pentium_(original) ↩

8. The LMSW instruction is serializing on Intel processors from Pentium onwards, but not on AMD processors. /wiki/Pentium_(original) ↩

9. On 80386 and later, the "Machine Status Word" is the same as the CR0 control register – however, the LMSW instruction can only modify the bottom 4 bits of this register and cannot clear bit 0. The inability to clear bit 0 means that LMSW can be used to enter but not leave x86 Protected Mode.On 80286, it is not possible to leave Protected Mode at all (neither with LMSW nor with LOADALL[5]) without a CPU reset – on 80386 and later, it is possible to leave Protected Mode, but this requires the use of the 80386-and-later MOV to CR0 instruction. /wiki/Control_register#CR0 ↩

10. The LGDT, LIDT, LLDT and LTR instructions are serializing on Pentium and later processors. /wiki/Pentium_(original) ↩

11. The LGDT, LIDT, LLDT and LTR instructions are serializing on Pentium and later processors. /wiki/Pentium_(original) ↩

12. The descriptors used by the LGDT, LIDT, SGDT and SIDT instructions consist of a 2-part data structure. The first part is a 16-bit value, specifying table size in bytes minus 1. The second part is a 32-bit value (64-bit value in 64-bit mode), specifying the linear start address of the table.For LGDT and LIDT with a 16-bit operand size, the address is ANDed with 00FFFFFFh. On Intel (but not AMD) CPUs, the SGDT and SIDT instructions with a 16-bit operand size is – as of Intel SDM revision 079 – documented to write a descriptor to memory with the last byte being set to 0. However, observed behavior is that bits 31:24 of the descriptor table address are written instead.[4] ↩

13. If CR4.UMIP=1 is set, then the SGDT, SIDT, SLDT, SMSW and STR instructions can only run in Ring 0.These instructions were unprivileged on all x86 CPUs from 80286 onwards until the introduction of UMIP in 2017.[6] This has been a significant security problem for software-based virtualization, since it enables these instructions to be used by a VM guest to detect that it is running inside a VM.[7] /wiki/Control_register#CR4 ↩

14. The descriptors used by the LGDT, LIDT, SGDT and SIDT instructions consist of a 2-part data structure. The first part is a 16-bit value, specifying table size in bytes minus 1. The second part is a 32-bit value (64-bit value in 64-bit mode), specifying the linear start address of the table.For LGDT and LIDT with a 16-bit operand size, the address is ANDed with 00FFFFFFh. On Intel (but not AMD) CPUs, the SGDT and SIDT instructions with a 16-bit operand size is – as of Intel SDM revision 079 – documented to write a descriptor to memory with the last byte being set to 0. However, observed behavior is that bits 31:24 of the descriptor table address are written instead.[4] ↩

15. The SMSW, SLDT and STR instructions always use an operand size of 16 bits when used with a memory argument. With a register argument on 80386 or later processors, wider destination operand sizes are available and behave as follows: SMSW: Stores full CR0 in x86-64 long mode, undefined otherwise. SLDT: Zero-extends 16-bit argument on Pentium Pro and later processors, undefined on earlier processors. STR: Zero-extends 16-bit argument. /wiki/Control_register#CR0 ↩

16. The SMSW, SLDT and STR instructions always use an operand size of 16 bits when used with a memory argument. With a register argument on 80386 or later processors, wider destination operand sizes are available and behave as follows: SMSW: Stores full CR0 in x86-64 long mode, undefined otherwise. SLDT: Zero-extends 16-bit argument on Pentium Pro and later processors, undefined on earlier processors. STR: Zero-extends 16-bit argument. /wiki/Control_register#CR0 ↩

17. The SMSW, SLDT and STR instructions always use an operand size of 16 bits when used with a memory argument. With a register argument on 80386 or later processors, wider destination operand sizes are available and behave as follows: SMSW: Stores full CR0 in x86-64 long mode, undefined otherwise. SLDT: Zero-extends 16-bit argument on Pentium Pro and later processors, undefined on earlier processors. STR: Zero-extends 16-bit argument. /wiki/Control_register#CR0 ↩

18. In 64-bit long mode, the ARPL instruction is not available – the 63 /r opcode has been reassigned to the 64-bit-mode-only MOVSXD instruction. /wiki/Long_mode ↩

19. The ARPL instruction causes #UD in Real mode and Virtual 8086 Mode – Windows 95 and OS/2 2.x are known to make extensive use of this #UD to use the 63 opcode as a one-byte breakpoint to transition from Virtual 8086 Mode to kernel mode.[8][9] /wiki/Real_mode ↩

20. Bits 19:16 of this mask are documented as "undefined" on Intel CPUs.[10] On AMD CPUs, the mask is documented as 0x00FFFF00. ↩

21. For the LAR and LSL instructions, if the specified segment descriptor could not be loaded, then the instruction's destination register is left unmodified. ↩

22. For the LAR and LSL instructions, if the specified segment descriptor could not be loaded, then the instruction's destination register is left unmodified. ↩

23. On some Intel CPU/microcode combinations from 2019 onwards, the VERW instruction also flushes microarchitectural data buffers. This enables it to be used as part of workarounds for Microarchitectural Data Sampling security vulnerabilities.[11][12] Some of the microarchitectural buffer-flushing functions that have been added to VERW may require the instruction to be executed with a memory operand.[13] /wiki/Microarchitectural_Data_Sampling ↩

24. Undocumented, 80286 only.[5][14][15] (A different variant of LOADALL with a different opcode and memory layout exists on 80386.) ↩

25. Undocumented, 80286 only.[5][14][15] (A different variant of LOADALL with a different opcode and memory layout exists on 80386.) ↩

26. For the 32-bit string instructions, the ±± notation is used to indicate that the indicated register is post-decremented by 4 if EFLAGS.DF=1 and post-incremented by 4 otherwise.For the operands where the DS segment is indicated, the DS segment can be overridden by a segment-override prefix – where the ES segment is indicated, the segment is always ES and cannot be overridden.The choice of whether to use the 16-bit SI/DI registers or the 32-bit ESI/EDI registers as the address registers to use is made by AddressSize, overridable with the 67 prefix. ↩

27. The 32-bit string instructions accept repeat-prefixes in the same way as older 8/16-bit string instructions.For LODSD, STOSD, MOVSD, INSD and OUTSD, the REP prefix (F3) will repeat the instruction the number of times specified in rCX (CX or ECX, decided by AddressSize), decrementing rCX for each iteration (with rCX=0 resulting in no-op and proceeding to the next instruction).For CMPSD and SCASD, the REPE (F3) and REPNE (F2) prefixes are available, which will repeat the instruction, decrementing rCX for each iteration, but only as long as the flag condition (ZF=1 for REPE, ZF=0 for REPNE) holds true AND rCX ≠ 0. ↩

28. For the INSB/W/D instructions, the memory access rights for the ES:[rDI] memory address might not be checked until after the port access has been performed – if this check fails (e.g. page fault or other memory exception), then the data item read from the port is lost. As such, it is not recommended to use this instruction to access an I/O port that performs any kind of side effect upon read. ↩

29. I/O port access is only allowed when CPL≤IOPL or the I/O port permission bitmap bits for the port to access are all set to 0. /wiki/Protection_ring#Privilege_level ↩

30. The CWDE instruction differs from the older CWD instruction in that CWD would sign-extend the 16-bit value in AX into a 32-bit value in the DX:AX register pair. ↩

31. For the E3 opcode (JCXZ/JECXZ), the choice of whether the instruction will use CX or ECX for its comparison (and consequently which mnemonic to use) is based on the AddressSize, not OperandSize. (OperandSize instead controls whether the jump destination should be truncated to 16 bits or not).This also applies to the loop instructions LOOP,LOOPE,LOOPNE (opcodes E0,E1,E2), however, unlike JCXZ/JECXZ, these instructions have not been given new mnemonics for their ECX-using variants. ↩

32. For PUSHA(D), the value of SP/ESP pushed onto the stack is the value it had just before the PUSHA(D) instruction started executing. ↩

33. For POPA/POPAD, the stack item corresponding to SP/ESP is popped off the stack (performing a memory read), but not placed into SP/ESP. ↩

34. The PUSHFD and POPFD instructions will cause a #GP exception if executed in virtual 8086 mode if IOPL is not 3.The PUSHF, POPF, IRET and IRETD instructions will cause a #GP exception if executed in Virtual-8086 mode if IOPL is not 3 and VME is not enabled. /wiki/Virtual_8086_mode ↩

35. If IRETD is used to return from kernel mode to user mode (which will entail a CPL change) and the user-mode stack segment indicated by SS is a 16-bit segment, then the IRETD instruction will only restore the low 16 bits of the stack pointer (ESP/RSP), with the remaining bits keeping whatever value they had in kernel code before the IRETD. This has necessitated complex workarounds on both Linux ("ESPFIX")[16] and Windows.[17] This issue also affects the later 64-bit IRETQ instruction. /wiki/X86_memory_segmentation ↩

36. For the BT, BTS, BTR and BTC instructions: If the first argument to the instruction is a register operand and/or the second argument is an immediate, then the bit-index in the second argument is taken modulo operand size (16/32/64, in effect using only the bottom 4, 5 or 6 bits of the index.) If the first argument is a memory operand and the second argument is a register operand, then the bit-index in the second argument is used in full – it is interpreted as a signed bit-index that is used to offset the memory address to use for the bit test. ↩

37. For the BT, BTS, BTR and BTC instructions: If the first argument to the instruction is a register operand and/or the second argument is an immediate, then the bit-index in the second argument is taken modulo operand size (16/32/64, in effect using only the bottom 4, 5 or 6 bits of the index.) If the first argument is a memory operand and the second argument is a register operand, then the bit-index in the second argument is used in full – it is interpreted as a signed bit-index that is used to offset the memory address to use for the bit test. ↩

38. The BTS, BTC and BTR instructions accept the LOCK (F0) prefix when used with a memory argument – this results in the instruction executing atomically. ↩

39. For the BT, BTS, BTR and BTC instructions: If the first argument to the instruction is a register operand and/or the second argument is an immediate, then the bit-index in the second argument is taken modulo operand size (16/32/64, in effect using only the bottom 4, 5 or 6 bits of the index.) If the first argument is a memory operand and the second argument is a register operand, then the bit-index in the second argument is used in full – it is interpreted as a signed bit-index that is used to offset the memory address to use for the bit test. ↩

40. The BTS, BTC and BTR instructions accept the LOCK (F0) prefix when used with a memory argument – this results in the instruction executing atomically. ↩

41. For the BT, BTS, BTR and BTC instructions: If the first argument to the instruction is a register operand and/or the second argument is an immediate, then the bit-index in the second argument is taken modulo operand size (16/32/64, in effect using only the bottom 4, 5 or 6 bits of the index.) If the first argument is a memory operand and the second argument is a register operand, then the bit-index in the second argument is used in full – it is interpreted as a signed bit-index that is used to offset the memory address to use for the bit test. ↩

42. The BTS, BTC and BTR instructions accept the LOCK (F0) prefix when used with a memory argument – this results in the instruction executing atomically. ↩

43. If the F3 prefix is used with the 0F BC /r opcode, then the instruction will execute as TZCNT on systems that support the BMI1 extension. TZCNT differs from BSF in that TZCNT but not BSR is defined to return operand size if the source operand is zero – for other source operand values, they produce the same result (except for flags). ↩

44. BSF and BSR set the EFLAGS.ZF flag to 1 if the source argument was all-0s and 0 otherwise.If the source argument was all-0s, then the destination register is documented as being left unchanged on AMD processors, but set to an undefined value on Intel processors. ↩

45. If the F3 prefix is used with the 0F BD /r opcode, then the instruction will execute as LZCNT on systems that support the ABM or LZCNT extensions. LZCNT produces a different result from BSR for most input values. ↩

46. BSF and BSR set the EFLAGS.ZF flag to 1 if the source argument was all-0s and 0 otherwise.If the source argument was all-0s, then the destination register is documented as being left unchanged on AMD processors, but set to an undefined value on Intel processors. ↩

47. For SHLD and SHRD, the shift-amount is masked – the bottom 5 bits are used for 16/32-bit operand size and 6 bits for 64-bit operand size.SHLD and SHRD with 16-bit arguments and a shift-amount greater than 16 produce undefined results. (Actual results differ between different Intel CPUs, with at least three different behaviors known.[18]) ↩

48. For SHLD and SHRD, the shift-amount is masked – the bottom 5 bits are used for 16/32-bit operand size and 6 bits for 64-bit operand size.SHLD and SHRD with 16-bit arguments and a shift-amount greater than 16 produce undefined results. (Actual results differ between different Intel CPUs, with at least three different behaviors known.[18]) ↩

49. The condition codes supported for the SETcc and Jcc near instructions (opcodes 0F 9x /0 and 0F 8x respectively, with the x nibble specifying the condition) are: xccCondition (EFLAGS)0OOF=1: "Overflow"1NOOF=0: "Not Overflow"2C,B,NAECF=1: "Carry", "Below", "Not Above or Equal"3NC,NB,AECF=0: "Not Carry", "Not Below", "Above or Equal"4Z,EZF=1: "Zero", "Equal"5NZ,NEZF=0: "Not Zero", "Not Equal"6NA,BE(CF=1 or ZF=1): "Not Above", "Below or Equal"7A,NBE(CF=0 and ZF=0): "Above", "Not Below or Equal"8SSF=1: "Sign"9NSSF=0: "Not Sign"AP,PEPF=1: "Parity", "Parity Even"BNP,POPF=0: "Not Parity", "Parity Odd"CL,NGESF≠OF: "Less", "Not Greater Or Equal"DNL,GESF=OF: "Not Less", "Greater Or Equal"ELE,NG(ZF=1 or SF≠OF): "Less or Equal", "Not Greater"FNLE,G(ZF=0 and SF=OF): "Not Less or Equal", "Greater" /wiki/FLAGS_register ↩

50. For SETcc, while the opcode is commonly specified as /0 – implying that bits 5:3 of the instruction's ModR/M byte should be 000 – modern x86 processors (Pentium and later) ignore bits 5:3 and will execute the instruction as SETcc regardless of the contents of these bits. /wiki/ModR/M ↩

51. The condition codes supported for the SETcc and Jcc near instructions (opcodes 0F 9x /0 and 0F 8x respectively, with the x nibble specifying the condition) are: xccCondition (EFLAGS)0OOF=1: "Overflow"1NOOF=0: "Not Overflow"2C,B,NAECF=1: "Carry", "Below", "Not Above or Equal"3NC,NB,AECF=0: "Not Carry", "Not Below", "Above or Equal"4Z,EZF=1: "Zero", "Equal"5NZ,NEZF=0: "Not Zero", "Not Equal"6NA,BE(CF=1 or ZF=1): "Not Above", "Below or Equal"7A,NBE(CF=0 and ZF=0): "Above", "Not Below or Equal"8SSF=1: "Sign"9NSSF=0: "Not Sign"AP,PEPF=1: "Parity", "Parity Even"BNP,POPF=0: "Not Parity", "Parity Odd"CL,NGESF≠OF: "Less", "Not Greater Or Equal"DNL,GESF=OF: "Not Less", "Greater Or Equal"ELE,NG(ZF=1 or SF≠OF): "Less or Equal", "Not Greater"FNLE,G(ZF=0 and SF=OF): "Not Less or Equal", "Greater" /wiki/FLAGS_register ↩

52. For LFS, LGS and LSS, the size of the offset part of the far pointer is given by operand size – the size of the segment part is always 16 bits. In 64-bit mode, using the REX.W prefix with these instructions will cause them to load a far pointer with a 64-bit offset on Intel but not AMD processors. /wiki/Far_pointer ↩

53. For MOV to/from the CRx, DRx and TRx registers, the reg part of the ModR/M byte is used to indicate CRx/DRx/TRx register and r/m part the general-register. Uniquely for the MOV CRx/DRx/TRx opcodes, the top two bits of the ModR/M byte is ignored – these opcodes are decoded and executed as if the top two bits of the ModR/M byte are 11b. /wiki/ModR/M ↩

54. For moves to/from the CRx and DRx registers, the operand size is always 64 bits in 64-bit mode and 32 bits otherwise. ↩

55. For MOV to/from the CRx, DRx and TRx registers, the reg part of the ModR/M byte is used to indicate CRx/DRx/TRx register and r/m part the general-register. Uniquely for the MOV CRx/DRx/TRx opcodes, the top two bits of the ModR/M byte is ignored – these opcodes are decoded and executed as if the top two bits of the ModR/M byte are 11b. /wiki/ModR/M ↩

56. For moves to/from the CRx and DRx registers, the operand size is always 64 bits in 64-bit mode and 32 bits otherwise. ↩

57. On processors that support global pages (Pentium and later), global page table entries will not be flushed by a MOV to CR3 − instead, these entries can be flushed by toggling the CR4.PGE bit.On processors that support PCIDs, writing to CR3 while PCIDs are enabled will only flush TLB entries belonging to the PCID specified in bits 11:0 of the value written to CR3 (this flush can be suppressed by setting bit 63 of the written value to 1). Flushing pages belonging to other PCIDs can instead be done by toggling the CR4.PGE bit, clearing the CR4.PCIDE bit, or using the INVPCID instruction. /wiki/Process-context_identifier ↩

58. On processors prior to Pentium, moves to CR0 would not serialize the instruction stream – in part for this reason, it is usually required to perform a far jump[19] immediately after a MOV to CR0 if such a MOV is used to enable/disable protected mode and/or memory paging.MOV to CR2 is architecturally listed as serializing, but has been reported to be non-serializing on at least some Intel Core-i7 processors.[20]MOV to CR8 (introduced with x86-64) is serializing on AMD but not Intel processors. /wiki/Pentium_(original) ↩

59. For MOV to/from the CRx, DRx and TRx registers, the reg part of the ModR/M byte is used to indicate CRx/DRx/TRx register and r/m part the general-register. Uniquely for the MOV CRx/DRx/TRx opcodes, the top two bits of the ModR/M byte is ignored – these opcodes are decoded and executed as if the top two bits of the ModR/M byte are 11b. /wiki/ModR/M ↩

60. For moves to/from the CRx and DRx registers, the operand size is always 64 bits in 64-bit mode and 32 bits otherwise. ↩

61. For MOV to/from the CRx, DRx and TRx registers, the reg part of the ModR/M byte is used to indicate CRx/DRx/TRx register and r/m part the general-register. Uniquely for the MOV CRx/DRx/TRx opcodes, the top two bits of the ModR/M byte is ignored – these opcodes are decoded and executed as if the top two bits of the ModR/M byte are 11b. /wiki/ModR/M ↩

62. For moves to/from the CRx and DRx registers, the operand size is always 64 bits in 64-bit mode and 32 bits otherwise. ↩

63. For MOV to/from the CRx, DRx and TRx registers, the reg part of the ModR/M byte is used to indicate CRx/DRx/TRx register and r/m part the general-register. Uniquely for the MOV CRx/DRx/TRx opcodes, the top two bits of the ModR/M byte is ignored – these opcodes are decoded and executed as if the top two bits of the ModR/M byte are 11b. /wiki/ModR/M ↩

64. The MOV TRx instructions were discontinued from Pentium onwards. ↩

65. For MOV to/from the CRx, DRx and TRx registers, the reg part of the ModR/M byte is used to indicate CRx/DRx/TRx register and r/m part the general-register. Uniquely for the MOV CRx/DRx/TRx opcodes, the top two bits of the ModR/M byte is ignored – these opcodes are decoded and executed as if the top two bits of the ModR/M byte are 11b. /wiki/ModR/M ↩

66. The MOV TRx instructions were discontinued from Pentium onwards. ↩

67. The INT1/ICEBP (F1) instruction is present on all known Intel x86 processors from the 80386 onwards,[21] but only fully documented for Intel processors from the May 2018 release of the Intel SDM (rev 067) onwards.[22] Before this release, mention of the instruction in Intel material was sporadic, e.g. AP-526 rev 001.[23]For AMD processors, the instruction has been documented since 2002.[24] ↩

68. The operation of the F1(ICEBP) opcode differs from the operation of the regular software interrupt opcode CD 01 in several ways:In protected mode, CD 01 will check CPL against the interrupt descriptor's DPL field as an access-rights check, while F1 will not.In virtual-8086 mode, CD 01 will also check CPL against IOPL as an access-rights check, while F1 will not.In virtual-8086 mode with VME enabled, interrupt redirection is supported for CD 01 but not F1. ↩

69. The UMOV instruction is present on 386 and 486 processors only.[21] ↩

70. The XBTS and IBTS instructions were discontinued with the B1 stepping of 80386. They have been used by software mainly for detection of the buggy[25] B0 stepping of the 80386. Microsoft Windows (v2.01 and later) will attempt to run the XBTS instruction as part of its CPU detection if CPUID is not present, and will refuse to boot if XBTS is found to be working.[26] ↩

71. For XBTS and IBTS, the r/m argument represents the data to extract/insert a bitfield from/to, the reg argument the bitfield to be inserted/extracted, AX/EAX a bit-offset and CL a bitfield length.[27] ↩

72. The XBTS and IBTS instructions were discontinued with the B1 stepping of 80386. They have been used by software mainly for detection of the buggy[25] B0 stepping of the 80386. Microsoft Windows (v2.01 and later) will attempt to run the XBTS instruction as part of its CPU detection if CPUID is not present, and will refuse to boot if XBTS is found to be working.[26] ↩

73. For XBTS and IBTS, the r/m argument represents the data to extract/insert a bitfield from/to, the reg argument the bitfield to be inserted/extracted, AX/EAX a bit-offset and CL a bitfield length.[27] ↩

74. Undocumented, 80386 only.[28] ↩

75. Using BSWAP with 16-bit registers is not disallowed per se (it will execute without producing an #UD or other exceptions) but is documented to produce undefined results – it is reported to produce various different results on 486,[29] 586, and Bochs/QEMU.[30] ↩

76. On Intel 80486 stepping A,[31] the CMPXCHG instruction uses a different encoding - 0F A6 /r for 8-bit variant, 0F A7 /r for 16/32-bit variant. The 0F B0/B1 encodings are used on 80486 stepping B and later.[32][33] ↩

77. The CMPXCHG instruction sets EFLAGS in the same way as a CMP instruction that uses the accumulator (AL/AX/EAX/RAX) as its first argument would do. ↩

78. On Intel 80486 stepping A,[31] the CMPXCHG instruction uses a different encoding - 0F A6 /r for 8-bit variant, 0F A7 /r for 16/32-bit variant. The 0F B0/B1 encodings are used on 80486 stepping B and later.[32][33] ↩

79. INVLPG executes as no-operation if the m8 argument is invalid (e.g. unmapped page or non-canonical address).INVLPG can be used to invalidate TLB entries for individual global pages. ↩

80. The INVD and WBINVD instructions will invalidate all cache lines in the CPU's L1 caches. It is implementation-defined whether they will invalidate L2/L3 caches as well.These instructions are serializing – on some processors, they may block interrupts until completion as well. ↩

81. Under Intel VT-x virtualization, the INVD instruction will cause a mandatory #VMEXIT. Also, on processors that support Intel SGX, if the PRM (Processor Reserved Memory) has been set up by using the PRMRRs (PRM range registers), then the INVD instruction is not permitted and will cause a #GP(0) exception.[34] /wiki/Intel_VT-x ↩

82. If the F3 prefix is used with the 0F 09 opcode, then the instruction will execute as WBNOINVD on processors that support the WBNOINVD extension – this will not invalidate the cache. ↩

83. The INVD and WBINVD instructions will invalidate all cache lines in the CPU's L1 caches. It is implementation-defined whether they will invalidate L2/L3 caches as well.These instructions are serializing – on some processors, they may block interrupts until completion as well. ↩

84. In 64-bit mode, the RDMSR, RDTSC and RDPMC instructions will set the top 32 bits of RDX and RAX to zero. ↩

85. Frank van Gilluwe, "The Undocumented PC, second edition", 1997, ISBN 0-201-47950-8, page 55 /wiki/ISBN_(identifier) ↩

86. On Intel and AMD CPUs, the WRMSR instruction is also used to update the CPU microcode. This is done by writing the virtual address of the new microcode to upload to MSR 79h on Intel CPUs and MSR C001_0020h[36] on AMD CPUs. /wiki/Intel_Microcode#Update_facility ↩

87. Writes to the following MSRs are not serializing:[37][38] NumberName48hSPEC_CTRL49hPRED_CMD10BhFLUSH_CMD122hTSX_CTRL6E0hTSC_DEADLINE6E1hPKRS774hHWP_REQUEST(non-serializing only if the FAST_IA32_­HWP_REQUEST bit it set)802h to 83Fh(x2APIC MSRs)1B01hUARCH_MISC_CTLC001_0100hFS_BASE (non-serializing on AMD Zen 4 and later)[39]C001_0101hGS_BASE (Zen 4 and later)C001_0102hKernelGSbase (Zen 4 and later)C001_011BhDoorbell Register (AMD-specific) WRMSR to the x2APIC ICR (Interrupt Command Register; MSR 830h) is commonly used to produce an IPI (Inter-processor interrupt) - on Intel[40] but not AMD[41] CPUs, such an IPI can be reordered before an older memory store. ↩

88. "RSM—Resume from System Management Mode". Archived from the original on 2012-03-12. https://web.archive.org/web/20120312224625/http://www.softeng.rl.ac.uk/st/archive/SoftEng/SESP/html/SoftwareTools/vtune/users_guide/mergedProjects/analyzer_ec/mergedProjects/reference_olh/mergedProjects/instructions/instruct32_hh/vc279.htm ↩

89. Microprocessor Report, System Management Mode Explained (vol 6, no. 8, june 17, 1992). Archived on Jun 29, 2022. http://www.cecs.uci.edu/~papers/mpr/MPR/ARTICLES/060805.PDF ↩

90. Ellis, Simson C., "The 386 SL Microprocessor in Notebook PCs", Intel Corporation, Microcomputer Solutions, March/April 1991, page 20 ↩

91. System Management Mode and the RSM instruction were made available on non-SL variants of the Intel 486 only after the initial release of the Intel Pentium in 1993. /wiki/System_Management_Mode ↩

92. Cyrix 486SLC/e Data Sheet (1992), section 2.6.4 http://www.bitsavers.org/components/cyrix/Cyrix_Cx486SLCe_Data_Sheet_1992.pdf ↩

93. On some older 32-bit processors, executing CPUID with a leaf index (EAX) greater than 0 may leave EBX and ECX unmodified, keeping their old values. For this reason, it is recommended to zero out EBX and ECX before executing CPUID.Processors noted to exhibit this behavior include Cyrix MII[46] and IDT WinChip 2.[47]In 64-bit mode, CPUID will set the top 32 bits of RAX, RBX, RCX and RDX to zero. ↩

94. On some Intel processors starting from Ivy Bridge, there exists MSRs that can be used to restrict CPUID to ring 0. Such MSRs are documented for at least Ivy Bridge[48] and Denverton.[49]The ability to restrict CPUID to ring 0 also exists on AMD processors supporting the "CpuidUserDis" feature (Zen 4 "Raphael" and later).[50] /wiki/Ivy_Bridge_(microarchitecture) ↩

95. CPUID is also available on some Intel and AMD 486 processor variants that were released after the initial release of the Intel Pentium. ↩

96. CPUID is also available on some Intel and AMD 486 processor variants that were released after the initial release of the Intel Pentium. ↩

97. On the Cyrix 5x86 and 6x86 CPUs, CPUID is not enabled by default and must be enabled through a Cyrix configuration register. ↩

98. On NexGen CPUs, CPUID is only supported with some system BIOSes. On some NexGen CPUs that do support CPUID, EFLAGS.ID is not supported but EFLAGS.AC is, complicating CPU detection.[51] ↩

99. Unlike the older CMPXCHG instruction, the CMPXCHG8B instruction does not modify any EFLAGS bits other than ZF. /wiki/FLAGS_register ↩

100. LOCK CMPXCHG8B with a register operand (which is an invalid encoding) will, on some Intel Pentium CPUs, cause a hang rather than the expected #UD exception - this is known as the Pentium F00F bug. /wiki/Pentium_(original) ↩

101. On IDT WinChip, Transmeta Crusoe and Rise mP6 processors, the CMPXCHG8B instruction is always supported, however its CPUID bit may be missing. This is a workaround for a bug in Windows NT.[52] ↩

102. On IDT WinChip, Transmeta Crusoe and Rise mP6 processors, the CMPXCHG8B instruction is always supported, however its CPUID bit may be missing. This is a workaround for a bug in Windows NT.[52] ↩

103. On IDT WinChip, Transmeta Crusoe and Rise mP6 processors, the CMPXCHG8B instruction is always supported, however its CPUID bit may be missing. This is a workaround for a bug in Windows NT.[52] ↩

104. The RDTSC and RDPMC instructions are not ordered with respect to other instructions, and may sample their respective counters before earlier instructions are executed or after later instructions have executed. Invocations of RDPMC (but not RDTSC) may be reordered relative to each other even for reads of the same counter.In order to impose ordering with respect to other instructions, LFENCE or serializing instructions (e.g. CPUID) are needed.[53] ↩

105. In 64-bit mode, the RDMSR, RDTSC and RDPMC instructions will set the top 32 bits of RDX and RAX to zero. ↩

106. Fixed-rate TSC was introduced in two stages: Constant TSCTSC running at a fixed rate as long as the processor core is not in a deep-sleep (C2 or deeper) mode, but not synchronized between CPU cores. Introduced in Intel Prescott, Yonah and Bonnell. Also present in all Transmeta and VIA Nano[54] CPUs. Does not have a CPUID bit.Invariant TSCTSC running at a fixed rate, and remaining synchronized between CPU cores in all P-,C- and T-states (but not necessarily S-states).Present in AMD K10 and later; Intel Nehalem/Saltwell[55] and later; Zhaoxin WuDaoKou[56] and later. Indicated with a CPUID bit (leaf 8000_0007:EDX[8]). /wiki/ACPI#Power_states ↩

107. RDTSC can be run outside Ring 0 only if CR4.TSD=0.On Intel Pentium and AMD K5, RDTSC cannot be run in Virtual-8086 mode.[57] Later processors removed this restriction. /wiki/Control_register#CR4 ↩

108. The RDTSC and RDPMC instructions are not ordered with respect to other instructions, and may sample their respective counters before earlier instructions are executed or after later instructions have executed. Invocations of RDPMC (but not RDTSC) may be reordered relative to each other even for reads of the same counter.In order to impose ordering with respect to other instructions, LFENCE or serializing instructions (e.g. CPUID) are needed.[53] ↩

109. In 64-bit mode, the RDMSR, RDTSC and RDPMC instructions will set the top 32 bits of RDX and RAX to zero. ↩

110. RDPMC can be run outside Ring 0 only if CR4.PCE=1. /wiki/Control_register#CR4 ↩

111. The RDPMC instruction is not present in VIA processors prior to the Nano. ↩

112. The condition codes supported for CMOVcc instruction (opcode 0F 4x /r, with the x nibble specifying the condition) are: xccCondition (EFLAGS)0OOF=1: "Overflow"1NOOF=0: "Not Overflow"2C,B,NAECF=1: "Carry", "Below", "Not Above or Equal"3NC,NB,AECF=0: "Not Carry", "Not Below", "Above or Equal"4Z,EZF=1: "Zero", "Equal"5NZ,NEZF=0: "Not Zero", "Not Equal"6NA,BE(CF=1 or ZF=1): "Not Above", "Below or Equal"7A,NBE(CF=0 and ZF=0): "Above", "Not Below or Equal"8SSF=1: "Sign"9NSSF=0: "Not Sign"AP,PEPF=1: "Parity", "Parity Even"BNP,POPF=0: "Not Parity", "Parity Odd"CL,NGESF≠OF: "Less", "Not Greater Or Equal"DNL,GESF=OF: "Not Less", "Greater Or Equal"ELE,NG(ZF=1 or SF≠OF): "Less or Equal", "Not Greater"FNLE,G(ZF=0 and SF=OF): "Not Less or Equal", "Greater" /wiki/FLAGS_register ↩

113. In 64-bit mode, CMOVcc with a 32-bit operand size will clear the upper 32 bits of the destination register even if the condition is false.For CMOVcc with a memory source operand, the CPU will always read the operand from memory – potentially causing memory exceptions and cache line-fills – even if the condition for the move is not satisfied. (The Intel APX extension defines a set of new EVEX-encoded variants of CMOVcc that will suppress memory exceptions if the condition is false.) /wiki/X86#APX_(Advanced_Performance_Extensions) ↩

114. On pre-Nehemiah VIA C3 variants ("Samuel"/"Ezra"), the reg,reg but not reg,[mem] forms of the CMOVcc instructions have been reported to be present as undocumented instructions.[58] ↩

115. Intel's recommended byte encodings for multi-byte NOPs of lengths 2 to 9 bytes in 32/64-bit mode are (in hex):[59] LengthByte Sequence266 9030F 1F 0040F 1F 40 0050F 1F 44 00 00666 0F 1F 44 00 0070F 1F 80 00 00 00 0080F 1F 84 00 00 00 00 00966 0F 1F 84 00 00 00 00 00 For cases where there is a need to use more than 9 bytes of NOP padding, it is recommended to use multiple NOPs. ↩

116. Unlike other instructions added in Pentium Pro, long NOP does not have a CPUID feature bit. /wiki/Pentium_Pro ↩

117. JookWiki, "nopl", sep 24, 2022 – provides a lengthy account of the history of the long NOP and the issues around it. Archived on oct 28, 2022. https://www.jookia.org/wiki/Nopl ↩

118. 0F 1F /0 as long-NOP was introduced in the Pentium Pro, but remained undocumented until 2006.[61] The whole 0F 18..1F opcode range was NOP in Pentium Pro. However, except for 0F 1F /0, Intel does not guarantee that these opcodes will remain NOP in future processors, and have indeed assigned some of these opcodes to other instructions in at least some processors.[62] ↩

119. Documented for AMD x86-64 since 2002.[63] ↩

120. Debian bug report logs, -686 build uses long noops, that are unsupported by Transmeta Crusoe, immediate crash on boot, see messages 148 and 158 for NOPL on VIA C7. Archived on 1 Aug 2019 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464962#148 ↩

121. While the 0F 0B opcode was officially reserved as an invalid opcode from Pentium onwards, it only got assigned the mnemonic UD2 from Pentium Pro onwards.[65] /wiki/Pentium_Pro ↩

122. GNU Binutils have used the UD2A and UD2B mnemonics for the 0F 0B and 0F B9 opcodes since version 2.7.[66]Neither UD2A nor UD2B originally took any arguments - UD2B was later modified to accept a ModR/M byte, in Binutils version 2.30.[67] /wiki/GNU_Binutils ↩

123. The UD2 (0F 0B) instruction will additionally stop subsequent bytes from being decoded as instructions, even speculatively. For this reason, if an indirect branch instruction is followed by something that is not code, it is recommended to place an UD2 instruction after the indirect branch.[68] ↩

124. The UD0/1/2 opcodes - 0F 0B, 0F B9 and 0F FF - will cause an #UD exception on all x86 processors from the 80186 onwards (except NEC V-series processors), but did not get explicitly reserved for this purpose until P5-class processors. /wiki/Intel_80186 ↩

125. Intel, Pentium® Processor Family Developer's Manual Volume 3, 1995. order no. 241430-004, appendix A, page 943 – reserves the opcodes 0F 0B and 0F B9. https://www.ardent-tool.com/CPU/docs/Intel/Pentium/241430-004.pdf ↩

126. While the 0F B9 opcode was officially reserved as an invalid opcode from Pentium onwards, it only got assigned its mnemonic UD1 much later – AMD APM started listing UD1 in its opcode maps from rev 3.17 onwards,[70] while Intel SDM started listing it from rev 061 onwards.[71] ↩

127. GNU Binutils have used the UD2A and UD2B mnemonics for the 0F 0B and 0F B9 opcodes since version 2.7.[66]Neither UD2A nor UD2B originally took any arguments - UD2B was later modified to accept a ModR/M byte, in Binutils version 2.30.[67] /wiki/GNU_Binutils ↩

128. For both the 0F B9 and 0F FF opcodes, different x86 implementations are known to differ regarding whether the opcodes accept a ModR/M byte.[72][73][74] /wiki/ModR/M ↩

129. For the 0F FF opcode, the OIO mnemonic was introduced by Cyrix,[75] while the UD0 menmonic (without arguments) was introduced by AMD and Intel at the same time as the UD1 mnemonic for 0F B9.[70][71] Later Intel (but not AMD) documentation modified its description of UD0 to add a ModR/M byte and take two arguments.[76] ↩

130. For both the 0F B9 and 0F FF opcodes, different x86 implementations are known to differ regarding whether the opcodes accept a ModR/M byte.[72][73][74] /wiki/ModR/M ↩

131. The UD0/1/2 opcodes - 0F 0B, 0F B9 and 0F FF - will cause an #UD exception on all x86 processors from the 80186 onwards (except NEC V-series processors), but did not get explicitly reserved for this purpose until P5-class processors. /wiki/Intel_80186 ↩

132. Cyrix, 6x86 processor data book, 1996, order no. 94175-01, table 6-20, page 209 – uses the mnemonic OIO ("Official invalid opcode") for the 0F FF opcode. https://ardent-tool.com/CPU/docs/Cyrix/6x86/94175.pdf ↩

133. AMD, AMD-K5 Processor Technical Reference Manual, Nov 1996, order no. 18524C/0, section 3.3.7, page 90 – reserves the 0F FF opcode without assigning it a mnemonic. https://www.ardent-tool.com/CPU/docs/AMD/K5/18524c.pdf ↩

134. On K6, the SYSCALL/SYSRET instructions were available on Model 7 (250nm "Little Foot") and later, not on the earlier Model 6.[78] ↩

135. SYSCALL and SYSRET were made an integral part of x86-64 – as a result, the instructions are available in 64-bit mode on all x86-64 processors from AMD, Intel, VIA and Zhaoxin.Outside 64-bit mode, the instructions are available on AMD processors only. ↩

136. The exact semantics of SYSRET differs slightly between AMD and Intel processors: non-canonical return addresses cause a #GP exception to be thrown in Ring 3 on AMD CPUs but Ring 0 on Intel CPUs. This has been known to cause security issues.[79] ↩

137. For the SYSRET and SYSEXIT instructions under x86-64, it is necessary to add the REX.W prefix for variants that will return to 64-bit user-mode code.Encodings of these instructions without the REX.W prefix are used to return to 32-bit user-mode code. (Neither of these instructions can be used to return to 16-bit user-mode code — for return to 16-bit code, IRET/IRETD/IRETQ should be used.) ↩

138. The SYSRET, SYSENTER and SYSEXIT instructions are unavailable in Real mode. (SYSENTER is, however, available in Virtual 8086 mode.) /wiki/Real_mode ↩

139. The SYSRET, SYSENTER and SYSEXIT instructions are unavailable in Real mode. (SYSENTER is, however, available in Virtual 8086 mode.) /wiki/Real_mode ↩

140. The CPUID flags that indicate support for SYSENTER/SYSEXIT are set on the Pentium Pro, even though the processor does not officially support these instructions.[80]Third party testing indicates that the opcodes are present on the Pentium Pro but too buggy to be usable.[81] ↩

141. AMD, Athlon Processor x86 Code Optimization Guide, publication no. 22007, rev K, feb 2002, appendix F, page 284. Archived on 13 Apr 2017. https://pdf.datasheetcatalog.com/datasheet/AdvancedMicroDevices/mXvyvs.pdf ↩

142. On AMD CPUs, the SYSENTER and SYSEXIT instructions are not available in x86-64 long mode (#UD). /wiki/Long_mode ↩

143. On Transmeta CPUs, the SYSENTER and SYSEXIT instructions are only available with version 4.2 or higher of the Transmeta Code Morphing software.[83] ↩

144. On Nehemiah, SYSENTER and SYSEXIT are available only on stepping 8 and later.[84] ↩

145. For the SYSRET and SYSEXIT instructions under x86-64, it is necessary to add the REX.W prefix for variants that will return to 64-bit user-mode code.Encodings of these instructions without the REX.W prefix are used to return to 32-bit user-mode code. (Neither of these instructions can be used to return to 16-bit user-mode code — for return to 16-bit code, IRET/IRETD/IRETQ should be used.) ↩

146. The SYSRET, SYSENTER and SYSEXIT instructions are unavailable in Real mode. (SYSENTER is, however, available in Virtual 8086 mode.) /wiki/Real_mode ↩

147. The memory operand to CMPXCHG16B must be 16-byte aligned. ↩

148. The CMPXCHG16B instruction was absent from a few of the earliest Intel/AMD x86-64 processors. On Intel processors, the instruction was missing from Xeon "Nocona" stepping D,[85] but added in stepping E.[86] On AMD K8 family processors, it was added in stepping F, at the same time as DDR2 support was introduced.[87]For this reason, CMPXCHG16B has its own CPUID flag, separate from the rest of x86-64. /wiki/List_of_Intel_Xeon_processors_(NetBurst-based)#"Nocona"_(90_nm) ↩

149. Encodings of MOVSXD without REX.W prefix are permitted but discouraged[88] – such encodings behave identically to 16/32-bit MOV (8B /r). ↩

150. On AMD CPUs, the "ABM" extension provides both POPCNT and LZCNT. On Intel CPUs, however, the CPUID bit for "ABM" is only documented to indicate the presence of the LZCNT instruction and is listed as "LZCNT", while POPCNT has its own separate CPUID feature bit.However, all known processors that implement the "ABM"/"LZCNT" extensions also implement POPCNT and set the CPUID feature bit for POPCNT, so the distinction is theoretical only.(The converse is not true – there exist processors that support POPCNT but not ABM, such as Intel Nehalem and VIA Nano 3000.) /wiki/Nehalem_(microarchitecture) ↩

151. The LZCNT instruction will execute as BSR on systems that do not support the LZCNT or ABM extensions. BSR computes the index of the highest set bit in the source operand, producing a different result from LZCNT for most input values. ↩

152. The TZCNT instruction will execute as BSF on systems that do not support the BMI1 extension. BSF produces the same result as TZCNT for all input operand values except zero – for which TZCNT returns input operand size, but BSF produces undefined behavior (leaves destination unmodified on most modern CPUs). ↩

153. For BEXTR, the start position and length are not masked and can take values from 0 to 255. If the selected bits extend beyond the end of the r/m argument (which has the usual 32/64-bit operand size), then the out-of-bounds bits are read out as 0. ↩

154. On AMD processors before Zen 3, the PEXT and PDEP instructions are quite slow[89] and exhibit data-dependent timing due to the use of a microcoded implementation (about 18 to 300 cycles, depending on the number of bits set in the mask argument). As a result, it is often faster to use other instruction sequences on these processors.[90][91] ↩

155. The RDSSPD and RDSSPQ instructions act as NOPs on processors where shadow stacks are disabled or CET is not supported. ↩

156. The RDSSPD and RDSSPQ instructions act as NOPs on processors where shadow stacks are disabled or CET is not supported. ↩

157. ENDBR32 and ENDBR64 act as NOPs on processors that don't support CET_IBT or where IBT is disabled. ↩

158. ENDBR32 and ENDBR64 act as NOPs on processors that don't support CET_IBT or where IBT is disabled. ↩

159. This prefix has the same encoding as the DS: segment override prefix – as of April 2022, Intel documentation does not appear to specify whether this prefix also retains its old segment-override function when used as a no-track prefix, nor does it provide an official mnemonic for this prefix.[92][93] (GNU binutils use "notrack"[94]) ↩

160. Under Intel APX, the XSAVE* and XRSTOR* instructions cannot be encoded with the REX2 prefix. ↩

161. XSAVE was added in steppings E0/R0 of Penryn and is not available in earlier steppings. ↩

162. On some processors (starting with Skylake, Goldmont and Zen 1), executing XGETBV with ECX=1 is permitted – this will not return XCR1 (no such register exists) but instead return XCR0 bitwise-ANDed with the current value of the "XINUSE" state-component bitmap (a bitmap of XSAVE state-components that are not known to be in their initial state).The presence of this functionality of XGETBV is indicated by CPUID.(EAX=0Dh,ECX=1):EAX[bit 2]. /wiki/Skylake_(microarchitecture) ↩

163. The XSETBV instruction will cause a mandatory #VMEXIT if executed under Intel VT-x virtualization. /wiki/Intel_VT-x ↩

164. AMD Athlon processors prior to the Athlon XP did not support full SSE, but did introduce the non-SIMD instructions of SSE as part of "MMX Extensions".[95] These extensions (without full SSE) are also present on Geode GX2 and later Geode processors. /wiki/Athlon ↩

165. All of the PREFETCH* instructions are hint instructions with effects only on performance, not program semantics. Providing an invalid address (e.g. address of an unmapped page or a non-canonical address) will cause the instruction to act as a NOP without any exceptions generated. ↩

166. AMD Athlon processors prior to the Athlon XP did not support full SSE, but did introduce the non-SIMD instructions of SSE as part of "MMX Extensions".[95] These extensions (without full SSE) are also present on Geode GX2 and later Geode processors. /wiki/Athlon ↩

167. AMD Athlon processors prior to the Athlon XP did not support full SSE, but did introduce the non-SIMD instructions of SSE as part of "MMX Extensions".[95] These extensions (without full SSE) are also present on Geode GX2 and later Geode processors. /wiki/Athlon ↩

168. All of the PREFETCH* instructions are hint instructions with effects only on performance, not program semantics. Providing an invalid address (e.g. address of an unmapped page or a non-canonical address) will cause the instruction to act as a NOP without any exceptions generated. ↩

169. All of the PREFETCH* instructions are hint instructions with effects only on performance, not program semantics. Providing an invalid address (e.g. address of an unmapped page or a non-canonical address) will cause the instruction to act as a NOP without any exceptions generated. ↩

170. All of the PREFETCH* instructions are hint instructions with effects only on performance, not program semantics. Providing an invalid address (e.g. address of an unmapped page or a non-canonical address) will cause the instruction to act as a NOP without any exceptions generated. ↩

171. For the SFENCE, LFENCE and MFENCE instructions, the bottom 3 bits of the ModR/M byte are ignored, and any value of x in the range 0..7 will result in a valid instruction. ↩

172. The SFENCE instruction ensures that all memory stores after the SFENCE instruction are made globally observable after all memory stores before the SFENCE. This imposes ordering on stores that can otherwise be reordered, such as non-temporal stores and stores to WC (Write-Combining) memory regions.[96]On Intel CPUs, as well as AMD CPUs from Zen1 onwards (but not older AMD CPUs), SFENCE also acts as a reordering barrier on cache flushes/writebacks performed with the CLFLUSH, CLFLUSHOPT and CLWB instructions. (Older AMD CPUs require MFENCE to order CLFLUSH.)SFENCE is not ordered with respect to LFENCE, and an SFENCE+LFENCE sequence is not sufficient to prevent a load from being reordered past a previous store.[97] To prevent such reordering, it is necessary to execute an MFENCE, LOCK or a serializing instruction. ↩

173. For the SFENCE, LFENCE and MFENCE instructions, the bottom 3 bits of the ModR/M byte are ignored, and any value of x in the range 0..7 will result in a valid instruction. ↩

174. The LFENCE instruction ensures that all memory loads after the LFENCE instruction are made globally observable after all memory loads before the LFENCE.On all Intel CPUs that support SSE2, the LFENCE instruction provides a stronger ordering guarantee:[98] it is dispatch-serializing, meaning that instructions after the LFENCE instruction are allowed to start executing only after all instructions before it have retired (which will ensure that all preceding loads but not necessarily stores have completed). The effect of dispatch-serialization is that LFENCE also acts as a speculation barrier and a reordering barrier for accesses to non-memory resources such as performance counters (accessed through e.g. RDTSC or RDPMC) and x2apic MSRs.On AMD CPUs, LFENCE is not necessarily dispatch-serializing by default – however, on all AMD CPUs that support any form of non-dispatch-serializing LFENCE, it can be made dispatch-serializing by setting bit 1 of MSR C001_1029.[99] ↩

175. For the SFENCE, LFENCE and MFENCE instructions, the bottom 3 bits of the ModR/M byte are ignored, and any value of x in the range 0..7 will result in a valid instruction. ↩

176. The MFENCE instruction ensures that all memory loads, stores and cacheline-flushes after the MFENCE instruction are made globally observable after all memory loads, stores and cacheline-flushes before the MFENCE.On Intel CPUs, MFENCE is not dispatch-serializing, and therefore cannot be used on its own to enforce ordering on accesses to non-memory resources such as performance counters and x2apic MSRs. MFENCE is still ordered with respect to LFENCE, so if there is a need to enforce ordering between memory stores and subsequent non-memory accesses, then such an ordering can be obtained by issuing an MFENCE followed by an LFENCE.[53][100]On AMD CPUs, MFENCE is serializing. ↩

177. The operation of the PAUSE instruction in 64-bit mode is, unlike NOP, unaffected by the presence of the REX.R prefix. Neither NOP nor PAUSE are affected by the other bits of the REX prefix. A few examples of how opcode 90 interacts with various prefixes in 64-bit mode are:90 is NOP41 90 is XCHG R8D,EAX4E 90 is NOP49 90 is XCHG R8,RAXF3 90 is PAUSEF3 41 90 is PAUSEF3 4F 90 is PAUSE ↩

178. The actual length of the pause performed by the PAUSE instruction is implementation-dependent.On systems without SSE2, PAUSE will execute as NOP. ↩

179. Under VT-x or AMD-V virtualization, executing PAUSE many times in a short time interval may cause a #VMEXIT. The number of PAUSE executions and interval length that can trigger #VMEXIT are platform-specific. ↩

180. While the CLFLUSH instruction was introduced together with SSE2, it has its own CPUID flag and may be present on processors not otherwise implementing SSE2 and/or absent from processors that otherwise implement SSE2. (E.g. AMD Geode LX supports CLFLUSH but not SSE2.) /wiki/Geode_(processor) ↩

181. While the MONITOR and MWAIT instructions were introduced at the same time as SSE3, they have their own CPUID flag that needs to be checked separately from the SSE3 CPUID flag (e.g. Athlon 64 X2 and VIA C7 supported SSE3 but not MONITOR.) /wiki/Athlon_64_X2 ↩

182. For the MONITOR and MWAIT instructions, older Intel documentation[101] lists instruction mnemonics with explicit operands (MONITOR EAX,ECX,EDX and MWAIT EAX,ECX), while newer documentation omits these operands. Assemblers/disassemblers may support one or both of these variants.[102] ↩

183. For MONITOR, the DS: segment can be overridden with a segment prefix.The memory area that will be monitored will be not just the single byte specified by DS:rAX, but a linear memory region containing the byte – the size and alignment of this memory region is implementation-dependent and can be queried through CPUID.The memory location to monitor should have memory type WB (write-back cacheable), or else monitoring may fail. ↩

184. As of April 2024, no extensions or hints have been defined for the MONITOR instruction. As such, the instruction requires ECX=0 and ignores EDX. ↩

185. On some processors, such as Intel Xeon Phi x200[103] and AMD K10[104] and later, there exist documented MSRs that can be used to enable MONITOR and MWAIT to run in Ring 3. /wiki/Xeon_Phi ↩

186. For the MONITOR and MWAIT instructions, older Intel documentation[101] lists instruction mnemonics with explicit operands (MONITOR EAX,ECX,EDX and MWAIT EAX,ECX), while newer documentation omits these operands. Assemblers/disassemblers may support one or both of these variants.[102] ↩

187. The wait performed by MWAITmay be ended by system events other than a memory write (e.g. cacheline evictions, interrupts) – the exact set of events that can cause the wait to end is implementation-specific.Regardless of whether the wait was ended by a memory write or some other event, monitoring will have ended and it will be necessary to set up monitoring again with MONITOR before using MWAIT to wait for memory writes again. ↩

188. The extension flags available for MWAIT in the ECX register are: BitsMWAIT Extension0Treat interrupts as break events, even when masked (EFLAGS.IF=0). (Available on all non-NetBurst implementations of MWAIT.)1Timed MWAIT: end the wait when the TSC reaches or exceeds the value in EDX:EBX. (Undocumented, reportedly present in Intel Skylake and later Intel processors)[105]2Monitorless MWAIT[106]31:3Not used, must be set to zero. /wiki/FLAGS_register ↩

189. The hint flags available for MWAIT in the EAX register are: BitsMWAIT Hint3:0Sub-state within a C-state (see bits 7:4) (Intel processors only)7:4Target CPU power C-state during wait, minus 1. (E.g. 0000b for C1, 0001b for C2, 1111b for C0)31:8Not used. The C-states are processor-specific power states, which do not necessarily correspond 1:1 to ACPI C-states. /wiki/ACPI#Processor_states ↩

190. For the GETSEC instruction, the REX.W prefix enables 64-bit addresses for the EXITAC leaf function only - REX prefixes are otherwise permitted but ignored for the instruction. ↩

191. The leaf functions defined for GETSEC (selected by EAX) are: EAXFunction0 (CAPABILITIES)Report SMX capabilities2 (ENTERACCES)Enter execution of authenticated code module3 (EXITAC)Exit execution of authenticated code module4 (SENTER)Enter measured environment5 (SEXIT)Exit measured environment6 (PARAMETERS)Report SMX parameters7 (SMCTRL)SMX Mode Control8 (WAKEUP)Wake up sleeping processors in measured environment Any unsupported value in EAX causes an #UD exception. ↩

192. For GETSEC, most leaf functions are restricted to Ring 0, but the CAPABILITIES (EAX=0) and PARAMETERS (EAX=6) leaf functions are available in Ring 3. ↩

193. Guru3D, VIA Zhaoxin x86 4 and 8-core SoC processors launch, Jan 22, 2018 https://www.guru3d.com/news-story/via-zhaoxin-x86-4-and-8-core-processors-launched.html ↩

194. The "core ID" value read by RDTSCP and RDPID is actually the TSC_AUX MSR (MSR C000_0103h). Whether this value actually corresponds to a processor ID is a matter of operating system convention. ↩

195. Unlike the older RDTSC instruction, RDTSCP will delay the TSC read until all previous instructions have retired, guaranteeing ordering with respect to preceding memory loads (but not stores). RDTSCP is not ordered with respect to subsequent instructions, though. ↩

196. RDTSCP can be run outside Ring 0 only if CR4.TSD=0. /wiki/Control_register#CR4 ↩

197. Support for RDTSCP was added in stepping F of the AMD K8, and is not available on earlier steppings. ↩

198. While the POPCNT instruction was introduced at the same time as SSE4.2, it is not considered to be a part of SSE4.2, but instead a separate extension with its own CPUID flag.On AMD processors, it is considered to be a part of the ABM extension, but still has its own CPUID flag. ↩

199. For the MOVBE instruction, encodings that use both the 66h prefix and the REX.W prefix will cause #UD on some processors (e.g. Haswell[108]) and should therefore be avoided. ↩

200. For the MOVBE instruction, encodings that use both the 66h prefix and the REX.W prefix will cause #UD on some processors (e.g. Haswell[108]) and should therefore be avoided. ↩

201. The invalidation types defined for INVPCID (selected by register argument) are: ValueFunction0Invalidate TLB entries matching PCID and virtual memory address in descriptor, excluding global entries1Invalidate TLB entries matching PCID in descriptor, excluding global entries2Invalidate all TLB entries, including global entries3Invalidate all TLB entries, excluding global entries Any unsupported value in the register argument causes a #GP exception. ↩

202. Unlike the older INVLPG instruction, INVPCID will cause a #GP exception if the provided memory address is non-canonical. This discrepancy has been known to cause security issues.[109] ↩

203. The PREFETCH and PREFETCHW instructions are mandatory parts of the 3DNow! instruction set extension, but are also available as a standalone extension on systems that do not support 3DNow! /wiki/3DNow! ↩

204. All of the PREFETCH* instructions are hint instructions with effects only on performance, not program semantics. Providing an invalid address (e.g. address of an unmapped page or a non-canonical address) will cause the instruction to act as a NOP without any exceptions generated. ↩

205. The opcodes for PREFETCH and PREFETCHW (0F 0D /r) execute as NOPs on Intel CPUs from Cedar Mill (65nm Pentium 4) onwards, with PREFETCHW gaining prefetch functionality from Broadwell onwards. /wiki/Pentium_4 ↩

206. The PREFETCH (0F 0D /0) instruction is a 3DNow! instruction, present on all processors with 3DNow! but not necessarily on processors with the PREFETCHW extension.On AMD CPUs with PREFETCHW, opcode 0F 0D /0 as well as opcodes 0F 0D /2../7 are all documented to be performing prefetch.On Intel processors with PREFETCHW, these opcodes are documented as performing reserved-NOPs[110] (except 0F 0D /2 being PREFETCHWT1 m8 on Xeon Phi only) – third party testing[111] indicates that some or all of these opcodes may be performing prefetch on at least some Intel Core CPUs. /wiki/3DNow! ↩

207. All of the PREFETCH* instructions are hint instructions with effects only on performance, not program semantics. Providing an invalid address (e.g. address of an unmapped page or a non-canonical address) will cause the instruction to act as a NOP without any exceptions generated. ↩

208. The SMAP, PKU and RDPID instruction set extensions are supported on stepping 2[112] and later of Zhaoxin LuJiaZui, but not on earlier steppings. ↩

209. All of the PREFETCH* instructions are hint instructions with effects only on performance, not program semantics. Providing an invalid address (e.g. address of an unmapped page or a non-canonical address) will cause the instruction to act as a NOP without any exceptions generated. ↩

210. The SMAP, PKU and RDPID instruction set extensions are supported on stepping 2[112] and later of Zhaoxin LuJiaZui, but not on earlier steppings. ↩

211. The "core ID" value read by RDTSCP and RDPID is actually the TSC_AUX MSR (MSR C000_0103h). Whether this value actually corresponds to a processor ID is a matter of operating system convention. ↩

212. Unlike the older RDTSCP instruction which can also be used to read the processor ID, user-mode RDPID is not disabled by CR4.TSD=1. /wiki/Control_register#CR4 ↩

213. The SMAP, PKU and RDPID instruction set extensions are supported on stepping 2[112] and later of Zhaoxin LuJiaZui, but not on earlier steppings. ↩

214. For MOVDIR64, the destination address given by ES:reg must be 64-byte aligned.The operand size for the register argument is given by the address size, which may be overridden by the 67h prefix.The 64-byte memory source argument does not need to be 64-byte aligned, and is not guaranteed to be read atomically. ↩

215. The WBNOINVD instruction will execute as WBINVD if run on a system that doesn't support the WBNOINVD extension.WBINVD differs from WBNOINVD in that WBINVD will invalidate all cache lines after writeback. ↩

216. In initial implementations, the PREFETCHIT0 and PREFETCHIT1 instructions will perform code prefetch only when using the RIP-relative addressing mode and act as NOPs otherwise.The PREFETCHI instructions are hint instructions only - if an attempt is made to prefetch an invalid address, the instructions will act as NOPs with no exceptions generated. On processors that support Long-NOP but do not support the PREFETCHI instructions, these instructions will always act as NOPs. ↩

217. In initial implementations, the PREFETCHIT0 and PREFETCHIT1 instructions will perform code prefetch only when using the RIP-relative addressing mode and act as NOPs otherwise.The PREFETCHI instructions are hint instructions only - if an attempt is made to prefetch an invalid address, the instructions will act as NOPs with no exceptions generated. On processors that support Long-NOP but do not support the PREFETCHI instructions, these instructions will always act as NOPs. ↩

218. The branch hint mnemonics HWNT and HST are listed in early Willamette documentation only[113] - later Intel documentation lists the branch hint prefixes without assigning them a mnemonic.[114]Intel XED uses the mnemonics hint-taken and hint-not-taken for these branch hints.[115] /wiki/Pentium_4#Willamette ↩

219. The 2E and 3E prefixes are interpreted as branch hints only when used with the Jcc conditional branch instructions (opcodes 70..7F and 0F 80..8F) - when used with other opcodes, they may take other meanings (e.g. for instructions with memory operands outside 64-bit mode, they will work as segment-override prefixes CS: and DS:, respectively). On processors that don't support branch hints, these prefixes are accepted but ignored when used with Jcc. ↩

220. Branch hints are supported on all NetBurst (Pentium 4 family) processors - but not supported on any other known processor prior to their re-introduction in "Redwood Cove" CPUs, starting with "Meteor Lake" in 2023. /wiki/NetBurst ↩

221. Intel, Intel 64 and IA-32 Architectures Optimization Reference Manual: Volume 1, order no. 248966-050US, April 2024, chapter 2.1.1.1, page 46. Archived on 25 Jan 2025. https://cdrdv2-public.intel.com/814198/248966-Optimization-Reference-Manual-V1-050.pdf ↩

222. The branch hint mnemonics HWNT and HST are listed in early Willamette documentation only[113] - later Intel documentation lists the branch hint prefixes without assigning them a mnemonic.[114]Intel XED uses the mnemonics hint-taken and hint-not-taken for these branch hints.[115] /wiki/Pentium_4#Willamette ↩

223. The 2E and 3E prefixes are interpreted as branch hints only when used with the Jcc conditional branch instructions (opcodes 70..7F and 0F 80..8F) - when used with other opcodes, they may take other meanings (e.g. for instructions with memory operands outside 64-bit mode, they will work as segment-override prefixes CS: and DS:, respectively). On processors that don't support branch hints, these prefixes are accepted but ignored when used with Jcc. ↩

224. The leaf functions defined for ENCLS (selected by EAX) are: EAXFunction0 (ECREATE)Create an enclave1 (EADD)Add a page2 (EINIT)Initialize an enclave3 (EREMOVE)Remove a page from EPC (Enclave Page Cache)4 (EDBGRD)Read data by debugger5 (EDBGWR)Write data by debugger6 (EEXTEND)Extend EPC page measurement7 (ELDB)Load an EPC page as blocked8 (ELDU)Load an EPC page as unblocked9 (EBLOCK)Block an EPC pageA (EPA)Add version arrayB (EWB)Writeback/invalidate EPC pageC (ETRACK)Activate EBLOCK checksAdded with SGX2D (EAUG)Add page to initialized enclaveE (EMODPTR)Restrict permissions of EPC pageF (EMODT)Change type of EPC pageAdded with OVERSUB[117]10 (ERDINFO)Read EPC page type/status info11 (ETRACKC)Activate EBLOCK checks12 (ELDBC)Load EPC page as blocked with enhanced error reporting13 (ELDUC)Load EPC page as unblocked with enhanced error reportingOther18 (EUPDATESVN)Update SVN (Security Version Number) after live microcode update[118] Any unsupported value in EAX causes a #GP exception. ↩

225. SGX is deprecated on desktop/laptop processors from 11th generation (Rocket Lake, Tiger Lake) onwards,[119] but continues to be available on Xeon-branded server parts. /wiki/Rocket_Lake ↩

226. Intel, Which Platforms Support Intel® Software Guard Extensions (Intel® SGX) SGX2? Archived on 5 May 2022. https://www.intel.com/content/www/us/en/support/articles/000058764/software/intel-security-products.html ↩

227. Intel, Intel® Software Guard Extensions (Intel® SGX) Architecture for Oversubscription of Secure Memory in a Virtualized Environment, 25 Jun 2017. Archived on 31 Mar 2023. https://cdrdv2-public.intel.com/671471/sgx-oversubscription.pdf ↩

228. The leaf functions defined for ENCLU (selected by EAX) are: EAXFunction0 (EREPORT)Create a cryptographic report1 (EGETKEY)Create a cryptographic key2 (EENTER)Enter an Enclave3 (ERESUME)Re-enter an Enclave4 (EEXIT)Exit an EnclaveAdded with SGX25 (EACCEPT)Accept changes to EPC page6 (EMODPE)Extend EPC page permissions7 (EACCEPTCOPY)Initialize pending pageAdded with TDX[121]8 (EVERIFYREPORT2)Verify a cryptographic report of a trust domainAdded with AEX-Notify[122]9 (EDECCSSA)Decrement TCS.CSSAAdded with 256BITSGX[123]A (EREPORT2)Create a cryptographic report that contains SHA384 measurementsB (EGETKEY256)Create a 256-bit cryptographic key Any unsupported value in EAX causes a #GP exception.The EENTER and ERESUME functions cannot be executed inside an SGX enclave – the other functions can only be executed inside an enclave. ↩

229. ENCLU can only be executed in ring 3, not rings 0/1/2. ↩

230. The leaf functions defined for ENCLV (selected by EAX) are: EAXFunctionAdded with OVERSUB[117]0 (EDECVIRTCHILD)Decrement VIRTCHILDCNT in SECS1 (EINCVIRTCHILD)Increment VIRTCHILDCNT in SECS2 (ESETCONTEXT)Set ENCLAVECONTEXT field in SECS Any unsupported value in EAX causes a #GP exception.The ENCLV instruction is only present on systems that support the EPC Oversubscription Extensions to SGX ("OVERSUB"). ↩

231. ENCLV is only available if Intel VMX operation is enabled with VMXON, and will produce #UD otherwise. ↩

232. For PTWRITE, the write to the Processor Trace Packet will only happen if a set of enable-bits (the "TriggerEn", "ContextEn", "FilterEn" bits of the RTIT_STATUS MSR and the "PTWEn" bit of the RTIT_CTL MSR) are all set to 1.The PTWRITE instruction is indicated in the SDM to cause an #UD exception if the 66h instruction prefix is used, regardless of other prefixes. ↩

233. The leaf functions defined for PCONFIG (selected by EAX) are: EAXFunction0MKTME_KEY_PROGRAM:Program key and encryption mode to use with an TME-MK Key ID.Added with TSE1TSE_KEY_PROGRAM:Direct key programming for TSE.2TSE_KEY_PROGRAM_WRAPPED:Wrapped key programming for TSE. Any unsupported value in EAX causes a #GP(0) exception. ↩

234. For CLDEMOTE, the cache level that it will demote a cache line to is implementation-dependent.Since the instruction is considered a hint, it will execute as a NOP without any exceptions if the provided memory address is invalid or not in the L1 cache. It may also execute as a NOP under other implementation-dependent circumstances as well.On systems that do not support the CLDEMOTE extension, it executes as a NOP. ↩

235. Intel documentation lists Tremont and Alder Lake as the processors in which CLDEMOTE was introduced. However, as of May 2022, no Tremont or Alder Lake models have been observed to have the CPUID feature bit for CLDEMOTE set, while several of them have the CPUID bit cleared.[124]As of April 2023, the CPUID feature bit for CLDEMOTE has been observed to be set for Sapphire Rapids.[125] ↩

236. For UMONITOR, the operand size of the address argument is given by the address size, which may be overridden by the 67h prefix. The default segment used is DS:, which can be overridden with a segment prefix. ↩

237. For the UMWAIT and TPAUSE instructions, the operating system can use the IA32_UMWAIT_CONTROL MSR to limit the maximum amount of time that a single UMWAIT/TPAUSE invocation is permitted to wait. The UMWAIT and TPAUSE instructions will set RFLAGS.CF to 1 if they reached the IA32_UMWAIT_CONTROL-defined time limit and 0 otherwise. ↩

238. TPAUSE and UMWAIT can be run outside Ring 0 only if CR4.TSD=0. /wiki/Control_register#CR4 ↩

239. For the UMWAIT and TPAUSE instructions, the operating system can use the IA32_UMWAIT_CONTROL MSR to limit the maximum amount of time that a single UMWAIT/TPAUSE invocation is permitted to wait. The UMWAIT and TPAUSE instructions will set RFLAGS.CF to 1 if they reached the IA32_UMWAIT_CONTROL-defined time limit and 0 otherwise. ↩

240. For the register argument to the UMWAIT and TPAUSE instructions, the following flag bits are supported: BitsUsage0Preferred optimization state.0 = C0.2 (slower wakeup, improves performance of other SMT threads on same core)1 = C0.1 (faster wakeup)31:1(Reserved) ↩

241. While serialization can be performed with older instructions such as e.g. CPUID and IRET, these instructions perform additional functions, causing side-effects and reduced performance when stand-alone instruction serialization is needed. (CPUID additionally has the issue that it causes a mandatory #VMEXIT when executed under virtualization, which causes a very large overhead.) The SERIALIZE instruction performs serialization only, avoiding these added costs. ↩

242. A bitmap of CPU history components that can be reset through HRESET is provided by CPUID.(EAX=20h,ECX=0):EBX.As of July 2023, the following bits are defined: BitUsage0Intel Thread Director history31:1(Reserved) ↩

243. The register argument to SENDUIPI is an index to pick an entry from the UITT (User-Interrupt Target Table, a table specified by the new UINTR_TT and UINT_MISC MSRs.) /wiki/Model-specific_register ↩

244. On Sapphire Rapids processors, the UIRET instruction always sets UIF (User Interrupt Flag) to 1. On Sierra Forest and later processors, UIRET will set UIF to the value of bit 1 of the value popped off the stack for RFLAGS - this functionality is indicated by CPUID.(EAX=7,ECX=1):EDX[17]. /wiki/Sapphire_Rapids_(microprocessor) ↩

245. Intel, Intel Data Streaming Accelerator Architecture Specification, order no. 341204-004, Sep 2022, pages 13 and 23. Archived on 20 Jul 2023. https://cdrdv2-public.intel.com/671116/341204-intel-data-streaming-accelerator-spec.pdf ↩

246. For ENQCMD and EMQCMDS, the operand-size of the register argument is given by the current address-size, which can be overridden with the 67h prefix. ↩

247. For the RDMSRLIST and WRMSRLIST instructions, the addresses specified in the RSI and RDI registers must be 8-byte aligned. ↩

248. For the RDMSRLIST and WRMSRLIST instructions, the addresses specified in the RSI and RDI registers must be 8-byte aligned. ↩

249. The condition codes supported for the CMPccXADD instructions (opcode VEX.128.66.0F38 Ex /r with the x nibble specifying the condition) are: xccCondition (EFLAGS)0OOF=1: "Overflow"1NOOF=0: "Not Overflow"2BCF=1: "Below"3NBCF=0: "Not Below"4ZZF=1: "Zero"5NZZF=0: "Not Zero"6BE(CF=1 or ZF=1): "Below or Equal"7NBE(CF=0 and ZF=0): "Not Below or Equal"8SSF=1: "Sign"9NSSF=0: "Not Sign"APPF=1: "Parity"BNPPF=0: "Not Parity"CLSF≠OF: "Less"DNLSF=OF: "Not Less"ELE(ZF=1 or SF≠OF): "Less or Equal"FNLE(ZF=0 and SF=OF): "Not Less or Equal" /wiki/FLAGS_register ↩

250. Even though the CMPccXADD instructions perform a locked memory operation, they do not require or accept the LOCK (F0h) prefix - attempting to use this prefix results in #UD. ↩

251. The standard way to access the CR8 register is to use an encoding that makes use of the REX.R prefix, e.g. 44 0F 20 07 (MOV RDI,CR8). However, the REX.R prefix is only available in 64-bit mode.The AltMovCr8 extension adds an additional method to access CR8, using the F0 (LOCK) prefix instead of REX.R – this provides access to CR8 outside 64-bit mode. ↩

252. Like other variants of MOV to/from the CRx registers, the AltMovCr8 encodings ignore the top 2 bits of the instruction's ModR/M byte, and always execute as if these two bits are set to 11b.The AltMovCr8 encodings are available in 64-bit mode. However, combining the LOCK prefix with the REX.R prefix is not permitted and will cause an #UD exception. ↩

253. Support for AltMovCR8 was added in stepping F of the AMD K8, and is not available on earlier steppings. ↩

254. Like other variants of MOV to/from the CRx registers, the AltMovCr8 encodings ignore the top 2 bits of the instruction's ModR/M byte, and always execute as if these two bits are set to 11b.The AltMovCr8 encodings are available in 64-bit mode. However, combining the LOCK prefix with the REX.R prefix is not permitted and will cause an #UD exception. ↩

255. For CLZERO, the address size and 67h prefix control whether to use AX, EAX or RAX as address. The default segment DS: can be overridden by a segment-override prefix. The provided address does not need to be aligned – hardware will align it as necessary.The CLZERO instruction is intended for recovery from otherwise-fatal Machine Check errors. It is non-cacheable, cannot be used to allocate a cache line without a memory access, and should not be used for fast memory clears.[127] ↩

256. The register numbering used by RDPRU does not necessarily match that of RDMSR/WRMSR.The registers supported by RDPRU as of December 2022 are: ECXRegister0MPERF (MSR 0E7h: Maximum Performance Frequency Clock Count)1APERF (MSR 0E8h: Actual Performance Frequency Clock Count) Unsupported values in ECX return 0. ↩

257. If CR4.TSD=1, then the RDPRU instruction can only run in ring 0. /wiki/Control_register#CR4 ↩

258. x87 coprocessors (other than the 8087) handle exceptions in a fairly unusual way. When an x87 instruction generates an unmasked arithmetic exception, it will still complete without causing a CPU fault – instead of causing a fault, it will record within the coprocessor information needed to handle the exception (instruction pointer, opcode, data pointer if the instruction had a memory operand) and set FPU status-word flag to indicate that a pending exception is present. This pending exception will then cause a CPU fault when the next x87, MMX or WAIT instruction is executed.The exception to this is x87's "Non-Waiting" instructions, which will execute without causing such a fault even if a pending exception is present (with some caveats, see application note AP-578[128]). These instructions are mostly control instructions that can inspect and/or modify the pending-exception state of the x87 FPU. ↩

259. For each non-waiting x87 instruction whose mnemonic begins with FN, there exists a pseudo-instruction that has the same mnemonic except without the N. These pseudo-instructions consist of a WAIT instruction (opcode 9B) followed by the corresponding non-waiting x87 instruction. For example:FNCLEX is an instruction with the opcode DB E2. The corresponding pseudo-instruction FCLEX is then encoded as 9B DB E2.FNSAVE ES:[BX+6] is an instruction with the opcode 26 DD 77 06. The corresponding pseudo-instruction FSAVE ES:[BX+6] is then encoded as 9B 26 DD 77 06These pseudo-instructions are commonly recognized by x86 assemblers and disassemblers and treated as single instructions, even though all x86 CPUs with x87 coprocessors execute them as a sequence of two instructions. ↩

260. F(N)STSW with the AX register as a destination is available on 80287 and later, but not on the 8087. ↩

261. On 80387 and later x87 FPUs, FLDENV, F(N)STENV, FRSTOR and F(N)SAVE exist in 16-bit and 32-bit variants. The 16-bit variants will load/store a 14-byte floating-point environment data structure to/from memory – the 32-bit variants will load/store a 28-byte data structure instead. (F(N)SAVE/FRSTOR will additionally load/store an additional 80 bytes of FPU data register content after the FPU environment, for a total of 94 or 108 bytes). The choice between the 16-bit and 32-bit variants is based on the CS.D bit and the presence of the 66h instruction prefix. On 8087 and 80287, only the 16-bit variants are available.64-bit variants of these instructions do not exist – using REX.W under x86-64 will cause the 32-bit variants to be used. Since these can only load/store the bottom 32 bits of FIP and FDP, it is recommended to use FXSAVE64/FXRSTOR64 instead if 64-bit operation is desired. ↩

262. On 80387 and later x87 FPUs, FLDENV, F(N)STENV, FRSTOR and F(N)SAVE exist in 16-bit and 32-bit variants. The 16-bit variants will load/store a 14-byte floating-point environment data structure to/from memory – the 32-bit variants will load/store a 28-byte data structure instead. (F(N)SAVE/FRSTOR will additionally load/store an additional 80 bytes of FPU data register content after the FPU environment, for a total of 94 or 108 bytes). The choice between the 16-bit and 32-bit variants is based on the CS.D bit and the presence of the 66h instruction prefix. On 8087 and 80287, only the 16-bit variants are available.64-bit variants of these instructions do not exist – using REX.W under x86-64 will cause the 32-bit variants to be used. Since these can only load/store the bottom 32 bits of FIP and FDP, it is recommended to use FXSAVE64/FXRSTOR64 instead if 64-bit operation is desired. ↩

263. On 80387 and later x87 FPUs, FLDENV, F(N)STENV, FRSTOR and F(N)SAVE exist in 16-bit and 32-bit variants. The 16-bit variants will load/store a 14-byte floating-point environment data structure to/from memory – the 32-bit variants will load/store a 28-byte data structure instead. (F(N)SAVE/FRSTOR will additionally load/store an additional 80 bytes of FPU data register content after the FPU environment, for a total of 94 or 108 bytes). The choice between the 16-bit and 32-bit variants is based on the CS.D bit and the presence of the 66h instruction prefix. On 8087 and 80287, only the 16-bit variants are available.64-bit variants of these instructions do not exist – using REX.W under x86-64 will cause the 32-bit variants to be used. Since these can only load/store the bottom 32 bits of FIP and FDP, it is recommended to use FXSAVE64/FXRSTOR64 instead if 64-bit operation is desired. ↩

264. On 80387 and later x87 FPUs, FLDENV, F(N)STENV, FRSTOR and F(N)SAVE exist in 16-bit and 32-bit variants. The 16-bit variants will load/store a 14-byte floating-point environment data structure to/from memory – the 32-bit variants will load/store a 28-byte data structure instead. (F(N)SAVE/FRSTOR will additionally load/store an additional 80 bytes of FPU data register content after the FPU environment, for a total of 94 or 108 bytes). The choice between the 16-bit and 32-bit variants is based on the CS.D bit and the presence of the 66h instruction prefix. On 8087 and 80287, only the 16-bit variants are available.64-bit variants of these instructions do not exist – using REX.W under x86-64 will cause the 32-bit variants to be used. Since these can only load/store the bottom 32 bits of FIP and FDP, it is recommended to use FXSAVE64/FXRSTOR64 instead if 64-bit operation is desired. ↩

265. In the case of an x87 instruction producing an unmasked FPU exception, the 8087 FPU will signal an IRQ some indeterminate time after the instruction was issued. This may not always be possible to handle,[129] and so the FPU offers the F(N)DISI and F(N)ENI instructions to set/clear the Interrupt Mask bit (bit 7) of the x87 Control Word,[130] to control the interrupt.Later x87 FPUs, from 80287 onwards, changed the FPU exception mechanism to instead produce a CPU exception on the next x87 instruction. This made the Interrupt Mask bit unnecessary, so it was removed.[131] In later Intel x87 FPUs, the F(N)ENI and F(N)DISI instructions were kept for backwards compatibility, executing as NOPs that do not modify any x87 state. /wiki/Interrupt_Request ↩

266. In the case of an x87 instruction producing an unmasked FPU exception, the 8087 FPU will signal an IRQ some indeterminate time after the instruction was issued. This may not always be possible to handle,[129] and so the FPU offers the F(N)DISI and F(N)ENI instructions to set/clear the Interrupt Mask bit (bit 7) of the x87 Control Word,[130] to control the interrupt.Later x87 FPUs, from 80287 onwards, changed the FPU exception mechanism to instead produce a CPU exception on the next x87 instruction. This made the Interrupt Mask bit unnecessary, so it was removed.[131] In later Intel x87 FPUs, the F(N)ENI and F(N)DISI instructions were kept for backwards compatibility, executing as NOPs that do not modify any x87 state. /wiki/Interrupt_Request ↩

267. FST/FSTP with an 80-bit destination (m80 or st(i)) and an sNaN source value is documented to produce exceptions on AMD but not Intel FPUs. ↩

268. FST/FSTP with an 80-bit destination (m80 or st(i)) and an sNaN source value is documented to produce exceptions on AMD but not Intel FPUs. ↩

269. FST/FSTP with an 80-bit destination (m80 or st(i)) and an sNaN source value is documented to produce exceptions on AMD but not Intel FPUs. ↩

270. FSTP ST(0) is a commonly used idiom for popping a single register off the x87 register stack. ↩

271. Intel x87 alias opcode. Use of this opcode is not recommended.On the Intel 8087 coprocessor, several reserved opcodes would perform operations behaving similarly to existing defined x87 instructions. These opcodes were documented for the 8087[132] and 80287,[133] but then omitted from later manuals until the October 2017 update of the Intel SDM.[134]They are present on all known Intel x87 FPUs but unavailable on some older non-Intel FPUs, such as AMD Geode GX/LX, DM&P Vortex86[135] and NexGen 586PF.[136] ↩

272. Intel x87 alias opcode. Use of this opcode is not recommended.On the Intel 8087 coprocessor, several reserved opcodes would perform operations behaving similarly to existing defined x87 instructions. These opcodes were documented for the 8087[132] and 80287,[133] but then omitted from later manuals until the October 2017 update of the Intel SDM.[134]They are present on all known Intel x87 FPUs but unavailable on some older non-Intel FPUs, such as AMD Geode GX/LX, DM&P Vortex86[135] and NexGen 586PF.[136] ↩

273. On the 8087 and 80287, FBSTP and the load-constant instructions always use the round-to-nearest rounding mode. On the 80387 and later x87 FPUs, these instructions will use the rounding mode specified in the x87 RC register. ↩

274. For the FADDP, FSUBP, FSUBRP, FMULP, FDIVP, FDIVRP, FCOM, FCOMP and FXCH instructions, x86 assemblers/disassemblers may recognize variants of the instructions with no arguments. Such variants are equivalent to variants using st(1) as their first argument. ↩

275. On Intel Pentium and later processors, FXCH is implemented as a register renaming rather than a true data move. This has no semantic effect, but enables zero-cycle-latency operation. It also allows the instruction to break data dependencies for the x87 top-of-stack value, improving attainable performance for code optimized for these processors. ↩

276. Intel x87 alias opcode. Use of this opcode is not recommended.On the Intel 8087 coprocessor, several reserved opcodes would perform operations behaving similarly to existing defined x87 instructions. These opcodes were documented for the 8087[132] and 80287,[133] but then omitted from later manuals until the October 2017 update of the Intel SDM.[134]They are present on all known Intel x87 FPUs but unavailable on some older non-Intel FPUs, such as AMD Geode GX/LX, DM&P Vortex86[135] and NexGen 586PF.[136] ↩

277. Intel x87 alias opcode. Use of this opcode is not recommended.On the Intel 8087 coprocessor, several reserved opcodes would perform operations behaving similarly to existing defined x87 instructions. These opcodes were documented for the 8087[132] and 80287,[133] but then omitted from later manuals until the October 2017 update of the Intel SDM.[134]They are present on all known Intel x87 FPUs but unavailable on some older non-Intel FPUs, such as AMD Geode GX/LX, DM&P Vortex86[135] and NexGen 586PF.[136] ↩

278. The result of executing the FBLD instruction on non-BCD data is undefined. ↩

279. On the 8087 and 80287, FBSTP and the load-constant instructions always use the round-to-nearest rounding mode. On the 80387 and later x87 FPUs, these instructions will use the rounding mode specified in the x87 RC register. ↩

280. On early Intel Pentium processors, floating-point divide was subject to the Pentium FDIV bug. This also affected instructions that perform divide as part of their operations, such as FPREM and FPATAN.[137] /wiki/Pentium_(original) ↩

281. For the FADDP, FSUBP, FSUBRP, FMULP, FDIVP, FDIVRP, FCOM, FCOMP and FXCH instructions, x86 assemblers/disassemblers may recognize variants of the instructions with no arguments. Such variants are equivalent to variants using st(1) as their first argument. ↩

282. Intel x87 alias opcode. Use of this opcode is not recommended.On the Intel 8087 coprocessor, several reserved opcodes would perform operations behaving similarly to existing defined x87 instructions. These opcodes were documented for the 8087[132] and 80287,[133] but then omitted from later manuals until the October 2017 update of the Intel SDM.[134]They are present on all known Intel x87 FPUs but unavailable on some older non-Intel FPUs, such as AMD Geode GX/LX, DM&P Vortex86[135] and NexGen 586PF.[136] ↩

283. For the FADDP, FSUBP, FSUBRP, FMULP, FDIVP, FDIVRP, FCOM, FCOMP and FXCH instructions, x86 assemblers/disassemblers may recognize variants of the instructions with no arguments. Such variants are equivalent to variants using st(1) as their first argument. ↩

284. For the FADDP, FSUBP, FSUBRP, FMULP, FDIVP, FDIVRP, FCOM, FCOMP and FXCH instructions, x86 assemblers/disassemblers may recognize variants of the instructions with no arguments. Such variants are equivalent to variants using st(1) as their first argument. ↩

285. For the FADDP, FSUBP, FSUBRP, FMULP, FDIVP, FDIVRP, FCOM, FCOMP and FXCH instructions, x86 assemblers/disassemblers may recognize variants of the instructions with no arguments. Such variants are equivalent to variants using st(1) as their first argument. ↩

286. For the FADDP, FSUBP, FSUBRP, FMULP, FDIVP, FDIVRP, FCOM, FCOMP and FXCH instructions, x86 assemblers/disassemblers may recognize variants of the instructions with no arguments. Such variants are equivalent to variants using st(1) as their first argument. ↩

287. For the FADDP, FSUBP, FSUBRP, FMULP, FDIVP, FDIVRP, FCOM, FCOMP and FXCH instructions, x86 assemblers/disassemblers may recognize variants of the instructions with no arguments. Such variants are equivalent to variants using st(1) as their first argument. ↩

288. For the FADDP, FSUBP, FSUBRP, FMULP, FDIVP, FDIVRP, FCOM, FCOMP and FXCH instructions, x86 assemblers/disassemblers may recognize variants of the instructions with no arguments. Such variants are equivalent to variants using st(1) as their first argument. ↩

289. For the FADDP, FSUBP, FSUBRP, FMULP, FDIVP, FDIVRP, FCOM, FCOMP and FXCH instructions, x86 assemblers/disassemblers may recognize variants of the instructions with no arguments. Such variants are equivalent to variants using st(1) as their first argument. ↩

290. Intel x87 alias opcode. Use of this opcode is not recommended.On the Intel 8087 coprocessor, several reserved opcodes would perform operations behaving similarly to existing defined x87 instructions. These opcodes were documented for the 8087[132] and 80287,[133] but then omitted from later manuals until the October 2017 update of the Intel SDM.[134]They are present on all known Intel x87 FPUs but unavailable on some older non-Intel FPUs, such as AMD Geode GX/LX, DM&P Vortex86[135] and NexGen 586PF.[136] ↩

291. Intel x87 alias opcode. Use of this opcode is not recommended.On the Intel 8087 coprocessor, several reserved opcodes would perform operations behaving similarly to existing defined x87 instructions. These opcodes were documented for the 8087[132] and 80287,[133] but then omitted from later manuals until the October 2017 update of the Intel SDM.[134]They are present on all known Intel x87 FPUs but unavailable on some older non-Intel FPUs, such as AMD Geode GX/LX, DM&P Vortex86[135] and NexGen 586PF.[136] ↩

292. The FXAM instruction will set C0, C2 and C3 based on value type in st(0) as follows: C3C2C0Classification000Unsupported (unnormal or pseudo-NaN)001NaN010Normal finite number011Infinity100Zero101Empty110Denormal number111Empty (may occur on 8087/80287 only) C1 is set to the sign-bit of st(0), regardless of whether st(0) is Empty or not. /wiki/NaN ↩

293. For FXTRACT, the behavior that results from st(0) being zero or ±∞, differs between 8087 and 80387: If st(0) is ±0, then on 8087/80287, E and M are both set equal to st(0) with no exception reported — on 80387 and later, M is set equal to st(0), E is set to -∞, and a zero-divide exception is raised. If st(0) is ±∞, then on 8087/80287, an invalid-operation exception is raised and both M and E are set to NaN — on 80387 and later, M is set equal to st(0) and E is set to +∞ with no exception reported.[138] ↩

294. For FPREM, if the quotient Q is larger than 2 63 {\displaystyle 2^{63}} , then the remainder calculation may have been done only partially – in this case, the FPREM instruction will need to be run again in order to complete the remainder calculation. This is indicated by the instruction setting C2 to 1.If the instruction did complete the remainder calculation, it will set C2 to 0 and set the three bits {C0,C3,C1} to the bottom three bits of the quotient Q.On 80387 and later, if the instruction didn't complete the remainder calculation, then the computed remainder Q used for argument reduction will have been rounded to a multiple of 8 (or larger power-of-2), so that the bottom 3 bits of the quotient can still be correctly retrieved in a later pass that does complete the remainder calculation. ↩

295. The remainder computation done by the FPREM instruction is always exact with no roundoff errors. ↩

296. For the FSCALE instruction on 8087 and 80287, st(1) is required to be in the range − 2 15 ≤ s t ( 1 ) < 2 15 {\displaystyle -2^{15}\leq st(1)<2^{15}} . Also, its absolute value must be either 0 or at least 1. If these requirements are not satisfied, the result is undefined.These restrictions were removed in the 80387. ↩

297. For FSCALE, rounding is only applied in the case of overflow, underflow or subnormal result. ↩

298. The x87 transcendental instructions do not obey PC or RC, but instead compute full 80-bit results. These results are not necessarily correctly rounded (see Table-maker's dilemma) – they may have an error of up to ±1 ulp on Pentium or later, or up to ±1.5 ulps on earlier x87 coprocessors. /wiki/Table-maker%27s_dilemma ↩

299. For the FYL2X and FYL2XP1 instructions, the maximum error bound of ±1 ulp only holds for st(1)=1.0 – for other values of st(1), the error bound is increased to ±1.35 ulps.FYL2X can produce a #Z (divide-by-zero exception) if st(0)=0 and st(1) is a finite nonzero value. FYL2XP1, however, cannot produce #Z. ↩

300. For FPATAN, the following adjustments are done as compared to just computing a one-argument arctangent of the ratio s t ( 1 ) s t ( 0 ) {\displaystyle {\frac {st(1)}{st(0)}}} :If both st(0) and st(1) are ±∞, then the arctangent is computed as if each of st(0) and st(1) had been replaced with ±1 of the same sign. This produces a result that is an odd multiple of π 4 {\displaystyle {\frac {\pi }{4}}} .If both st(0) and st(1) are ±0, then the arctangent is computed as if st(0) but not st(1) had been replaced with ±1 of the same sign, producing a result of ±0 or ± π {\displaystyle \pm \pi } .If st(0) is negative (has sign bit set), then an addend of ± π {\displaystyle \pm \pi } with the same sign as st(1) is added to the result. ↩

301. For the FYL2X and FYL2XP1 instructions, the maximum error bound of ±1 ulp only holds for st(1)=1.0 – for other values of st(1), the error bound is increased to ±1.35 ulps.FYL2X can produce a #Z (divide-by-zero exception) if st(0)=0 and st(1) is a finite nonzero value. FYL2XP1, however, cannot produce #Z. ↩

302. While FNOP is a no-op in the sense that will leave the x87 FPU register stack unmodified, it may still modify FIP and CC, and it may fault if a pending x87 FPU exception is present. ↩

303. If the top-of-stack register st(0) is Empty, then the FSTPNCE instruction will behave like FINCSTP, incrementing the stack pointer with no data movement and no exceptions reported. ↩

304. Intel x87 alias opcode. Use of this opcode is not recommended.On the Intel 8087 coprocessor, several reserved opcodes would perform operations behaving similarly to existing defined x87 instructions. These opcodes were documented for the 8087[132] and 80287,[133] but then omitted from later manuals until the October 2017 update of the Intel SDM.[134]They are present on all known Intel x87 FPUs but unavailable on some older non-Intel FPUs, such as AMD Geode GX/LX, DM&P Vortex86[135] and NexGen 586PF.[136] ↩

305. Intel x87 alias opcode. Use of this opcode is not recommended.On the Intel 8087 coprocessor, several reserved opcodes would perform operations behaving similarly to existing defined x87 instructions. These opcodes were documented for the 8087[132] and 80287,[133] but then omitted from later manuals until the October 2017 update of the Intel SDM.[134]They are present on all known Intel x87 FPUs but unavailable on some older non-Intel FPUs, such as AMD Geode GX/LX, DM&P Vortex86[135] and NexGen 586PF.[136] ↩

306. The x87 FPU needs to know whether it is operating in Real Mode or Protected Mode because the floating-point environment accessed by the F(N)SAVE, FRSTOR, FLDENV and F(N)STENV instructions has different formats in Real Mode and Protected Mode. On 80287, the F(N)SETPM instruction is required to communicate the real-to-protected mode transition to the FPU. On 80387 and later x87 FPUs, real↔protected mode transitions are handled automatically between the CPU and the FPU without the need for any dedicated instructions – therefore, on these FPUs, FNSETPM executes as a NOP that does not modify any FPU state. /wiki/Real_Mode ↩

307. Not including discontinued instructions specific to particular 80387-compatible FPU models. /wiki/List_of_discontinued_x86_instructions#Instructions_present_in_specific_80387_clones ↩

308. For the FUCOM and FUCOMP instructions, x86 assemblers/disassemblers may recognize variants of the instructions with no arguments. Such variants are equivalent to variants using st(1) as their first argument. ↩

309. For the FUCOM and FUCOMP instructions, x86 assemblers/disassemblers may recognize variants of the instructions with no arguments. Such variants are equivalent to variants using st(1) as their first argument. ↩

310. The 80387 FPREM1 instruction differs from the older FPREM (D9 F8) instruction in that the quotient Q is rounded to integer with round-to-nearest-even rounding rather than the round-to-zero rounding used by FPREM. Like FPREM, FPREM1 always computes an exact result with no roundoff errors. Like FPREM, it may also perform a partial computation if the quotient is too large, in which case it must be run again. ↩

311. Due to the x87 FPU performing argument reduction for sin/cos with only about 68 bits of precision, the value of k used in the calculation of FSIN, FCOS and FSINCOS is not precisely 1.0, but instead given by[139][140][138] k = 2 66 ∗ π ⌊ 2 66 ∗ π ⌋ ≈ 1.0000000000000000000012874 {\displaystyle k{=}{\frac {2^{66}*\pi }{\lfloor 2^{66}*\pi \rfloor }}\approx 1.0000000000000000000012874} This argument reduction inaccuracy also affects the FPTAN instruction. ↩

312. If st(0) is finite and its absolute value is 2 63 {\displaystyle 2^{63}} or greater, then the top-of-stack value st(0) is left unmodified and C2 is set, with no exception raised. This applies to the FSIN, FCOS and FSINCOS instructions, as well as FPTAN on 80387 and later.In this case, the FSINCOS and FPTAN instructions will also abstain from pushing a value onto the x87 register-stack. ↩

313. Due to the x87 FPU performing argument reduction for sin/cos with only about 68 bits of precision, the value of k used in the calculation of FSIN, FCOS and FSINCOS is not precisely 1.0, but instead given by[139][140][138] k = 2 66 ∗ π ⌊ 2 66 ∗ π ⌋ ≈ 1.0000000000000000000012874 {\displaystyle k{=}{\frac {2^{66}*\pi }{\lfloor 2^{66}*\pi \rfloor }}\approx 1.0000000000000000000012874} This argument reduction inaccuracy also affects the FPTAN instruction. ↩

314. Due to the x87 FPU performing argument reduction for sin/cos with only about 68 bits of precision, the value of k used in the calculation of FSIN, FCOS and FSINCOS is not precisely 1.0, but instead given by[139][140][138] k = 2 66 ∗ π ⌊ 2 66 ∗ π ⌋ ≈ 1.0000000000000000000012874 {\displaystyle k{=}{\frac {2^{66}*\pi }{\lfloor 2^{66}*\pi \rfloor }}\approx 1.0000000000000000000012874} This argument reduction inaccuracy also affects the FPTAN instruction. ↩

315. The FCOMI, FCOMIP, FUCOMI and FUCOMIP instructions write their results to the ZF, CF and PF bits of the EFLAGS register. On Intel but not AMD processors, the SF, AF and OF bits of EFLAGS are also zeroed out by these instructions. ↩

316. The FXSAVE and FXRSTOR instructions were added in the "Deschutes" revision of Pentium II, and are not present in earlier "Klamath" revision.They are also present in AMD K7.They are also considered an integral part of SSE and are therefore present in all processors with SSE. ↩

317. The FXSAVE and FXRSTOR instructions will save/restore SSE state only on processors that support SSE. Otherwise, they will only save/restore x87 and MMX state.The x87 section of the state saved/restored by FXSAVE(64)/FXRSTOR(64) has a completely different layout than the data structure of the older F(N)SAVE/FRSTOR instructions, enabling faster save/restore by avoiding misaligned loads and stores.FXSAVE and FXRSTOR require their memory argument to be 16-byte aligned. ↩

318. When floating-point emulation is enabled with CR0.EM=1, FXSAVE(64) and FXRSTOR(64) are considered to be x87 instructions and will accordingly produce an #NM (device-not-available) exception. Other than WAIT, these are the only opcodes outside the D8..DF ESC opcode space that exhibit this behavior.Except on Netburst (Pentium 4 family) CPUs, all opcodes in D8..DF will produce #NM if CR0.EM=1, even for undefined opcodes that would produce #UD otherwise. ↩

319. Unlike the older F(N)SAVE instruction, FXSAVE will not initialize the FPU after saving its state to memory, but instead leave the x87 coprocessor state unmodified. ↩

320. The FXSAVE64/FXRSTOR64 instruction differ from the FXSAVE/FXRSTOR instructions in that: FXSAVE/FXRSTOR will save/restore FIP and FDP as 32-bit items, and will also save/restore FCS and FDS as 16-bit items. FXSAVE64/FXRSTOR64 will save/restore FIP and FDP as 64-bit items while not saving/restoring FCS and FDS. This difference also applies to the later XSAVE/XRSTOR vs XSAVE64/XRSTOR64 instructions.As a result, saving both FCS/FDS and the top 32 bits of 64-bit FIP/FDP cannot be accomplished with 1 instruction, but instead requires running both (F)XSAVE and (F)XSAVE64. This has been known to cause problems, especially for 64-bit hypervisors running 16/32-bit guests.[141][142] ↩

321. The FXSAVE and FXRSTOR instructions will save/restore SSE state only on processors that support SSE. Otherwise, they will only save/restore x87 and MMX state.The x87 section of the state saved/restored by FXSAVE(64)/FXRSTOR(64) has a completely different layout than the data structure of the older F(N)SAVE/FRSTOR instructions, enabling faster save/restore by avoiding misaligned loads and stores.FXSAVE and FXRSTOR require their memory argument to be 16-byte aligned. ↩

322. When floating-point emulation is enabled with CR0.EM=1, FXSAVE(64) and FXRSTOR(64) are considered to be x87 instructions and will accordingly produce an #NM (device-not-available) exception. Other than WAIT, these are the only opcodes outside the D8..DF ESC opcode space that exhibit this behavior.Except on Netburst (Pentium 4 family) CPUs, all opcodes in D8..DF will produce #NM if CR0.EM=1, even for undefined opcodes that would produce #UD otherwise. ↩

323. The FXSAVE64/FXRSTOR64 instruction differ from the FXSAVE/FXRSTOR instructions in that: FXSAVE/FXRSTOR will save/restore FIP and FDP as 32-bit items, and will also save/restore FCS and FDS as 16-bit items. FXSAVE64/FXRSTOR64 will save/restore FIP and FDP as 64-bit items while not saving/restoring FCS and FDS. This difference also applies to the later XSAVE/XRSTOR vs XSAVE64/XRSTOR64 instructions.As a result, saving both FCS/FDS and the top 32 bits of 64-bit FIP/FDP cannot be accomplished with 1 instruction, but instead requires running both (F)XSAVE and (F)XSAVE64. This has been known to cause problems, especially for 64-bit hypervisors running 16/32-bit guests.[141][142] ↩

324. Robert Collins, Undocumented OpCodes: AAM. Archived on 21 Feb 2001 http://www.rcollins.org/secrets/opcodes/AAM.html ↩

325. Retrocomputing StackExchange, 0F1h opcode-prefix on i80286. Archived on 13 Apr 2023. https://retrocomputing.stackexchange.com/questions/12004/0f1h-opcode-prefix-on-i80286 ↩

326. Frank van Gilluwe, "The Undocumented PC – Second Edition", p. 93-95 ↩

327. Michal Necasek, Intel 486 Errata?, 6 Dec 2015. Archived on 29 Nov 2023. http://www.os2museum.com/wp/intel-486-errata/ ↩

328. Robert Hummel, "PC Magazine Programmer's Technical Reference" (ISBN 1-56276-016-5) p.728 /wiki/ISBN_(identifier) ↩

329. Frank van Gilluwe, "The Undocumented PC – Second Edition", p. 93-95 ↩

330. Raúl Gutiérrez Sanz, Undocumented 8086 Opcodes, Part I, 27 Dec 2017. Archived on 29 Nov 2023. http://www.os2museum.com/wp/undocumented-8086-opcodes-part-i/ ↩

331. "Asm, opcode 82h". 24 Dec 1998. Archived from the original on 14 Apr 2023. http://computer-programming-forum.com/46-asm/143edbd28ae1a091.htm ↩

332. "Asm, opcode 82h". 24 Dec 1998. Archived from the original on 14 Apr 2023. http://computer-programming-forum.com/46-asm/143edbd28ae1a091.htm ↩

333. Intel Corporation 2022, p. 3698. - Intel Corporation (April 2022). "Intel 64 and IA-32 Architectures Software Developer's Manual, Combined Volumes: 1, 2A, 2B, 2C, 2D, 3A, 3B, 3C, 3D and 4". Intel. Retrieved 21 June 2022. https://cdrdv2.intel.com/v1/dl/getContent/671200 ↩

334. Intel, The 8086 Family User's Manual, October 1979, opcodes omitted on pages 4-25 and 4-31 http://bitsavers.org/components/intel/8086/9800722-03_The_8086_Family_Users_Manual_Oct79.pdf ↩

335. Retrocomputing StackExchange, Undocumented instructions in x86 CPU prior to 80386?, 4 Jun 2021. Archived on 18 Jul 2023. https://retrocomputing.stackexchange.com/questions/20031/undocumented-instructions-in-x86-cpu-prior-to-80386 ↩

336. Daniel B. Sedory, An Examination of the Standard MBR, 2000. Archived on 6 Oct 2023. https://thestarman.pcministry.com/asm/mbr/STDMBR.htm#REP ↩

337. AMD, Software Optimization Guide for AMD64 Processors (publication 25112, revision 3.06, sep 2005), section 6.2, p.128 https://www.amd.com/system/files/TechDocs/25112.PDF ↩

338. GCC bugzilla, Bug 48227 – "rep ret" generated for -march=core2. Archived on 9 Apr 2023. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48227 ↩

339. Raymond Chen, My, what strange NOPs you have!, 12 Jan 2011. Archived on 20 May 2023. https://devblogs.microsoft.com/oldnewthing/20110112-00/?p=11773 ↩

340. Jeff Parsons, Intel 80386 CPU information (B1 errata section, item #7). Archived on 13 Nov 2023. https://www.pcjs.org/documents/manuals/intel/80386/#b1-errata ↩

341. Intel Community: Multibyte NOP Made Official. Archived on 7 Apr 2022. https://community.intel.com/t5/Software-Archive/Multi-byte-NOP-opcode-made-official/td-p/932580 ↩

342. Intel Software Developers Manual, volume 2B (Jan 2006, order no 235667-018, does not have long NOP) https://kib.kiev.ua/x86docs/Intel/SDMs/253667-018.pdf ↩

343. Intel Software Developers Manual, volume 2B (March 2006, order no 235667-019, has long NOP) https://kib.kiev.ua/x86docs/Intel/SDMs/253667-019.pdf ↩

344. Agner Fog, Instruction Tables, AMD K7 section. https://www.agner.org/optimize/instruction_tables.pdf ↩

345. "579838 – glibc not compatible with AMD Geode LX". Archived from the original on 30 Jul 2023. https://web.archive.org/web/20230730214505/https://bugzilla.redhat.com/show_bug.cgi?id=579838#c46 ↩

346. Intel Software Developers Manual, volume 2B (April 2005, order no 235667-015, does not list 0F0D-nop) https://kib.kiev.ua/x86docs/Intel/SDMs/253667-015.pdf ↩

347. Intel Software Developers Manual, volume 2B (June 2005, order no 235667-016, lists 0F0D-nop in opcode table but not under NOP instruction description.) https://kib.kiev.ua/x86docs/Intel/SDMs/253667-016.pdf ↩

348. Catherine Easdon, Undocumented CPU Behaviour on x86 and RISC-V Microarchitectures: A Security Perspective, 10 May 2019, page 39 https://www.cattius.com/images/thesis-unsigned.pdf ↩

349. Intel Software Developers Manual, volume 2B (order no. 253667-060, September 2016) does not list UD0 and UD1. https://kib.kiev.ua/x86docs/Intel/SDMs/253667-060.pdf ↩

350. Intel, Software Developer's Manual, vol 2B, order no. 253667-061, dec 2016 – lists UD1 (with ModR/M byte) and UD0 (without ModR/M byte) on page 4-687. https://kib.kiev.ua/x86docs/Intel/SDMs/253667-061.pdf ↩

351. "PCJS : pcjs/x86op0F.js (two-byte x86 opcode handlers), lines 1647–1651". GitHub. 17 April 2022. Archived from the original on 13 Apr 2023. https://web.archive.org/web/20230413012542/https://github.com/jeffpar/pcjs/blob/e565ffa65d8ee5d600ec04e62c6651dabb4894cb/machines/pcx86/lib/x86op0f.js#L1647 ↩

352. "80486 paging protection faults? \ VOGONS". Archived from the original on 9 April 2022. https://www.vogons.org/viewtopic.php?t=62949 ↩

353. "Invalid opcode handling \ VOGONS". Archived from the original on 9 April 2022. https://www.vogons.org/viewtopic.php?t=13379 ↩

354. "Invalid instructions cause exit even if Int 6 is hooked \ VOGONS". Archived from the original on 9 April 2022. https://www.vogons.org/viewtopic.php?t=21418 ↩

355. "Tutorial – Calling Win32 from DOS". Ragestorm. 17 Sep 2005. Archived from the original on 9 April 2022. https://www.ragestorm.net/tutorial?id=27 ↩

356. "Accessing Windows device drivers from DOS programs". Archived from the original on 8 Nov 2011. https://web.archive.org/web/20111108011230/https://sta.c64.org/blog/dosvddaccess.html ↩

357. "8086 microcode disassembled". Reenigne blog. 2020-09-03. Archived from the original on 8 Dec 2023. Retrieved 2022-07-26. Using the REP or REPNE prefix with a MUL or IMUL instruction negates the product. Using the REP or REPNE prefix with an IDIV instruction negates the quotient. https://www.reenigne.org/blog/8086-microcode-disassembled/ ↩

358. "8086 microcode disassembled". Reenigne blog. 2020-09-03. Archived from the original on 8 Dec 2023. Retrieved 2022-07-26. Using the REP or REPNE prefix with a MUL or IMUL instruction negates the product. Using the REP or REPNE prefix with an IDIV instruction negates the quotient. https://www.reenigne.org/blog/8086-microcode-disassembled/ ↩

359. "Re: Undocumented opcodes (HINT_NOP)". Archived from the original on 2004-11-06. Retrieved 2010-11-07. https://web.archive.org/web/20041106070621/http://www.sandpile.org/post/msgs/20004129.htm ↩

360. "Re: Also some undocumented 0Fh opcodes". Archived from the original on 2003-06-26. Retrieved 2010-11-07. https://web.archive.org/web/20030626044017/http://www.sandpile.org/post/msgs/20003986.htm ↩

361. Intel's RCCE library for the SCC used opcode 0F 0A for SCC's message invalidation instruction. https://web.archive.org/web/20220424231054/https://github.com/Intel-SCC/RCCE/blob/master/src/RCCE_admin.c#L87 ↩

362. Intel Labs, SCC External Architecture Specification (EAS), Revision 0.94, p.29. Archived on May 22, 2022. https://www.intel.com/content/dam/www/public/us/en/documents/technology-briefs/intel-labs-single-chip-cloud-architecture-brief.pdf ↩

363. "Undocumented x86 instructions to control the CPU at the microarchitecture level in modern Intel processors" (PDF). 9 July 2021. https://raw.githubusercontent.com/chip-red-pill/udbgInstr/main/paper/undocumented_x86_insts_for_uarch_control.pdf ↩

364. Robert R. Collins, Undocumented OpCodes: UMOV. Archived on Feb 21, 2001. http://www.rcollins.org/secrets/opcodes/UMOV.html ↩

365. Herbert Oppmann, NXOP (Opcode 0Fh 55h) https://www.memotech.franken.de/NexGen/Opcode0F55.html ↩

366. Herbert Oppmann, NexGen Nx586 Hypercode Source, see COMMON.INC. Archived on 9 Apr 2023. https://www.memotech.franken.de/NexGen/Source/index.html ↩

367. Herbert Oppmann, Inside the NexGen Nx586 System BIOS. Archived on 29 Dec 2023. https://www.memotech.franken.de/NexGen/Bios.html ↩

368. Intel, XuCode: An Innovative Technology for Implementing Complex Instruction Flows, May 6, 2021. Archived on Jul 19, 2022. https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/secure-coding/xucode-implementing-complex-instruction-flows.html ↩

369. Grzegorz Mazur, AMD 3DNow! undocumented instructions https://web.archive.org/web/20000121143428/http://x86.ddj.com/articles/3dnow/amd_3dnow.htm ↩

370. "Undocumented 3DNow! Instructions". grafi.ii.pw.edu.pl. Archived from the original on 30 January 2003. Retrieved 22 February 2022. https://web.archive.org/web/20030130030723/http://grafi.ii.pw.edu.pl/gbm/x86/3dundoc.html ↩

371. Potemkin's Hacker Group's OPCODE.LST, v4.51, 15 Oct 1999. Archived on 21 May 2001. http://phg.chat.ru/opcode.txt ↩

372. "[UCA CPU Analysis] Prototype UMC Green CPU U5S-SUPER33". 25 May 2020. Archived from the original on 9 Jun 2023. https://x86.fr/uca-cpu-analysis-prototype-umc-green-cpu-u5s-super33 ↩

373. Agner Fog, The Microarchitecture of Intel, AMD and VIA CPUs, section 3.4 "Branch Prediction in P4 and P4E". Archived on 7 Jan 2024. https://www.agner.org/optimize/microarchitecture.pdf ↩

374. Reddit /r/Amd discussion thread: Ryzen has undocumented support for FMA4 https://www.reddit.com/r/Amd/comments/68s4bj/ryzen_has_undocumented_support_for_fma4/dh0y353/ ↩

375. Christopher Domas, Breaking the x86 ISA, 27 July 2017. Archived on 27 Dec 2023. https://raw.githubusercontent.com/xoreaxeaxeax/sandsifter/dff63246fed84d90118441b8ba5b5d3bdd094427/references/domas_breaking_the_x86_isa_wp.pdf ↩

376. Xixing Li et al, UISFuzz: An Efficient Fuzzing Method for CPU Undocumented Instruction Searching, 9 Oct 2019. Archived on 27 Dec 2023. https://ieeexplore.ieee.org/abstract/document/8863327 ↩

377. "Undocumented 3DNow! Instructions". grafi.ii.pw.edu.pl. Archived from the original on 30 January 2003. Retrieved 22 February 2022. https://web.archive.org/web/20030130030723/http://grafi.ii.pw.edu.pl/gbm/x86/3dundoc.html ↩

378. Microprocessor Report, MediaGX Targets Low-Cost PCs (vol 11, no. 3, mar 10, 1997). Archived on 6 Jun 2022. http://www.cecs.uci.edu/~papers/mpr/MPR/ARTICLES/110301.PDF ↩

379. "Welcome to the OpenSSL Project". GitHub. 21 April 2022. Archived from the original on 4 Jan 2022. https://github.com/openssl/openssl/blob/1aa89a7a3afb053d0c0b7fad8d3ea1b0a5447289/engines/asm/e_padlock-x86.pl#L597 ↩

380. https://lkml.iu.edu/2308.0/02183.html https://lkml.iu.edu/2308.0/02183.html ↩

381. Kary Jin, PATCH: Update PadLock engine for VIA C7 and Nano CPUs, openssl-dev mailing list, 10 Jun 2011. Archived on 11 Feb 2022. https://marc.info/?l=openssl-dev&m=130767391615291&w=2 ↩

382. Christopher Domas, Breaking the x86 ISA, 27 July 2017. Archived on 27 Dec 2023. https://raw.githubusercontent.com/xoreaxeaxeax/sandsifter/dff63246fed84d90118441b8ba5b5d3bdd094427/references/domas_breaking_the_x86_isa_wp.pdf ↩

383. Xixing Li et al, UISFuzz: An Efficient Fuzzing Method for CPU Undocumented Instruction Searching, 9 Oct 2019. Archived on 27 Dec 2023. https://ieeexplore.ieee.org/abstract/document/8863327 ↩

384. https://gitee.com/openeuler/kernel/pulls/85 https://gitee.com/openeuler/kernel/pulls/85 ↩

385. USPTO/Zhaoxin, Patent application US2023/006718: Processor with a hash cryptographic algorithm and data processing thereof, pages 13 and 45, Mar 2, 2023. Archived on Sep 12, 2023. https://image-ppubs.uspto.gov/dirsearch-public/print/downloadPdf/20230066718 ↩

386. https://lwn.net/Articles/950884/ https://lwn.net/Articles/950884/ ↩

387. InstLatx64, CPUID dump for Zhaoxin KaiXian KX-6000G – has the SM2 and xmodx feature bits set (CPUID leaf C0000001:EDX:bits 0 and 29). Archived on Jul 25, 2023. http://users.atw.hu/instlatx64/CentaurHauls/CentaurHauls00307B2_KX6000_01_CPUID.txt ↩

388. OpenEuler kernel pull request 2602: x86/delay: add support for Zhaoxin ZXPAUSE instruction. Gitee. 26 Oct 2023. Archived on 22 Jan 2024. https://gitee.com/openeuler/kernel/pulls/2602/files ↩

389. https://gitee.com/openeuler/kernel/pulls/85 https://gitee.com/openeuler/kernel/pulls/85 ↩

390. InstLatx64, CPUID dump for Zhaoxin KaiXian KX-6000G – has the SM2 and xmodx feature bits set (CPUID leaf C0000001:EDX:bits 0 and 29). Archived on Jul 25, 2023. http://users.atw.hu/instlatx64/CentaurHauls/CentaurHauls00307B2_KX6000_01_CPUID.txt ↩

391. Intel 80286 and 80287 Programmers Reference Manual, 1987 (order no. 210498-005), p. 485 http://bitsavers.trailing-edge.com/components/intel/80286/210498-005_80286_and_80287_Programmers_Reference_Manual_1987.pdf ↩

392. ISA datafile for Intel XED (April 17, 2022), lines 916-944 https://github.com/intelxed/xed/blob/ef19f00de14a9c2c253c1c9b1119e1617280e3f2/datafiles/xed-isa.txt#L916 ↩

393. Cyrix 6x86 processor data book, page 6-34 https://www.ardent-tool.com/CPU/docs/Cyrix/6x86/94175.pdf ↩

394. AMD Geode LX Processors Data Book, publication 33234H, p.670 https://www.amd.com/system/files/TechDocs/33234H_LX_databook.pdf ↩