Editing X86 instruction listings (section)

== x86 integer instructions ==
{{Main|x86 assembly language}}
Below is the full [[8086]]/[[8088]] instruction set of Intel (81 instructions total).<ref>{{Cite web | url=https://eecs.wsu.edu/~ee314/handouts/x86ref.pdf | title=Intel 80x86 Instruction Set Summary | website=eecs.wsu.edu}}</ref> 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 ([[Intel 80186|i186]], [[Intel 80286|i286]], [[i386]], [[i486]], [[Pentium (original)|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).

{{sticky header}}
{| class="wikitable sortable sticky-header"
|+ Original 8086/8088 instruction set
! style="line-height:120%; text-align:left" | In-<br />struc-<br />tion !! Meaning !! Notes !! Opcode
|- id=mnem-aaa
| {{mono|[[Intel BCD opcodes|AAA]]}} || ASCII adjust AL after addition || used with unpacked [[binary-coded decimal]] || {{mono|0x37}}
|-
| {{mono|AAD}} || ASCII adjust AX before division || 8086/8088 datasheet documents only base 10 version of the AAD instruction ([[opcode]] {{mono|0xD5}} {{mono|0x0A}}), but any other base will work. Later Intel's documentation has the generic form too. [[NEC V20]] and V30 (and possibly other NEC V-series CPUs) always use base 10, and ignore the argument, causing a number of incompatibilities || {{mono|0xD5}}
|-
| {{mono|AAM}} || ASCII adjust AX after multiplication || Only base 10 version (Operand is 0xA) is documented, see notes for AAD || {{mono|0xD4}}
|-
| {{mono|AAS}} || ASCII adjust AL after subtraction || || {{mono|0x3F}}
|-
| {{mono|ADC}} || Add with carry || (1) <code> r += (r/m/imm+CF);</code> (2) <code>m += (r/imm+CF);</code> || {{mono|0x10}}...{{mono|0x15}}, {{mono|0x80}}...{{mono|0x81/2}}, {{mono|0x83/2}}
|-
| {{mono|ADD}} || Add || (1) <code> r += r/m/imm;</code> (2) <code>m += r/imm;</code> || {{mono|0x00}}...{{mono|0x05}}, {{mono|0x80/0}}...{{mono|0x81/0}}, {{mono|0x83/0}}
|-
| {{mono|AND}} || [[Logical conjunction|Logical AND]] || (1) <code> r &= r/m/imm;</code> (2) <code>m &= r/imm;</code>  || {{mono|0x20}}...{{mono|0x25}}, {{mono|0x80}}...{{mono|0x81/4}}, {{mono|0x83/4}}
|-
| {{mono|CALL}} || [[Function (computer programming)|Call procedure]] || {{code|lang=nasm|push eip; eip points to the instruction directly after the call}} || {{mono|0x9A}}, {{mono|0xE8}}, {{mono|0xFF/2}}, {{mono|0xFF/3}}
|-
| {{mono|CBW}} || Convert byte to word || <code>AX = AL ; sign extended</code>  || {{mono|0x98}}
|-
| {{mono|CLC}} || Clear [[carry flag]] || <code>CF = 0;</code> || {{mono|0xF8}}
|-
| {{mono|CLD}} || Clear [[direction flag]] || <code>DF = 0;</code>  || {{mono|0xFC}}
|-
| {{mono|[[CLI (x86 instruction)|CLI]]}} || Clear [[IF (x86 flag)|interrupt flag]] || <code>IF = 0;</code> || {{mono|0xFA}}
|-
| {{mono|CMC}} || Complement carry flag || <code>CF = !CF;</code> || {{mono|0xF5}}
|-
| {{mono|CMP}} || Compare operands || (1) <code> r - r/m/imm;</code> (2) <code>m - r/imm;</code> || {{mono|0x38}}...{{mono|0x3D}}, {{mono|0x80}}...{{mono|0x81/7}}, {{mono|0x83/7}}
|-
| {{mono|CMPSB}} || Compare bytes in memory. May be used with a {{mono|REPE}} or {{mono|REPNE}} prefix to test and repeat the instruction {{mono|CX}} times. || {{sxhl|lang=c|1=if (DF==0) *(byte*)SI++ - *(byte*)ES:DI++;
else       *(byte*)SI-- - *(byte*)ES:DI--;}} || {{mono|0xA6}}
|-
| {{mono|CMPSW}} || Compare words. May be used with a {{mono|REPE}} or {{mono|REPNE}} prefix to test and repeat the instruction {{mono|CX}} times. || {{sxhl|lang=c|1=if (DF==0) *(word*)SI++ - *(word*)ES:DI++;
else       *(word*)SI-- - *(word*)ES:DI--;}} || {{mono|0xA7}}
|-
| {{mono|CWD}} || Convert word to doubleword || || {{mono|0x99}}
|-
| {{mono|[[Intel BCD opcodes|DAA]]}} || Decimal adjust AL after addition || (used with packed [[binary-coded decimal]]) || {{mono|0x27}}
|-
| {{mono|[[Intel BCD opcodes|DAS]]}} || Decimal adjust AL after subtraction || || {{mono|0x2F}}
|-
| {{mono|DEC}} || Decrement by 1 || || {{mono|0x48}}...{{mono|0x4F}}, {{mono|0xFE/1}}, {{mono|0xFF/1}}
|-
| {{mono|DIV}} || [[Signed number representations|Unsigned]] divide || (1) <code>AX = DX:AX / r/m;</code> resulting <code>DX = remainder</code> (2) <code>AL = AX / r/m;</code> resulting <code>AH = remainder</code> || {{mono|0xF7/6}}, {{mono|0xF6/6}}
|-
| {{mono|ESC}} || Used with [[floating-point unit]] || || {{mono|0xD8}}..{{mono|0xDF}}
|-
| {{mono|[[HLT (x86 instruction)|HLT]]}} || Enter halt state || || {{mono|0xF4}}
|-
| {{mono|IDIV}} || Signed divide || (1) <code>AX = DX:AX / r/m;</code> resulting <code>DX = remainder</code> (2) <code>AL = AX / r/m;</code> resulting <code>AH = remainder</code> || {{mono|0xF7/7}}, {{mono|0xF6/7}}
|-
| {{mono|IMUL}} || Signed multiply in One-operand form || (1) <code>DX:AX = AX * r/m;</code> (2) <code>AX = AL * r/m</code> || {{mono|0xF7/5}}, {{mono|0xF6/5}}
|-
| {{mono|IN}} || Input from port || (1) <code>AL = port[imm];</code> (2) <code>AL = port[DX];</code> (3) <code>AX = port[imm];</code> (4) <code>AX = port[DX];</code> || {{mono|0xE4}}, {{mono|0xE5}}, {{mono|0xEC}}, {{mono|0xED}}
|-
| {{mono|INC}} || Increment by 1 || || {{mono|0x40}}...{{mono|0x47}}, {{mono|0xFE/0}}, {{mono|0xFF/0}}
|-
| {{mono|[[INT (x86 instruction)|INT]]}} || Call to [[interrupt]] || || {{mono|0xCC}}, {{mono|0xCD}}
|-
| {{mono|INTO}} || Call to interrupt if overflow || || {{mono|0xCE}}
|-
| {{mono|IRET}} || Return from interrupt || || {{mono|0xCF}}
|-
| {{mono|Jcc}} || [[Branch (computer science)|Jump if condition]] || {{mono|JA, JAE, JB, JBE, JC (same as JB), JE, JG, JGE, JL, JLE, JNA (same as JBE), JNAE (same as JB), JNB (same as JAE), JNBE, JNC (same as JAE), JNE, JNG (same as JLE), JNGE (same as JL), JNL (same as JGE), JNLE (same as JG), JNO, JNP, JNS, JNZ (same as JNE), JO, JP, JPE (same as JP), JPO (same as JNP), JS, JZ (same as JE)}}<ref>{{cite web | url = http://unixwiz.net/techtips/x86-jumps.html | title = Intel x85 JUMP quick reference | access-date = 2025-04-01 }}.</ref> || {{mono|0x70}}...{{mono|0x7F}}
|-
| {{mono|JCXZ}} || Jump if CX is zero || {{mono|JECXZ}} for ECX instead of CX in 32 bit mode (same opcode). || {{mono|0xE3}}
|-
| {{mono|[[JMP (x86 instruction)|JMP]]}} || Jump || || {{mono|0xE9}}...{{mono|0xEB}}, {{mono|0xFF/4}}, {{mono|0xFF/5}}
|-
| {{mono|LAHF}} || Load FLAGS into AH register || || {{mono|0x9F}}
|-
| {{mono|LDS}} || Load DS:r with far pointer || <code> r = m; DS = 2 + m;</code> || {{mono|0xC5}}
|-
| {{mono|LEA}} || [[Load Effective Address]] || || {{mono|0x8D}}
|-
| {{mono|LES}} || Load ES:r with far pointer ||<code> r = m; ES = 2 + m;</code> || {{mono|0xC4}}
|-
| {{mono|LOCK}} || Assert BUS LOCK# signal || (for multiprocessing) || {{mono|0xF0}}
|-
| {{mono|LODSB}} || Load string byte. May be used with a {{mono|REP}} prefix to repeat the instruction {{mono|CX}} times. || {{code|lang=c|1=if (DF==0) AL = *SI++; else AL = *SI--;}} || {{mono|0xAC}}
|-
| {{mono|LODSW}} || Load string word. May be used with a {{mono|REP}} prefix to repeat the instruction {{mono|CX}} times. || {{code|lang=c|1=if (DF==0) AX = *SI++; else AX = *SI--;}} || {{mono|0xAD}}
|-
| {{mono|LOOP}}/<br />{{mono|LOOPx}} || Loop control || ({{mono|LOOPE, LOOPNE, LOOPNZ, LOOPZ}}) {{code|lang=c|1=if (x && --CX) goto lbl;}} || {{mono|0xE0}}...{{mono|0xE2}}
|-
| {{mono|MOV}} || Move || (1) <code> r = r/m/imm;</code> (2) <code>m = r/imm;</code> (3) <code> r/m = sreg;</code> (4) <code> sreg = r/m;</code> ||{{mono|0xA0}}...{{mono|0xA3}}, {{mono|0x8C}}, {{mono|0x8E}}
|-
| {{mono|MOVSB}} || Move byte from string to string. May be used with a {{mono|REP}} prefix to repeat the instruction {{mono|CX}} times. || {{sxhl|lang=c|1=if (DF==0) *(byte*)ES:DI++ = *(byte*)SI++;
else       *(byte*)ES:DI-- = *(byte*)SI--;}}. || {{mono|0xA4}}
|-
| {{mono|MOVSW}} || Move word from string to string. May be used with a {{mono|REP}} prefix to repeat the instruction {{mono|CX}} times. || {{sxhl|lang=c|1=if (DF==0) *(word*)ES:DI++ = *(word*)SI++;
else       *(word*)ES:DI-- = *(word*)SI--;}} || {{mono|0xA5}}
|-
| {{mono|MUL}} || Unsigned multiply || (1) <code>DX:AX = AX * r/m;</code> (2) <code>AX = AL * r/m;</code> || {{mono|0xF7/4}}, {{mono|0xF6/4}}
|-
| {{mono|NEG}} || [[Two's complement]] negation || {{code|lang=c|1=r/m = 0 – r/m;}} || {{mono|0xF6/3}}...{{mono|0xF7/3}}
|-
| {{mono|[[NOP (code)|NOP]]}} || No operation || opcode equivalent to {{code|XCHG EAX, EAX}} || {{mono|0x90}}
|-
| {{mono|NOT}} || Negate the operand, [[Bitwise operation#NOT|logical NOT]] ||  {{code|lang=c|1=r/m ^= -1;}} || {{mono|0xF6/2}}...{{mono|0xF7/2}}
|-
| {{mono|OR}} || [[Logical disjunction|Logical OR]] || (1) <code> r &mid;= r/m/imm;</code> (2) <code>m &mid;= r/imm;</code> || {{mono|0x08}}...{{mono|0x0D}}, {{mono|0x80}}...{{mono|0x81/1}}, {{mono|0x83/1}}
|-
| {{mono|OUT}} || Output to port || (1) <code>port[imm] = AL;</code> (2) <code>port[DX] = AL;</code> (3) <code>port[imm] = AX;</code> (4) <code>port[DX] = AX;</code> || {{mono|0xE6}}, {{mono|0xE7}}, {{mono|0xEE}}, {{mono|0xEF}}
|-
| {{mono|POP}} || Pop data from [[Stack (data structure)|stack]] || <code>r/m/sreg = *SP++;</code> || {{mono|0x07}}, {{mono|0x17}}, {{mono|0x1F}}, {{mono|0x58}}...{{mono|0x5F}}, {{mono|0x8F/0}}
|-
| {{mono|POPF}} || Pop [[FLAGS register (computing)|FLAGS register]] from stack|| <code>FLAGS = *SP++;</code>  || {{mono|0x9D}}
|-
| {{mono|PUSH}} || Push data onto stack || {{code|lang=c|1=*--SP = r/m/sreg;}} || {{mono|0x06}}, {{mono|0x0E}}, {{mono|0x16}}, {{mono|0x1E}}, {{mono|0x50}}...{{mono|0x57}}, {{mono|0xFF/6}}
|-
| {{mono|PUSHF}} || Push FLAGS onto stack || {{code|lang=c|1=*--SP = FLAGS;}} || {{mono|0x9C}}
|-
| {{mono|RCL}} || Rotate left (with carry) || || {{mono|0xC0}}...{{mono|0xC1/2}} (186+), {{mono|0xD0}}...{{mono|0xD3/2}}
|-
| {{mono|RCR}} || Rotate right (with carry) || || {{mono|0xC0}}...{{mono|0xC1/3}} (186+), {{mono|0xD0}}...{{mono|0xD3/3}}
|-
| {{mono|REPxx}} || Repeat MOVS/STOS/CMPS/LODS/SCAS || ({{mono|REP, REPE, REPNE, REPNZ, REPZ}}) || {{mono|0xF2}}, {{mono|0xF3}}
|-
| {{mono|RET}} || Return from procedure || Not a real instruction. The assembler will translate these to a RETN or a RETF depending on the memory model of the target system. ||
|-
| {{mono|RETN}} || Return from near procedure || || {{mono|0xC2}}, {{mono|0xC3}}
|-
| {{mono|RETF}} || Return from far procedure || || {{mono|0xCA}}, {{mono|0xCB}}
|-
| {{mono|ROL}} || Rotate left || || {{mono|0xC0}}...{{mono|0xC1/0}} (186+), {{mono|0xD0}}...{{mono|0xD3/0}}
|-
| {{mono|ROR}} || Rotate right || || {{mono|0xC0}}...{{mono|0xC1/1}} (186+), {{mono|0xD0}}...{{mono|0xD3/1}}
|-
| {{mono|SAHF}} || Store AH into FLAGS || || {{mono|0x9E}}
|-
| {{mono|SAL}} || [[Arithmetic shift|Shift Arithmetically]] left (signed shift left) || (1) <code>r/m <<= 1;</code> (2) <code>r/m <<= CL;</code> || {{mono|0xC0}}...{{mono|0xC1/4}} (186+), {{mono|0xD0}}...{{mono|0xD3/4}}
|-
| {{mono|SAR}} || Shift Arithmetically right (signed shift right) || (1) <code>(signed) r/m >>= 1;</code> (2) <code>(signed) r/m >>= CL;</code> ||  {{mono|0xC0}}...{{mono|0xC1/7}} (186+), {{mono|0xD0}}...{{mono|0xD3/7}}
|-
| {{mono|SBB}} || Subtraction with borrow || (1) <code> r -= (r/m/imm+CF);</code> (2) <code>m -= (r/imm+CF);</code> alternative 1-byte encoding of {{nowrap|<code>SBB AL, AL</code>}} is available via [[#Undocumented instructions|undocumented]] SALC instruction || {{mono|0x18}}...{{mono|0x1D}}, {{mono|0x80}}...{{mono|0x81/3}}, {{mono|0x83/3}}
|-
| {{mono|SCASB}} || Compare byte string. May be used with a {{mono|REPE}} or {{mono|REPNE}} prefix to test and repeat the instruction {{mono|CX}} times. || {{code|lang=c|1=if (DF==0) AL - *ES:DI++; else AL - *ES:DI--;}} || {{mono|0xAE}}
|-
| {{mono|SCASW}} || Compare word string. May be used with a {{mono|REPE}} or {{mono|REPNE}} prefix to test and repeat the instruction {{mono|CX}} times. || {{code|lang=c|1=if (DF==0) AX - *ES:DI++; else AX - *ES:DI--;}} || {{mono|0xAF}}
|-
| {{mono|SHL}} || [[Logical shift|Shift]] left (unsigned shift left) || Same opcode as SAL, since logical left shifts are equal to arithmetical left shifts. || {{mono|0xC0}}...{{mono|0xC1/4}} (186+), {{mono|0xD0}}...{{mono|0xD3/4}}
|-
| {{mono|SHR}} || Shift right (unsigned shift right) || || {{mono|0xC0}}...{{mono|0xC1/5}} (186+), {{mono|0xD0}}...{{mono|0xD3/5}}
|-
| {{mono|STC}} || Set carry flag || <code>CF = 1;</code> || {{mono|0xF9}}
|-
| {{mono|STD}} || Set direction flag || <code>DF = 1;</code> || {{mono|0xFD}}
|-
| {{mono|[[STI (x86 instruction)|STI]]}} || Set interrupt flag || <code>IF = 1;</code> || {{mono|0xFB}}
|-
| {{mono|STOSB}} || Store byte in string. May be used with a {{mono|REP}} prefix to repeat the instruction {{mono|CX}} times. || {{code|lang=c|1=if (DF==0) *ES:DI++ = AL; else *ES:DI-- = AL;}} || {{mono|0xAA}}
|-
| {{mono|STOSW}} || Store word in string. May be used with a {{mono|REP}} prefix to repeat the instruction {{mono|CX}} times. || {{code|lang=c|1=if (DF==0) *ES:DI++ = AX; else *ES:DI-- = AX;}} || {{mono|0xAB}}
|-
| {{mono|SUB}} || Subtraction || (1) <code> r -= r/m/imm;</code> (2) <code>m -= r/imm;</code> || {{mono|0x28}}...{{mono|0x2D}}, {{mono|0x80}}...{{mono|0x81/5}}, {{mono|0x83/5}}
|-
| {{mono|[[TEST (x86 instruction)|TEST]]}} || Logical compare (AND) || (1) <code> r & r/m/imm;</code> (2) <code>m & r/imm;</code> || {{mono|0x84}}, {{mono|0x85}}, {{mono|0xA8}}, {{mono|0xA9}}, {{mono|0xF6/0}}, {{mono|0xF7/0}}
|-
| {{mono|WAIT}} || Wait until not busy || Waits until BUSY# pin is inactive (used with [[floating-point unit]]) || {{mono|0x9B}}
|-
| {{mono|XCHG}} || Exchange data || {{code|lang=asm|1=r :=: r/m;}} A [[spinlock]] typically uses xchg as an [[atomic operation]]. ([[coma bug]]). || {{mono|0x86}}, {{mono|0x87}}, {{mono|0x91}}...{{mono|0x97}}
|-
| {{mono|XLAT}} || Table look-up translation || behaves like {{code|MOV AL, [BX+AL]}} || {{mono|0xD7}}
|-
| {{mono|XOR}} || [[Exclusive or|Exclusive OR]] || (1) <code> r ^+= r/m/imm;</code> (2) <code>m ^= r/imm;</code> || {{mono|0x30}}...{{mono|0x35}}, {{mono|0x80}}...{{mono|0x81/6}}, {{mono|0x83/6}}
|}

=== Added in specific processors ===

==== Added with [[Intel 80186|80186]]/[[Intel 80188|80188]] ====

{{sticky header}}
{| class="wikitable sortable sticky-header"
! Instruction !! Opcode !! Meaning !! Notes
|-
| {{mono|BOUND}} || 62 ''/r'' ||  Check array index against bounds || raises software interrupt 5 if test fails
|-
| {{mono|ENTER}} || C8 ''iw ib'' || Enter stack frame || Modifies stack for entry to procedure for high level language. Takes two operands: the amount of storage to be allocated on the stack and the nesting level of the procedure.
|-
| rowspan="2" | {{mono|INSB/INSW}}
| 6C
| rowspan="2" | Input from port to string. May be used with a REP prefix to repeat the instruction CX times.
| rowspan="2"| equivalent to:
<syntaxhighlight lang="nasm">
IN AL, DX
MOV ES:[DI], AL
INC DI ; adjust DI according to operand size and DF
</syntaxhighlight>
|-
| 6D
|-
| {{mono|LEAVE}} || C9 || Leave stack frame || Releases the local stack storage created by the previous ENTER instruction.
|-
| rowspan="2"| {{mono|OUTSB/OUTSW}}
| 6E
| rowspan="2" | Output string to port. May be used with a REP prefix to repeat the instruction CX times.
| rowspan="2"| equivalent to:
<syntaxhighlight lang="nasm">
MOV AL, DS:[SI]
OUT DX, AL
INC SI ; adjust SI according to operand size and DF
</syntaxhighlight>
|-
| 6F
|-
| {{mono|POPA}} || 61 ||  Pop all general purpose registers from stack || equivalent to:
<syntaxhighlight lang="nasm">POP DI
POP SI
POP BP
POP AX ; no POP SP here, all it does is ADD SP, 2 (since AX will be overwritten later)
POP BX
POP DX
POP CX
POP AX</syntaxhighlight>
|-
| {{mono|PUSHA}} || 60 || Push all general purpose registers onto stack || equivalent to:
<syntaxhighlight lang="nasm">PUSH AX
PUSH CX
PUSH DX
PUSH BX
PUSH SP ; The value stored is the initial SP value
PUSH BP
PUSH SI
PUSH DI</syntaxhighlight>
|-
| rowspan="2"| {{mono|PUSH}} immediate
| 6A ''ib''
| rowspan="2"| Push an immediate byte/word value onto the stack
| rowspan="2"| example:
<syntaxhighlight lang="nasm">PUSH 12h
PUSH 1200h</syntaxhighlight>
|-
| 68 ''iw''
|-
| rowspan="2" | {{mono|IMUL}} immediate
| 6B ''/r ib''
|rowspan="2"|  Signed and unsigned multiplication of immediate byte/word value
|rowspan="2"| example:
<syntaxhighlight lang="nasm">IMUL BX,12h
IMUL DX,1200h
IMUL CX, DX, 12h
IMUL BX, SI, 1200h
IMUL DI, word ptr [BX+SI], 12h
IMUL SI, word ptr [BP-4], 1200h
</syntaxhighlight>
Note that since the lower half is the same for unsigned and signed multiplication, this version of the instruction can be used for unsigned multiplication as well.
|-
| 69 ''/r iw''
|-
| rowspan="2" | {{mono|SHL/SHR/SAL/SAR/ROL/ROR/RCL/RCR}} immediate
| C0
| rowspan="2" | Rotate/shift bits with an immediate value greater than 1
| rowspan="2" | example:
<syntaxhighlight lang="nasm">ROL AX,3
SHR BL,3</syntaxhighlight>
|-
| C1
|}

==== 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.

{{sticky header}}
{| class="wikitable sortable sticky-header"
! Instruction !! Opcode !! Instruction description !! Real mode !! [[Protection ring|Ring]]
|-
! colspan="5" |
|-
| <code>LGDT m16&32</code>{{efn|name=gdt_idt_descriptor|text=The descriptors used by the <code>LGDT</code>, <code>LIDT</code>, <code>SGDT</code> and <code>SIDT</code> 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.<br />For <code>LGDT</code> and <code>LIDT</code> with a 16-bit operand size, the address is ANDed with 00FFFFFFh.

On Intel (but not AMD) CPUs, the <code>SGDT</code> and <code>SIDT</code> 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.<ref>Michal Necasek SGDT/SIDT Fiction and Reality. [https://web.archive.org/web/20231129085923/https://www.os2museum.com/wp/sgdtsidt-fiction-and-reality/ Archived] on 29 Nov 2023.</ref>}}
| <code>0F 01 /2</code>
| Load GDTR ([[Global Descriptor Table]] Register) from memory.{{efn|name=i286_serialize|text=The <code>LGDT</code>, <code>LIDT</code>, <code>LLDT</code> and <code>LTR</code> instructions are serializing on [[Pentium (original)|Pentium]] and later processors.}}
| rowspan="4" {{yes}}
| rowspan="6" {{no|0}}
|-
| {{nowrap|<code>LIDT m16&32</code>{{efn|name=gdt_idt_descriptor}}}}
| <code>0F 01 /3</code>
| Load IDTR (Interrupt Descriptor Table Register) from memory.{{efn|name=i286_serialize}}<br />The IDTR controls not just the address/size of the IDT ([[interrupt Descriptor Table]]) in [[protected mode]], but the IVT (Interrupt Vector Table) in [[real mode]] as well.
|-
| <code>LMSW r/m16</code>
| <code>0F 01 /6</code>
| Load MSW (Machine Status Word) from 16-bit register or memory.{{efn|text=The <code>LMSW</code> instruction is serializing on Intel processors from [[Pentium (original)|Pentium]] onwards, but not on AMD processors.}}{{efn|text=On 80386 and later, the "Machine Status Word" is the same as the [[Control register#CR0|CR0 control register]] – however, the <code>LMSW</code> instruction can only modify the bottom 4 bits of this register and cannot clear bit 0. The inability to clear bit 0 means that <code>LMSW</code> can be used to enter but not leave x86 [[Protected Mode]].<br />On 80286, it is not possible to leave Protected Mode at all (neither with <code>LMSW</code> nor with <code>LOADALL</code><ref name="loadall286_doc"/>) without a [[Hardware reset|CPU reset]] – on 80386 and later, it is possible to leave Protected Mode, but this requires the use of the 80386-and-later <code>MOV</code> to <code>CR0</code> instruction.}}
|-
| <code>CLTS</code>
| <code>0F 06</code>
| Clear task-switched flag in the MSW.
|-
| <code>LLDT r/m16</code>
| <code>0F 00 /2</code>
| Load LDTR (Local Descriptor Table Register) from 16-bit register or memory.{{efn|name=i286_serialize}}
| rowspan="2" {{no|#UD}}
|-
| <code>[[Load Task Register|LTR]] r/m16</code>
| <code>0F 00 /3</code>
| Load TR (Task Register) from 16-bit register or memory.{{efn|name=i286_serialize}}

The TSS ([[Task State Segment]]) specified by the 16-bit argument is marked busy, but a task switch is not done.
|-
! colspan="5" |
|-
| {{nowrap|<code>SGDT m16&32</code>{{efn|name=gdt_idt_descriptor}}}}
| <code>0F 01 /0</code>
| Store GDTR to memory.
| rowspan="3" {{yes}}
| rowspan="5" {{yes2|Usually 3{{efn|text=If <code>[[Control register #CR4|CR4]].UMIP=1</code> is set, then the <code>SGDT</code>, <code>SIDT</code>, <code>SLDT</code>, <code>SMSW</code> and <code>STR</code> instructions can only run in Ring 0.<br />These instructions were unprivileged on all x86 CPUs from 80286 onwards until the introduction of UMIP in 2017.<ref>WikiChip, [https://en.wikichip.org/wiki/x86/umip UMIP – x86]. [https://web.archive.org/web/20230316111706/https://en.wikichip.org/wiki/x86/umip Archived] on 16 Mar 2023.</ref>
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.<ref>Oracle Corp, [https://docs.oracle.com/en/virtualization/virtualbox/6.0/admin/swvirt-details.html Oracle® VM VirtualBox Administrator's Guide for Release 6.0, section 3.5: Details About Software Virtualization]. [https://web.archive.org/web/20231208205121/https://docs.oracle.com/en/virtualization/virtualbox/6.0/admin/swvirt-details.html Archived] on 8 Dec 2023.</ref>}}}}
|-
| <code>SIDT m16&32</code>{{efn|name=gdt_idt_descriptor}}
| <code>0F 01 /1</code>
| Store IDTR to memory.
|-
| <code>SMSW r/m16</code>
| <code>0F 01 /4</code>
| Store MSW to register or 16-bit memory.{{efn|name=i286_extend16}}
|-
| <code>SLDT r/m16</code>
| <code>0F 00 /0</code>
| Store LDTR to register or 16-bit memory.{{efn|name=i286_extend16|text=The <code>SMSW</code>, <code>SLDT</code> and <code>STR</code> 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:
* <code>SMSW</code>: Stores full [[Control register#CR0|CR0]] in x86-64 [[long mode]], undefined otherwise.
* <code>SLDT</code>: Zero-extends 16-bit argument on [[Pentium Pro]] and later processors, undefined on earlier processors.
* <code>STR</code>: Zero-extends 16-bit argument.}}
| rowspan="2" {{no|#UD}}
|-
| <code>STR r/m16</code>
| <code>0F 00 /1</code>
| Store TR to register or 16-bit memory.{{efn|name=i286_extend16}}
|-
! colspan="5" |
|-
| {{nowrap|<code>ARPL r/m16,r16</code>}}
| <code>63 /r</code>{{efn|In 64-bit [[long mode]], the <code>ARPL</code> instruction is not available – the {{nowrap|<code>63 /r</code>}} opcode has been reassigned to the 64-bit-mode-only <code>MOVSXD</code> instruction.}}
| Adjust RPL (Requested [[Protection ring#Privilege level|Privilege Level]]) field of selector. The operation performed is:<pre>
if (dst & 3) < (src & 3) then
   dst = (dst & 0xFFFC) | (src & 3)
   eflags.zf = 1
else
   eflags.zf = 0</pre>
| {{no|#UD{{efn|The <code>ARPL</code> 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 <code>63</code> opcode as a one-byte breakpoint to transition from Virtual 8086 Mode to kernel mode.<ref>Andrew Schulman, "Unauthorized Windows 95" ({{ISBN|1-56884-169-8}}), chapter 8, p.249,257.</ref><ref>[https://patents.google.com/patent/US4974159A/ US Patent 4974159], "Method of transferring control in a multitasking computer system" mentions 63h/ARPL.</ref>}}}}
| rowspan="5" {{yes|3}}
|-
| <code>LAR r,r/m16</code>
| <code>0F 02 /r</code>
| Load access rights byte from the specified [[segment descriptor]].<br />Reads bytes 4-7 of segment descriptor, bitwise-ANDs it with <code>0x00FxFF00</code>,{{efn|text=Bits 19:16 of this mask are documented as "undefined" on Intel CPUs.<ref>Intel, [https://ardent-tool.com/CPU/docs/Intel/Pentium/241430-004.pdf Pentium® Processor Family Developer’s Manual, Volume 3], 1995, order no. 241430-004, section 12.7, p. 323</ref> On AMD CPUs, the mask is documented as <code>0x00FFFF00</code>.}} then stores the bottom 16/32 bits of the result in destination register. Sets [[FLAGS register|EFLAGS]].ZF=1 if the descriptor could be loaded, ZF=0 otherwise.{{efn|name=lar_lsl_unmod|1=For the <code>LAR</code> and <code>LSL</code> instructions, if the specified segment descriptor could not be loaded, then the instruction's destination register is left unmodified.}}
| rowspan="4" {{no|#UD}}
|-
| <code>LSL r,r/m16</code>
| <code>0F 03 /r</code>
| Load segment limit from the specified segment descriptor. Sets ZF=1 if the descriptor could be loaded, ZF=0 otherwise.{{efn|name=lar_lsl_unmod}}
|-
| <code>VERR r/m16</code>
| {{nowrap|<code>0F 00 /4</code>}}
| Verify a segment for reading. Sets ZF=1 if segment can be read, ZF=0 otherwise.
|-
| <code>VERW r/m16</code>
| <code>0F 00 /5</code>
| Verify a segment for writing. Sets ZF=1 if segment can be written, ZF=0 otherwise.{{efn|text=On some Intel CPU/microcode combinations from 2019 onwards, the <code>VERW</code> instruction also flushes microarchitectural data buffers. This enables it to be used as part of workarounds for [[Microarchitectural Data Sampling]] security vulnerabilities.<ref>Intel, [https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/intel-analysis-microarchitectural-data-sampling.html How Microarchitectural Data Sampling works], see mitigations section. [https://archive.today/20220422211750/https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/intel-analysis-microarchitectural-data-sampling.html Archived] on Apr 22,2022</ref><ref>Linux kernel documentation, [https://www.kernel.org/doc/html/latest/x86/mds.html Microarchitectural Data Sampling (MDS) mitigation] {{Webarchive|url=https://web.archive.org/web/20201021233511/https://www.kernel.org/doc/html/latest/x86/mds.html |date=2020-10-21 }}</ref> Some of the microarchitectural buffer-flushing functions that have been added to <code>VERW</code> may require the instruction to be executed with a memory operand.<ref>Intel, [https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/processor-mmio-stale-data-vulnerabilities.html?wapkw=VERW Processor MMIO Stale Data Vulnerabilities], 14 Jun 2022 - see "VERW Buffer Overwriting Details" section. [https://web.archive.org/web/20241003223701/https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/processor-mmio-stale-data-vulnerabilities.html Archived] on 3 Oct 2024.</ref>}}
|-
! colspan="5" |
|-
| {{unofficial2|align="left"|{{mono|&nbsp;[[LOADALL]]}}{{efn|name=i286_undoc|Undocumented, 80286 only.<ref name="loadall286_doc">Intel, [https://docs.pcjs.org/manuals/intel/80286/80286_LOADALL.pdf Undocumented iAPX 286 Test Instruction]. [https://web.archive.org/web/20231220173720/https://docs.pcjs.org/manuals/intel/80286/80286_LOADALL.pdf Archived] on 20 Dec 2023.</ref><ref>VCF Forums, [https://forum.vcfed.org/index.php?threads/i-found-the-saveall-opcode.71519/ I found the SAVEALL opcode], jun 21, 2019. [https://web.archive.org/web/20230413203921/https://forum.vcfed.org/index.php?threads/i-found-the-saveall-opcode.71519/ Archived] on 13 Apr 2023.</ref><ref>rep lodsb, [https://rep-lodsb.mataroa.blog/blog/intel-286-secrets-ice-mode-and-f1-0f-04/ Intel 286 secrets: ICE mode and F1 0F 04], aug 12, 2022. [https://web.archive.org/web/20231208175920/https://rep-lodsb.mataroa.blog/blog/intel-286-secrets-ice-mode-and-f1-0f-04/ Archived] on 8 Dec 2023.</ref> (A different variant of <code>LOADALL</code> with a different opcode and memory layout exists on 80386.)}}}}
| {{unofficial2|align="left"|{{mono|&nbsp;0F 05}}}}
| Load all CPU registers from a 102-byte data structure starting at physical address <code>800h</code>, including "hidden" part of segment descriptor registers.
| rowspan="2" {{yes}}
| rowspan="2" {{no|0}}
|-
| {{unofficial2|align="left"|{{mono|&nbsp;STOREALL}}{{efn|name=i286_undoc}}}}
| {{unofficial2|align="left"|{{mono|&nbsp;F1 0F 04}}}}
| Store all CPU registers to a 102-byte data structure starting at physical address <code>800h</code>, then shut down CPU.
|}
{{notelist}}

==== 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 - <code>D=0</code> makes both 16-bit, <code>D=1</code> 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:
* <code>66h</code>: OperandSize override. Will change OperandSize from 16-bit to 32-bit if <code>CS.D=0</code>, or from 32-bit to 16-bit if <code>CS.D=1</code>.
* <code>67h</code>: AddressSize override. Will change AddressSize from 16-bit to 32-bit if <code>CS.D=0</code>, or from 32-bit to 16-bit if <code>CS.D=1</code>.

The 80386 also introduced the two new segment registers <code>FS</code> and <code>GS</code> as well as the x86 [[Control register|control]], [[x86 debug register|debug]] and [[test register]]s.

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. <code>CWDE</code>, <code>LODSD</code>)
* New opcodes that introduced new functionality (e.g. <code>SHLD</code>, <code>SETcc</code>)
For instruction forms where the operand size can be inferred from the instruction's arguments (e.g. <code>ADD EAX,EBX</code> 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.

{{sticky header}}
{| class="wikitable sortable sticky-header"
|+ 80386: new instruction mnemonics for 32-bit variants of older opcodes
! Type !! Instruction mnemonic !! Opcode !! Description !! Mnemonic for older 16-bit variant !! [[Protection ring|Ring]]
|-
| rowspan="7" | String instructions{{efn|text=For the 32-bit string instructions, the ±± notation is used to indicate that the indicated register is post-decremented by 4 if <code>EFLAGS.DF=1</code> and post-incremented by 4 otherwise.<br />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.<br />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 <code>67</code> prefix.}}{{efn|text=The 32-bit string instructions accept repeat-prefixes in the same way as older 8/16-bit string instructions.<br />For <code>LODSD</code>, <code>STOSD</code>, <code>MOVSD</code>, <code>INSD</code> and <code>OUTSD</code>, the <code>REP</code> prefix (<code>F3</code>) 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).<br />For <code>CMPSD</code> and <code>SCASD</code>, the <code>REPE</code> (<code>F3</code>) and <code>REPNE</code> (<code>F2</code>) prefixes are available, which will repeat the instruction, decrementing rCX for each iteration, but only as long as the flag condition (ZF=1 for <code>REPE</code>, ZF=0 for <code>REPNE</code>) holds true AND rCX ≠ 0.}}
| <code>LODSD</code> || <code>AD</code> || Load string doubleword: <code>EAX := DS:[rSI±±]</code> || <code>LODSW</code>
| rowspan="5" {{yes|3}}
|-
| <code>STOSD</code> || <code>AB</code> || Store string doubleword: <code>ES:[rDI±±] := EAX</code> || <code>STOSW</code>
|-
| <code>MOVSD</code> || <code>A5</code> || Move string doubleword: <code>ES:[rDI±±] := DS:[rSI±±]</code> || <code>MOVSW</code>
|-
| <code>CMPSD</code> || <code>A7</code> || Compare string doubleword: <pre>temp1 := DS:[rSI±±]
temp2 := ES:[rDI±±]
CMP temp1, temp2 /* 32-bit compare and set EFLAGS */</pre> || <code>CMPSW</code>
|-
| <code>SCASD</code> || <code>AF</code> || Scan string doubleword: <pre>temp1 := ES:[rDI±±]
CMP EAX, temp1 /* 32-bit compare and set EFLAGS */</pre> || <code>SCASW</code>
|-
| <code>INSD</code> || <code>6D</code> || Input string from doubleword I/O port:<code>ES:[rDI±±] := port[DX]</code>{{efn|For the <code>INSB/W/D</code> instructions, the memory access rights for the <code>ES:[rDI]</code> 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.}} || <code>INSW</code> || rowspan="2" {{no2|Usually 0{{efn|I/O port access is only allowed when [[Protection ring#Privilege level|CPL≤IOPL]] or the [[Task state segment#I/O port permissions|I/O port permission bitmap]] bits for the port to access are all set to 0.}}}}
|-
| <code>OUTSD</code> || <code>6F</code> || Output string to doubleword I/O port:<code>port[DX] := DS:[rSI±±]</code> || <code>OUTSW</code>
|-
! colspan="6" |
|-
| rowspan="8" | Other
| <code>CWDE</code> || <code>98</code> || [[Sign extension|Sign-extend]] 16-bit value in AX to 32-bit value in EAX{{efn|The <code>CWDE</code> instruction differs from the older <code>CWD</code> instruction in that <code>CWD</code> would sign-extend the 16-bit value in AX into a 32-bit value in the DX:AX register pair.}} || <code>CBW</code>
| rowspan="5" {{yes|3}}
|-
| <code>CDQ</code> || <code>99</code> || Sign-extend 32-bit value in EAX to 64-bit value in EDX:EAX.
Mainly used to prepare a dividend for the 32-bit <code>IDIV</code> (signed divide) instruction.
| <code>CWD</code>
|-
| {{nowrap|<code>JECXZ rel8</code>}} || {{nowrap|<code>E3 ''cb''</code>}}{{efn|For the <code>E3</code> opcode (<code>JCXZ</code>/<code>JECXZ</code>), the choice of whether the instruction will use <code>CX</code> or <code>ECX</code> 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).<br />This also applies to the loop instructions <code>LOOP</code>,<code>LOOPE</code>,<code>LOOPNE</code> (opcodes <code>E0</code>,<code>E1</code>,<code>E2</code>), however, unlike <code>JCXZ</code>/<code>JECXZ</code>, these instructions have not been given new mnemonics for their ECX-using variants.}} || Jump if ECX is zero || <code>JCXZ</code>
|-
| <code>PUSHAD</code> || <code>60</code> || Push all 32-bit registers onto stack{{efn|For <code>PUSHA(D)</code>, the value of SP/ESP pushed onto the stack is the value it had just before the <code>PUSHA(D)</code> instruction started executing.}} || <code>PUSHA</code>
|-
| <code>POPAD</code> || <code>61</code> || Pop all 32-bit general-purpose registers off stack{{efn|For <code>POPA</code>/<code>POPAD</code>, the stack item corresponding to SP/ESP is popped off the stack (performing a memory read), but not placed into SP/ESP.}} || <code>POPA</code>
|-
| <code>PUSHFD</code> || <code>9C</code> || Push 32-bit E[[FLAGS register]] onto stack || <code>PUSHF</code>
| rowspan="3" {{yes2|Usually 3{{efn|The <code>PUSHFD</code> and <code>POPFD</code> instructions will cause a #GP exception if executed in [[virtual 8086 mode]] if IOPL is not 3.<br />The <code>PUSHF</code>, <code>POPF</code>, <code>IRET</code> and <code>IRETD</code> instructions will cause a #GP exception if executed in Virtual-8086 mode if IOPL is not 3 and VME is not enabled.}}}}
|-
| <code>POPFD</code> || <code>9D</code> || Pop 32-bit EFLAGS register off stack || <code>POPF</code>
|-
| <code>IRETD</code> || <code>CF</code> || 32-bit interrupt return. Differs from the older 16-bit <code>IRET</code> instruction in that it will pop interrupt return items (EIP,CS,EFLAGS; also ESP{{efn|text=If <code>IRETD</code> is used to return from kernel mode to user mode (which will entail a CPL change) and the user-mode stack [[x86 memory segmentation|segment]] indicated by SS is a 16-bit segment, then the <code>IRETD</code> 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 <code>IRETD</code>. This has necessitated complex workarounds on both Linux ("ESPFIX")<ref>LKML, [https://lkml.org/lkml/2014/4/29/626 (PATCH) x86-64, espfix: Don't leak bits 31:16 of %esp returning to 16-bit stack], Apr 29, 2014. [https://web.archive.org/web/20180104155340/https://lkml.org/lkml/2014/4/29/626 Archived] on Jan 4, 2018</ref> and Windows.<ref>Raymond Chen, [https://devblogs.microsoft.com/oldnewthing/20160404-00/?p=93261 Getting MS-DOS games to run on Windows 95: Working around the iretd problem], Apr 4, 2016. [https://web.archive.org/web/20190315174141/https://devblogs.microsoft.com/oldnewthing/20160404-00/?p=93261 Archived] on Mar 15, 2019</ref> This issue also affects the later 64-bit <code>IRETQ</code> instruction.}} and SS if there is a [[Privilege level|CPL]] change; and also ES,DS,FS,GS if returning to [[virtual 8086 mode]]) off the stack as 32-bit items instead of 16-bit items. Should be used to return from interrupts when the interrupt handler was entered through a 32-bit [[Interrupt descriptor table|IDT]] interrupt/trap gate.
Instruction is serializing.
| <code>IRET</code>
|}
{{notelist}}

{{sticky header}}
{| class="wikitable sortable sticky-header"
|+ 80386: new opcodes introduced
! Instruction mnemonics !! Opcode !! Description !! [[Protection ring|Ring]]
|-
| <code>BT r/m, r</code> || <code>0F A3 /r</code> || rowspan="2" | [[Bit Test]].{{efn|name=bt_offsetting|text=For the <code>BT</code>, <code>BTS</code>, <code>BTR</code> and <code>BTC</code> 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.}}
Second operand specifies which bit of the first operand to test. The bit to test is copied to [[FLAGS register|EFLAGS]].[[Carry flag|CF]].
| rowspan="8" {{yes|3}}
|-
| <code>BT r/m, imm8</code> || <code>0F BA /4 ''ib''</code>
|-
| <code>BTS r/m, r</code> || <code>0F AB /r</code> || rowspan="2" | Bit [[Test-and-set]].{{efn|name=bt_offsetting}}{{efn|name=bt_atomic|text=The <code>BTS</code>, <code>BTC</code> and <code>BTR</code> instructions accept the <code>LOCK</code> (<code>F0</code>) prefix when used with a memory argument – this results in the instruction executing atomically.}}
Second operand specifies which bit of the first operand to test and set.
|-
| <code>BTS r/m, imm8</code> || <code>0F BA /5 ''ib''</code>
|-
| <code>BTR r/m, r</code> || <code>0F B3 /r</code> || rowspan="2" | Bit Test and Reset.{{efn|name=bt_offsetting}}{{efn|name=bt_atomic}}
Second operand specifies which bit of the first operand to test and clear.
|-
| <code>BTR r/m, imm8</code> || <code>0F BA /6 ''ib''</code>
|-
| <code>BTC r/m, r</code> || <code>0F BB /r</code> || rowspan="2" | Bit Test and Complement.{{efn|name=bt_offsetting}}{{efn|name=bt_atomic}}
Second operand specifies which bit of the first operand to test and toggle.
|-
| <code>BTC r/m, imm8</code> || <code>0F BA /7 ''ib''</code>
|-
! colspan="4" |
|-
| <code>BSF r, r/m</code> || {{nowrap|<code>NFx 0F BC /r</code>{{efn|If the <code>F3</code> prefix is used with the {{nowrap|<code>0F BC /r</code>}} opcode, then the instruction will execute as <code>TZCNT</code> on systems that support the BMI1 extension. <code>TZCNT</code> differs from <code>BSF</code> in that <code>TZCNT</code> but not <code>BSR</code> 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).}}}}|| [[Find first set|Bit scan]] forward. Returns bit index of lowest set bit in input.{{efn|name=bsf_bsr_zero|text=<code>BSF</code> and <code>BSR</code> set the EFLAGS.ZF flag to 1 if the source argument was all-0s and 0 otherwise.<br />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.}}
| rowspan="6" {{yes|3}}
|-
| <code>BSR r, r/m</code> || {{nowrap|<code>NFx 0F BD /r</code>{{efn|If the <code>F3</code> prefix is used with the {{nowrap|<code>0F BD /r</code>}} opcode, then the instruction will execute as <code>LZCNT</code> on systems that support the ABM or LZCNT extensions. <code>LZCNT</code> produces a different result from <code>BSR</code> for most input values.}}}} || [[Find first set|Bit scan]] reverse. Returns bit index of highest set bit in input.{{efn|name=bsf_bsr_zero}}
|-
| <code>SHLD r/m, r, imm8</code> || <code>0F A4 /r ''ib''</code> || rowspan="2" | Shift Left Double.<br />The operation of <code>SHLD arg1,arg2,shamt</code> is:<br /><code>arg1 := (arg1<<shamt) | (arg2>>(operand_size - shamt))</code>{{efn|name=shld_shamt|text=For <code>SHLD</code> and <code>SHRD</code>, 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.<br /><code>SHLD</code> and <code>SHRD</code> 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.<ref>sandpile.org, [https://www.sandpile.org/x86/flags.htm x86 architecture rFLAGS register], see note #7. [https://web.archive.org/web/20111103093624/https://www.sandpile.org/x86/flags.htm Archived] on 3 Nov 2011.</ref>)}}
|-
| <code>SHLD r/m, r, CL</code> || <code>0F A5 /r</code>
|-
| {{nowrap|<code>SHRD r/m, r, imm8</code>}} || {{nowrap|<code>0F AC /r ''ib''</code>}} || rowspan="2" | Shift Right Double.<br />The operation of <code>SHRD arg1,arg2,shamt</code> is:<br /><code>arg1 := (arg1>>shamt) | (arg2<<(operand_size - shamt))</code>{{efn|name=shld_shamt}}
|-
| <code>SHRD r/m, r, CL</code> || <code>0F AD /r</code>
|-
! colspan="4" |
|-
| <code>MOVZX reg, r/m8</code> || <code>0F B6 /r</code> || rowspan="2" | Move from 8/16-bit source to 16/32-bit register with zero-extension.
| rowspan="7" {{yes|3}}
|-
| <code>MOVZX reg, r/m16</code> || <code>0F B7 /r</code>
|-
| <code>MOVSX reg, r/m8</code> || <code>0F BE /r</code> || rowspan="2" | Move from 8/16-bit source to 16/32/64-bit register with [[sign-extension]].
|-
| <code>MOVSX reg, r/m16</code> || <code>0F BF /r</code>
|-
| <code>SETcc r/m8</code>
| {{nowrap|<code>0F 9x /0</code>}}{{efn|name=setcc_conds|text=The condition codes supported for the <code>SET'''cc'''</code> and <code>J'''cc''' near</code> instructions (opcodes <code>0F 9'''x''' /0</code> and <code>0F 8'''x'''</code> respectively, with the '''x''' nibble specifying the condition) are:
{{(!}} class="wikitable sortable"
! x !! cc !! Condition ([[FLAGS register|EFLAGS]])
{{!}}-
{{!}} 0 {{!!}} O {{!!}} OF=1: "Overflow"
{{!}}-
{{!}} 1 {{!!}} NO {{!!}} OF=0: {{nowrap|"Not Overflow"}}
{{!}}-
{{!}} 2 {{!!}} C,B,NAE {{!!}} CF=1: "Carry", "Below", {{nowrap|"Not Above or Equal"}}
{{!}}-
{{!}} 3 {{!!}} NC,NB,AE {{!!}} CF=0: {{nowrap|"Not Carry"}}, {{nowrap|"Not Below"}}, {{nowrap|"Above or Equal"}}
{{!}}-
{{!}} 4 {{!!}} Z,E {{!!}} ZF=1: "Zero", "Equal"
{{!}}-
{{!}} 5 {{!!}} NZ,NE {{!!}} ZF=0: {{nowrap|"Not Zero"}}, {{nowrap|"Not Equal"}}
{{!}}-
{{!}} 6 {{!!}} NA,BE {{!!}} (CF=1 or ZF=1): {{nowrap|"Not Above"}}, {{nowrap|"Below or Equal"}}
{{!}}-
{{!}} 7 {{!!}} A,NBE {{!!}} (CF=0 and ZF=0): "Above", {{nowrap|"Not Below or Equal"}}
{{!}}-
{{!}} 8 {{!!}} S {{!!}} SF=1: "Sign"
{{!}}-
{{!}} 9 {{!!}} NS {{!!}} SF=0: {{nowrap|"Not Sign"}}
{{!}}-
{{!}} A {{!!}} P,PE {{!!}} PF=1: "Parity", {{nowrap|"Parity Even"}}
{{!}}-
{{!}} B {{!!}} NP,PO {{!!}} PF=0: {{nowrap|"Not Parity"}}, {{nowrap|"Parity Odd"}}
{{!}}-
{{!}} C {{!!}} L,NGE {{!!}} SF≠OF: "Less", {{nowrap|"Not Greater Or Equal"}}
{{!}}-
{{!}} D {{!!}} NL,GE {{!!}} SF=OF: {{nowrap|"Not Less"}}, {{nowrap|"Greater Or Equal"}}
{{!}}-
{{!}} E {{!!}} LE,NG {{!!}} (ZF=1 or SF≠OF): {{nowrap|"Less or Equal"}}, {{nowrap|"Not Greater"}}
{{!}}-
{{!}} F {{!!}} NLE,G {{!!}} (ZF=0 and SF=OF): {{nowrap|"Not Less or Equal"}}, {{nowrap|"Greater"}}
{{!)}}
}}{{efn|text=For <code>SETcc</code>, 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 <code>SETcc</code> regardless of the contents of these bits.}}
| Set byte to 1 if condition is satisfied, 0 otherwise.
|-
| <code>Jcc ''rel16''</code><br /><code>Jcc ''rel32''</code>
| <code>0F 8x ''cw''</code><br /><code>0F 8x ''cd''</code>{{efn|name=setcc_conds}}
| Conditional jump near.
Differs from older variants of conditional jumps in that they accept a 16/32-bit offset rather than just an 8-bit offset.
|-
| <code>IMUL r, r/m</code> || <code>0F AF /r</code> || Two-operand non-widening integer multiply.
|-
! colspan="4" |
|-
| <code>FS:</code> || <code>64</code> || rowspan="2" | Segment-override prefixes for FS and GS segment registers.
| rowspan="9" {{yes|3}}
|-
| <code>GS:</code> || <code>65</code>
|-
| <code>PUSH FS</code> || <code>0F A0</code> || rowspan="4" | Push/pop FS and GS segment registers.
|-
| <code>POP FS</code> || <code>0F A1</code>
|-
| <code>PUSH GS</code> || <code>0F A8</code>
|-
| <code>POP GS</code> || <code>0F A9</code>
|-
| <code>LFS r16, m16&16</code><br /><code>LFS r32, m32&16</code> || <code>0F B4 /r</code> || rowspan="3" | Load [[far pointer]] from memory.
Offset part is stored in destination register argument, segment part in FS/GS/SS segment register as indicated by the instruction mnemonic.{{efn|For <code>LFS</code>, <code>LGS</code> and <code>LSS</code>, 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 <code>REX.W</code> prefix with these instructions will cause them to load a [[far pointer]] with a 64-bit offset on Intel but not AMD processors.}}
|-
| <code>LGS r16, m16&16</code><br />{{nowrap|<code>LGS r32, m32&16</code>}} || <code>0F B5 /r</code>
|-
| <code>LSS r16, m16&16</code><br />{{nowrap|<code>LSS r32, m32&16</code>}} || <code>0F B2 /r</code>
|-
! colspan="4" |
|-
| <code>MOV reg,CRx</code> || <code>0F 20 /r</code>{{efn|name=movcr_modrm|text=For <code>MOV</code> to/from the <code>CRx</code>, <code>DRx</code> and <code>TRx</code> registers, the reg part of the [[ModR/M]] byte is used to indicate <code>CRx/DRx/TRx</code> register and r/m part the general-register.

Uniquely for the {{nowrap|<code>MOV CRx/DRx/TRx</code>}} 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 <code>11b</code>.}} || Move from [[control register]] to general register.{{efn|name=movcr_opsiz|For moves to/from the <code>CRx</code> and <code>DRx</code> registers, the operand size is always 64 bits in 64-bit mode and 32 bits otherwise.}}
| rowspan="6" {{no|0}}
|-
| <code>MOV CRx,reg</code> || <code>0F 22 /r</code>{{efn|name=movcr_modrm}} || Move from general register to control register.{{efn|name=movcr_opsiz}}
Moves to the <code>CR3</code> control register are serializing and will flush the [[Translation lookaside buffer|TLB]].{{efn|On processors that support global pages (Pentium and later), global page table entries will not be flushed by a <code>MOV</code> to <code>CR3</code> − instead, these entries can be flushed by toggling the CR4.PGE bit.<br/>On processors that support [[Process-context identifier|PCID]]s, 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 <code>INVPCID</code> instruction.}}

On Pentium and later processors, moves to the <code>CR0</code> and <code>CR4</code> control registers are also serializing.{{efn|On processors prior to [[Pentium (original)|Pentium]], moves to <code>CR0</code> would not serialize the instruction stream – in part for this reason, it is usually required to perform a far jump<ref>iPXE, [https://github.com/ipxe/ipxe/commit/bc35b24e3ebd2996b2484b7f9ceb96a3cf25823a Commit bc35b24: Fix use of writable code segment on 486 and earlier CPUs], ''Github'', Feb 2, 2022 − indicates that when leaving protected mode on 386/486 by writing to <code>CR0</code>, it is specifically necessary to do a far <code>JMP</code> (opcode <code>EA</code>) in order to restore proper real-mode access-rights for the CS segment, and that other far control transfers (e.g. <code>RETF</code>, <code>IRET</code>) will not do this. [https://web.archive.org/web/20241104213948/https://github.com/ipxe/ipxe/commit/bc35b24e3ebd2996b2484b7f9ceb96a3cf25823a Archived] on 4 Nov 2024.</ref> immediately after a <code>MOV</code> to <code>CR0</code> if such a <code>MOV</code> is used to enable/disable [[protected mode]] and/or [[memory paging]].<br /><code>MOV</code> to <code>CR2</code> is architecturally listed as serializing, but has been reported to be {{nowrap|non-serializing}} on at least some Intel Core-i7 processors.<ref>Can Bölük, [https://blog.can.ac/2021/03/22/speculating-x86-64-isa-with-one-weird-trick/ Speculating the entire x86-64 Instruction Set In Seconds with This One Weird Trick], Mar 22, 2021. [https://web.archive.org/web/20210323035913/https://blog.can.ac/2021/03/22/speculating-x86-64-isa-with-one-weird-trick/ Archived] on Mar 23, 2021.</ref><br /><code>MOV</code> to <code>CR8</code> (introduced with x86-64) is serializing on AMD but not Intel processors.}}
|-
| <code>MOV reg,DRx</code> || <code>0F 21 /r</code>{{efn|name=movcr_modrm}} || Move from [[x86 debug register]] to general register.{{efn|name=movcr_opsiz}}
|-
| <code>MOV DRx,reg</code> || <code>0F 23 /r</code>{{efn|name=movcr_modrm}} || Move from general register to x86 debug register.{{efn|name=movcr_opsiz}}
On Pentium and later processors, moves to the DR0-DR7 debug registers are serializing.
|-
| <code>MOV reg,TRx</code> || <code>0F 24 /r</code>{{efn|name=movcr_modrm}} || Move from x86 [[test register]] to general register.{{efn|name=movtr_pent|The <code>MOV TRx</code> instructions were discontinued from Pentium onwards.}}
|-
| <code>MOV TRx,reg</code> || <code>0F 26 /r</code>{{efn|name=movcr_modrm}} || Move from general register to x86 test register.{{efn|name=movtr_pent}}
|-
! colspan="4" |
|-
| {{unofficial2|align="left"|{{mono|&nbsp;ICEBP,<br />&nbsp;INT01,<br />&nbsp;INT1{{efn|The <code>INT1</code>/<code>ICEBP</code> (<code>F1</code>) instruction is present on all known Intel x86 processors from the 80386 onwards,<ref name="rcollins_undoc" /> but only fully documented for Intel processors from the May 2018 release of the Intel SDM (rev 067) onwards.<ref>Michal Necasek, [https://www.os2museum.com/wp/icebp-finally-documented/ ICEBP finally documented], ''OS/2 Museum'', May 25, 2018. [https://web.archive.org/web/20180606211954/https://www.os2museum.com/wp/icebp-finally-documented/ Archived] on 6 June 2018</ref> Before this release, mention of the instruction in Intel material was sporadic, e.g.  AP-526 rev 001.<ref name="intel_ap526_001">Intel, [https://web.archive.org/web/19961222093646/http://www.intel.com/design/pro/applnots/24281601.pdf AP-526: Optimization For Intel's 32-bit Processors], order no. 242816-001, october 1995 – lists <code>SALC</code> on page 83, <code>INT1</code> on page 86 and <code>FFREEP</code> on page 114. Archived from the [http://www.intel.com/design/pro/applnots/24281601.pdf original] on 22 Dec 1996.</ref><br />For AMD processors, the instruction has been documented since 2002.<ref>AMD, [https://kib.kiev.ua/x86docs/AMD/AMD64/24593_APM_v2-r3.06.pdf AMD 64-bit Technology, vol 2: System Programming], order no. 24593, rev 3.06, aug 2002, page 248</ref>}}}}}}
| {{unofficial2|align="left"|{{mono|&nbsp;F1}}}}
| [[In-circuit emulation]] breakpoint.

Performs software interrupt #1 if executed when not using in-circuit emulation.{{efn|text=The operation of the <code>F1</code>(<code>ICEBP</code>) opcode differs from the operation of the regular software interrupt opcode {{nowrap|<code>CD 01</code>}} in several ways:<ul>In protected mode, {{nowrap|<code>CD 01</code>}} will check CPL against the interrupt descriptor's DPL field as an access-rights check, while <code>F1</code> will not.<li>In virtual-8086 mode, {{nowrap|<code>CD 01</code>}} will also check CPL against IOPL as an access-rights check, while <code>F1</code> will not.<li>In virtual-8086 mode with VME enabled, interrupt redirection is supported for {{nowrap|<code>CD 01</code>}} but not <code>F1</code>.</ul>}}
| rowspan="7" {{yes|3}}
|-
| {{unofficial2|align="left"|{{mono|&nbsp;UMOV r/m, r8}}}}
| {{unofficial2|align="left"|{{mono|&nbsp;0F 10 /r}}}}
| rowspan="4" | User Move – perform data moves that can access user memory while in In-circuit emulation HALT mode.

Performs same operation as <code>MOV</code> if executed when not doing in-circuit emulation.{{efn|text=The UMOV instruction is present on 386 and 486 processors only.<ref name="rcollins_undoc">Robert Collins, [http://www.rcollins.org/secrets/OpCodes.html Undocumented OpCodes], 29 july 1995. [https://web.archive.org/web/20010221221019/http://www.rcollins.org/secrets/OpCodes.html Archived] on 21 feb 2001</ref>}}
|-
| {{unofficial2|align="left"|{{mono|&nbsp;UMOV r/m, r16/32}}}}
| {{unofficial2|align="left"|{{mono|&nbsp;0F 11 /r}}}}
|-
| {{unofficial2|align="left"|{{mono|&nbsp;UMOV r8, r/m}}}}
| {{unofficial2|align="left"|{{mono|&nbsp;0F 12 /r}}}}
|-
| {{unofficial2|align="left"|{{mono|&nbsp;UMOV r16/32, r/m}}}}
| {{unofficial2|align="left"|{{mono|&nbsp;0F 13 /r}}}}

|-
| {{unofficial2|align="left"|{{mono|&nbsp;XBTS reg,r/m}}}}
| {{unofficial2|align="left"|{{mono|&nbsp;0F A6 /r}}}}
| Bitfield extract (early 386 only).{{efn|name=xbts_discon|The <code>XBTS</code> and <code>IBTS</code> instructions were discontinued with the B1 stepping of 80386.<br />
They have been used by software mainly for detection of the buggy<ref>{{Cite web|url=https://www.pcjs.org/documents/manuals/intel/80386/#b0-stepping|title=Intel 80386 CPU Information &#124; PCjs Machines|website=www.pcjs.org}}</ref> B0 stepping of the 80386. Microsoft Windows (v2.01 and later) will attempt to run the <code>XBTS</code> instruction as part of its CPU detection if <code>CPUID</code> is not present, and will refuse to boot if <code>XBTS</code> is found to be working.<ref>Geoff Chappell, [https://www.geoffchappell.com/studies/windows/km/cpu/precpuid.htm?tx=245 CPU Identification before CPUID], 27 Jan 2020. [https://web.archive.org/web/20220407203913/https://www.geoffchappell.com/studies/windows/km/cpu/precpuid.htm?tx=245 Archived] on 7 Apr 2023.</ref>}}{{efn|name=xbts_op|text=For <code>XBTS</code> and <code>IBTS</code>, 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.<ref>Jeff Parsons, [https://www.pcjs.org/documents/manuals/intel/80386/ibts_xbts/ Obsolete 80386 Instructions: IBTS and XBTS], ''PCjs Machines''. [https://web.archive.org/web/20200919154722/https://www.pcjs.org/documents/manuals/intel/80386/ibts_xbts/ Archived] on Sep 19, 2020.</ref>}}
|-
| {{unofficial2|align="left"|{{mono|&nbsp;IBTS r/m,reg}}}}
| {{unofficial2|align="left"|{{mono|&nbsp;0F A7 /r}}}}
| Bitfield insert (early 386 only).{{efn|name=xbts_discon}}{{efn|name=xbts_op}}
|-
| {{unofficial2|align="left"|{{mono|&nbsp;[[LOADALL]]D,<br />&nbsp;LOADALL386}}{{efn|name=i386_loadall|Undocumented, 80386 only.<ref>Robert Collins, [https://web.archive.org/web/19970605213204/http://www.x86.org/articles/loadall/tspec_a3_doc.html The LOADALL Instruction]. Archived from the [http://www.x86.org/articles/loadall/tspec_a3_doc.html original] on Jun 5, 1997.</ref>}}}}
| {{unofficial2|align="left"|{{mono|&nbsp;0F 07}}}}
| Load all CPU registers from a 296-byte data structure starting at ES:EDI, including "hidden" part of segment descriptor registers.
| {{no|0}}
|}
{{notelist}}

==== Added with [[80486]] ====

{| class="wikitable sortable"
! Instruction !! Opcode !! Description !! [[Protection ring|Ring]]
|-
| <code>BSWAP r32</code>
| {{nowrap|<code>0F C8+r</code>}}
| Byte Order Swap. Usually used to convert between big-endian and little-endian data representations. For 32-bit registers, the operation performed is:<pre>
r =   (r << 24)
    | ((r << 8) & 0x00FF0000)
    | ((r >> 8) & 0x0000FF00)
    | (r >> 24);</pre>
Using <code>BSWAP</code> with a 16-bit register argument produces an undefined result.{{efn|text=Using <code>BSWAP</code> 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,<ref name="toth-19980316">{{cite web|url=http://www.df.lth.se/~john_e/gems/gem000c.html|archive-url=https://web.archive.org/web/19991103025640/http://www.df.lth.se/~john_e/gems/gem000c.html|url-status=dead|archive-date=1999-11-03|title=BSWAP with 16-bit registers|first=Ervin|last=Toth|date=1998-03-16|quote=The instruction brings down the upper word of the doubleword register without affecting its upper 16 bits.}}</ref> 586, and [[Bochs]]/[[QEMU]].<ref name="coldwin-20091229">{{cite web|url=https://gynvael.coldwind.pl/?id=268|title=BSWAP + 66h prefix|first=Gynvael|last=Coldwin|date=2009-12-29|access-date=2018-10-03|quote=internal (zero-)extending the value of a smaller (16-bit) register … applying the bswap to a 32-bit value "00 00 AH AL", … truncated to lower 16-bits, which are "00 00".  … Bochs … bswap reg16 acts just like the bswap reg32 … QEMU … ignores the 66h prefix}}</ref>}}
| rowspan="5" {{yes|3}}
|-
| <code>CMPXCHG r/m8,r8</code>
| {{nowrap|<code>0F B0 /r</code>{{efn|name=i486_cmpxchg|text=On Intel 80486 stepping A,<ref>Intel [https://www.ardent-tool.com/CPU/docs/Intel/486/datasheets/240440-001.pdf "i486 Microprocessor"] (April 1989, order no. 240440-001) p.142 lists <code>CMPXCHG</code> with {{nowrap|<code>0F A6/A7</code>}} encodings.</ref> the <code>CMPXCHG</code> instruction uses a different encoding - {{nowrap|<code>0F A6 /r</code>}} for 8-bit variant, {{nowrap|<code>0F A7 /r</code>}} for 16/32-bit variant. The {{nowrap|<code>0F B0/B1</code>}} encodings are used on 80486 stepping B and later.<ref>Intel [https://www.ardent-tool.com/CPU/docs/Intel/486/datasheets/240440-002.pdf "i486 Microprocessor"] (November 1989, order no. 240440-002) p.135 lists <code>CMPXCHG</code> with {{nowrap|<code>0F B0/B1</code>}} encodings.</ref><ref>{{Cite web|url=http://datasheets.chipdb.org/Intel/x86/486/Intel486.htm|title = Intel 486 & 486 POD CPUID, S-spec, & Steppings}}</ref>}}}}
| rowspan="2" | [[Compare-and-swap|Compare and Exchange]]. If accumulator (AL/AX/EAX/RAX) compares equal to first operand,{{efn|The <code>CMPXCHG</code> instruction sets <code>EFLAGS</code> in the same way as a <code>CMP</code> instruction that uses the accumulator (AL/AX/EAX/RAX) as its first argument would do.}} then <code>EFLAGS.ZF</code> is set to 1 and the first operand is overwritten with the second operand. Otherwise, <code>EFLAGS.ZF</code> is set to 0, and first operand is copied into the accumulator.
Instruction atomic only if used with <code>LOCK</code> prefix.
|-
| {{nowrap|<code>CMPXCHG r/m,r16</code>}}<br />{{nowrap|<code>CMPXCHG r/m,r32</code>}}
| {{nowrap|<code>0F B1 /r</code>{{efn|name=i486_cmpxchg}}}}
|-
| <code>XADD r/m,r8</code>
| {{nowrap|<code>0F C0 /r</code>}}
| rowspan="2" | [[Fetch-and-add|eXchange and ADD]]. Exchanges the first operand with the second operand, then stores the sum of the two values into the destination operand.
Instruction atomic only if used with <code>LOCK</code> prefix.
|-
| <code>XADD r/m,r16</code><br /><code>XADD r/m,r32</code>
| <code>0F C1 /r</code>
|-
| <code>INVLPG m8</code>
| {{nowrap|<code>0F 01 /7</code>}}
| Invalidate the [[Translation lookaside buffer|TLB]] entries that would be used for the 1-byte memory operand.{{efn|<code>INVLPG</code> executes as no-operation if the m8 argument is invalid (e.g. unmapped page or non-canonical address).<br /><code>INVLPG</code> can be used to invalidate TLB entries for individual global pages.}}
Instruction is serializing.
| rowspan="3" {{no|0}}
|-
| <code>INVD</code>
| <code>0F 08</code>
| Invalidate Internal Caches.{{efn|name=invd_scope|text=The <code>INVD</code> and <code>WBINVD</code> 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.<br />These instructions are serializing – on some processors, they may block interrupts until completion as well.}} Modified data in the cache are not written back to memory, potentially causing data loss.{{efn|text=Under [[Intel VT-x]] virtualization, the <code>INVD</code> 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 <code>INVD</code> instruction is not permitted and will cause a #GP(0) exception.<ref>Intel, [https://www.intel.com/content/dam/develop/external/us/en/documents/329298-002-629101.pdf Software Guard Extensions Programming Reference], order no. 329298-002, oct 2014, sections 3.5 and 3.6.5.</ref>}}
|-
| <code>WBINVD</code>
| {{nowrap|<code>NFx 0F 09</code>{{efn|If the <code>F3</code> prefix is used with the <code>0F 09</code> opcode, then the instruction will execute as <code>WBNOINVD</code> on processors that support the WBNOINVD extension – this will not invalidate the cache.}}}}
| Write Back and Invalidate Cache.{{efn|name=invd_scope}} Writes back all modified cache lines in the processor's internal cache to main memory and invalidates the internal caches.
|}
{{notelist}}{{vpad}}

==== Added in [[Pentium (original)|P5]]/[[P6 (microarchitecture)|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. ([[List of discontinued x86 instructions|Discontinued instructions]] are not included.)

{{sticky header}}
{| class="wikitable sortable sticky-header"
! Instruction !! Opcode !! Description !! [[Protection ring|Ring]] !! Added in
|-
! colspan="5" |
|-
| <code>RDMSR</code>
| <code>0F 32</code>
| Read [[Model-specific register]]. The MSR to read is specified in ECX. The value of the MSR is then returned as a 64-bit value in EDX:EAX.{{efn|name="p5rd_clear_hi32"|1=In 64-bit mode, the <code>RDMSR</code>, <code>RDTSC</code> and <code>RDPMC</code> instructions will set the top 32 bits of RDX and RAX to zero.}}
| rowspan="2" {{no|0}}
| rowspan="2" | IBM [[IBM 386SLC|386SLC]],<ref>Frank van Gilluwe, "The Undocumented PC, second edition", 1997, {{ISBN|0-201-47950-8}}, page 55</ref><br />Intel [[Pentium (original)|Pentium]],<br />AMD [[AMD K5|K5]],<br />{{nowrap|Cyrix [[Cyrix 6x86|6x86MX]],[[MediaGX]]m,}}<br />IDT [[WinChip]] C6,<br />Transmeta [[Transmeta Crusoe|Crusoe]],<br />DM&P [[Vortex86]]DX3
|-
| <code>WRMSR</code>
| <code>0F 30</code>
| Write [[Model-specific register]]. The MSR to write is specified in ECX, and the data to write is given in EDX:EAX.{{efn|On Intel and AMD CPUs, the <code>WRMSR</code> instruction is also used to update the [[Intel Microcode#Update facility|CPU microcode]]. This is done by writing the virtual address of the new microcode to upload to MSR <code>79h</code> on Intel CPUs and MSR <code>C001_0020h</code><ref>AMD, [https://www.amd.com/content/dam/amd/en/documents/archived-tech-docs/revision-guides/25759.pdf Revision Guide for AMD Athlon 64 and AMD Opteron Processors] pub.no. 25759, rev 3.79, July 2009, page 34. [https://web.archive.org/web/20231220133454/https://www.amd.com/content/dam/amd/en/documents/archived-tech-docs/revision-guides/25759.pdf Archived] on 20 Dec 2023.</ref> on AMD CPUs.}}

Instruction is, with some exceptions, serializing.{{efn|text=Writes to the following MSRs are not serializing:<ref>Intel, [http://kib.kiev.ua/x86docs/Intel/SDMs/253668-078.pdf Software Developer’s Manual, vol 3A], order no. 253668-078, Dec 2022, section 9.3, page 299.</ref><ref>Intel, [https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/cpuid-enumeration-and-architectural-msrs.html CPUID Enumeration and Architectural MSRs], 8 Aug 2023. [https://web.archive.org/web/20240523214955/https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/cpuid-enumeration-and-architectural-msrs.html Archived] on 23 May 2024.</ref>
{{(!}} class="wikitable sortable"
! Number !! Name
{{!}}-
{{!}} <code>48h</code> {{!!}} SPEC_CTRL
{{!}}-
{{!}} <code>49h</code> {{!!}} PRED_CMD
{{!}}-
{{!}} <code>10Bh</code> {{!!}} FLUSH_CMD
{{!}}-
{{!}} <code>122h</code> {{!!}} TSX_CTRL
{{!}}-
{{!}} <code>6E0h</code> {{!!}} TSC_DEADLINE
{{!}}-
{{!}} <code>6E1h</code> {{!!}} PKRS
{{!}}-
{{!}} <code>774h</code> {{!!}} HWP_REQUEST<br />(non-serializing only if the FAST_IA32_&shy;HWP_REQUEST bit it set)
{{!}}-
{{!}} <code>802h</code> to <code>83Fh</code> {{!!}} (x2APIC MSRs)
{{!}}-
{{!}} <code>1B01h</code> {{!!}} UARCH_MISC_CTL
{{!}}-
{{!}} <code>C001_0100h</code> {{!!}} FS_BASE (non-serializing on AMD [[Zen 4]] and later)<ref name="amd_56713_p116">AMD, [https://www.amd.com/system/files/TechDocs/56713-B1_3.05.zip PPR for AMD Family 19h Model 61h, Revision B1 processors], document no. 56713, rev 3.05, mar 8 2023, page 116. [https://web.archive.org/web/20230425231817/https://www.amd.com/system/files/TechDocs/56713-B1_3.05.zip Archived] on Apr 25, 2023.</ref>
{{!}}-
{{!}} <code>C001_0101h</code> {{!!}} GS_BASE ([[Zen 4]] and later)
{{!}}-
{{!}} <code>C001_0102h</code> {{!!}} KernelGSbase ([[Zen 4]] and later)
{{!}}-
{{!}} <code>C001_011Bh</code> {{!!}} Doorbell Register (AMD-specific)
{{!)}}
<code>WRMSR</code> to the x2APIC ICR (Interrupt Command Register; MSR <code>830h</code>) is commonly used to produce an IPI ([[Inter-processor interrupt]]) - on Intel<ref>https://lkml.org/lkml/2021/2/8/1118</ref> but not AMD<ref>Linux kernel, [https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?h=x86/cpu&id=04c3024560d3a14acd18d0a51a1d0a89d29b7eb5 git commit: x86/barrier: Do not serialize MSR accesses on AMD], 13 Nov 2023</ref> CPUs, such an IPI can be reordered before an older memory store.
}}
|-
| <code>RSM</code><ref>{{cite web|url=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|title=RSM—Resume from System Management Mode|url-status=dead |archive-url=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|archive-date=2012-03-12}}</ref>
| <code>0F AA</code>
| Resume from [[System Management Mode]].

Instruction is serializing.
| {{n/a|-2<br />(SMM)}}
| {{nowrap|Intel 386SL,<ref>Microprocessor Report, [http://www.cecs.uci.edu/~papers/mpr/MPR/ARTICLES/060805.PDF System Management Mode Explained] (vol 6, no. 8, june 17, 1992). [https://web.archive.org/web/20220629220530/https://www.cecs.uci.edu/~papers/mpr/MPR/ARTICLES/060805.PDF Archived] on Jun 29, 2022.</ref><ref>Ellis, Simson C., "The 386 SL Microprocessor in Notebook PCs", Intel Corporation, Microcomputer Solutions, March/April 1991, page 20</ref> [[Intel 80486SL|486SL]],{{efn|[[System Management Mode]] and the <code>RSM</code> instruction were made available on non-SL variants of the Intel 486 only after the initial release of the Intel Pentium in 1993.}}}}<br />Intel [[Pentium (original)|Pentium]],<br />AMD [[AMD 5x86|5x86]],<br />Cyrix [[Cyrix Cx486SLC|486SLC]]/e,<ref name="cx486slce">[http://www.bitsavers.org/components/cyrix/Cyrix_Cx486SLCe_Data_Sheet_1992.pdf Cyrix 486SLC/e Data Sheet (1992)], section 2.6.4</ref><br />IDT [[WinChip]] C6,<br />Transmeta [[Transmeta Crusoe|Crusoe]],<br />Rise [[mP6]] 
|-
| <code>[[CPUID]]</code>
| <code>0F A2</code>
| CPU Identification and feature information. Takes as input a CPUID leaf index in EAX and, depending on leaf, a sub-index in ECX. Result is returned in EAX,EBX,ECX,EDX.{{efn|On some older 32-bit processors, executing <code>CPUID</code> 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 <code>CPUID</code>.<br />Processors noted to exhibit this behavior include Cyrix MII<ref>Linux 6.3 kernel sources, [https://elixir.bootlin.com/linux/v6.3/source/arch/x86/include/asm/cpuid.h /arch/x86/include/asm/cpuid.h], line 69</ref> and IDT WinChip 2.<ref>gcc-patches mailing list, [https://gcc.gnu.org/pipermail/gcc-patches/2019-May/522177.html CPUID Patch for IDT Winchip], May 21, 2019. [https://web.archive.org/web/20230427201255/https://gcc.gnu.org/pipermail/gcc-patches/2019-May/522177.html Archived] on Apr 27, 2023.</ref><br /><br />In 64-bit mode, <code>CPUID</code> will set the top 32 bits of RAX, RBX, RCX and RDX to zero.}}

Instruction is serializing, and causes a mandatory #VMEXIT under virtualization.

Support for <code>CPUID</code> can be checked by toggling bit 21 of [[FLAGS register|EFLAGS]] (EFLAGS.ID) – if this bit can be toggled, <code>CPUID</code> is present.
| {{yes2|Usually 3{{efn|On some Intel processors starting from [[Ivy Bridge (microarchitecture)|Ivy Bridge]], there exists MSRs that can be used to restrict <code>CPUID</code> to ring 0. Such MSRs are documented for at least Ivy Bridge<ref>Intel, [https://www.intel.com/content/dam/www/public/us/en/documents/application-notes/virtualization-technology-flexmigration-application-note.pdf Intel® Virtualization Technology FlexMigration Application Note] order no. 323850-004, oct 2012, section 2.3.2 on page 12. [https://web.archive.org/web/20141013075554/https://www.intel.com/content/dam/www/public/us/en/documents/application-notes/virtualization-technology-flexmigration-application-note.pdf Archived] on Oct 13, 2014.</ref> and Denverton.<ref>Intel, [https://ru.mouser.com/datasheet/2/612/c3000-family-datasheet-1623704.pdf Atom Processor C3000 Product Family Datasheet] order no. 337018-002, Feb 2018, pages 133, 3808 and 3814. [https://web.archive.org/web/20220209183514/https://ru.mouser.com/datasheet/2/612/c3000-family-datasheet-1623704.pdf Archived] on Feb 9, 2022.</ref><br />The ability to restrict <code>CPUID</code> to ring 0 also exists on AMD processors supporting the "CpuidUserDis" feature ([[Zen 4]] "Raphael" and later).<ref>AMD, [https://kib.kiev.ua/x86docs/AMD/AMD64/24594_APM_v3-r3.34.pdf AMD64 Architecture Programmer’s Manual Volume 3] pub.no. 24594, rev 3.34, oct 2022, p. 165 (entry on <code>CPUID</code> instruction)</ref>}}}}
| Intel [[Pentium (original)|Pentium]],{{efn|name="cpuid_backported"|<code>CPUID</code> is also available on some Intel and AMD 486 processor variants that were released after the initial release of the Intel Pentium.}}<br />AMD [[AMD 5x86|5x86]],{{efn|name="cpuid_backported"}}<br />Cyrix [[Cyrix 5x86|5x86]],{{efn|On the Cyrix 5x86 and 6x86 CPUs, <code>CPUID</code> is not enabled by default and must be enabled through a Cyrix configuration register.}}<br />IDT [[WinChip]] C6,<br />Transmeta [[Transmeta Crusoe|Crusoe]],<br />Rise [[mP6]],<br />NexGen [[NexGen|Nx586]],{{efn|On NexGen CPUs, <code>CPUID</code> is only supported with some system BIOSes. On some NexGen CPUs that do support <code>CPUID</code>, EFLAGS.ID is not supported but EFLAGS.AC is, complicating CPU detection.<ref>Robert Collins, [https://web.archive.org/web/20001218003500/http://www.rcollins.org/ddj/Nov96/Nov96.html CPUID Algorithm Wars], nov 1996. Archived from the [http://www.rcollins.org/ddj/Nov96/Nov96.html original] on dec 18, 2000.</ref>}}<br />UMC [[UMC Green CPU|Green CPU]]
|-
| {{nowrap|<code>CMPXCHG8B m64</code>}}
| {{nowrap|<code>0F C7 /1</code>}}
| [[Compare-and-swap|Compare and Exchange]] 8 bytes. Compares EDX:EAX with m64. If equal, set ZF{{efn|Unlike the older <code>CMPXCHG</code> instruction, the <code>CMPXCHG8B</code> instruction does not modify any [[FLAGS register|EFLAGS]] bits other than ZF.}} and store ECX:EBX into m64. Else, clear ZF and load m64 into EDX:EAX.

Instruction atomic only if used with <code>LOCK</code> prefix.{{efn|{{nowrap|<code>LOCK CMPXCHG8B</code>}} with a register operand (which is an invalid encoding) will, on some Intel [[Pentium (original)|Pentium]] CPUs, cause a [[Halt and Catch Fire (computing)|hang]] rather than the expected #UD exception - this is known as the [[Pentium F00F bug]].}}
| {{yes|3}}
| Intel [[Pentium (original)|Pentium]],<br />AMD [[AMD K5|K5]],<br />Cyrix {{nowrap|[[Cyrix 6x86|6x86L]],[[MediaGX]]m,}}<br />IDT [[WinChip]] C6,{{efn|name="cmpxchg8b_ntbug"|text=On IDT WinChip, Transmeta Crusoe and Rise mP6 processors, the <code>CMPXCHG8B</code> instruction is always supported, however its CPUID bit may be missing. This is a workaround for a bug in Windows NT.<ref>Geoff Chappell, [https://www.geoffchappell.com/studies/windows/km/cpu/cx8.htm CMPXCHG8B Support in the 32-Bit Windows Kernel], 23 jan 2008. [https://web.archive.org/web/20231105001739/https://www.geoffchappell.com/studies/windows/km/cpu/cx8.htm Archived] on 5 Nov 2023.</ref>}}<br />Transmeta [[Transmeta Crusoe|Crusoe]],{{efn|name="cmpxchg8b_ntbug"}}<br />Rise [[mP6]]{{efn|name="cmpxchg8b_ntbug"}}
|-
| <code>RDTSC</code>
| <code>0F 31</code>
| Read 64-bit [[Time Stamp Counter]] (TSC) into EDX:EAX.{{efn|name="rdtsc_pmc_unordered"|text=The <code>RDTSC</code> and <code>RDPMC</code> 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 <code>RDPMC</code> (but not <code>RDTSC</code>) may be reordered relative to each other even for reads of the same counter.<br />In order to impose ordering with respect to other instructions, <code>LFENCE</code> or serializing instructions (e.g. <code>CPUID</code>) are needed.<ref name="rdtsc_ordering" />}}{{efn|name="p5rd_clear_hi32"}}

In early processors, the TSC was a cycle counter, incrementing by 1 for each clock cycle (which could cause its rate to vary on processors that could change clock speed at runtime) – in later processors, it increments at a fixed rate that doesn't necessarily match the CPU clock speed.{{efn|text=Fixed-rate TSC was introduced in two stages:{{glossary}}{{term|Constant TSC}}{{defn|TSC running at a fixed rate as long as the processor core is not in a deep-sleep ([[ACPI#Power states|C2]] or deeper) mode, but not synchronized between CPU cores. Introduced in Intel [[Pentium 4#Prescott|Prescott]], [[Yonah (microprocessor)|Yonah]] and [[Bonnell (microarchitecture)|Bonnell]]. Also present in all [[Transmeta]] and [[VIA Nano]]<ref>Linux kernel 5.4.12, [https://elixir.bootlin.com/linux/v5.4.12/source/arch/x86/kernel/cpu/centaur.c#L110 /arch/x86/kernel/cpu/centaur.c]</ref> CPUs. Does not have a CPUID bit.}}{{term|Invariant TSC}}{{defn|TSC running at a fixed rate, and remaining synchronized between CPU cores in all [[ACPI#Power states|P-,C- and T-states]] (but not necessarily S-states).<br />Present in [[AMD K10]] and later; Intel [[Nehalem (microarchitecture)|Nehalem]]/[[Saltwell (microarchitecture)|Saltwell]]<ref>Stack Overflow, [https://stackoverflow.com/questions/62492053/can-constant-non-invariant-tsc-change-frequency-across-cpu-states Can constant non-invariant tsc change frequency across cpu states?] Accessed 24 Jan 2023. [https://web.archive.org/web/20230124204354/https://stackoverflow.com/questions/62492053/can-constant-non-invariant-tsc-change-frequency-across-cpu-states Archived] on 24 Jan 2023.</ref> and later; [[Zhaoxin]] WuDaoKou<ref>CPU-World, [https://www.cpu-world.com/cgi-bin/CPUID.pl?CPUID=81992 CPUID for Zhaoxin KaiXian KX-5000 KX-5650 (by timw4mail)], 24 Apr 2024. [https://web.archive.org/web/20240426121032/https://www.cpu-world.com/cgi-bin/CPUID.pl?CPUID=81992 Archived] on 26 Apr 2024.</ref> and later. Indicated with a CPUID bit (leaf <code>8000_0007:EDX[8]</code>).}}}}
| {{yes2|Usually 3{{efn|text=<code>RDTSC</code> can be run outside Ring 0 only if <code>[[Control_register#CR4|CR4.TSD]]=0</code>.<br />On Intel Pentium and AMD K5, <code>RDTSC</code> cannot be run in Virtual-8086 mode.<ref>Michal Necasek, [http://www.os2museum.com/wp/undocumented-rdtsc/ "Undocumented RDTSC"], 27 Apr 2018. [https://web.archive.org/web/20231216114233/http://www.os2museum.com/wp/undocumented-rdtsc/ Archived] on 16 Dec 2023.</ref> Later processors removed this restriction.}}}}
| Intel [[Pentium (original)|Pentium]],<br />AMD [[AMD K5|K5]],<br />Cyrix {{nowrap|[[Cyrix 6x86|6x86MX]],[[MediaGX]]m,}}<br />IDT [[WinChip]] C6,<br />Transmeta [[Transmeta Crusoe|Crusoe]],<br />Rise [[mP6]]
|-
! colspan="5" |
|-
| <code>RDPMC</code>
| <code>0F 33</code>
| Read [[Performance Monitoring Counter]]. The counter to read is specified by ECX and its value is returned in EDX:EAX.{{efn|name="rdtsc_pmc_unordered"}}{{efn|name="p5rd_clear_hi32"}}
| {{yes2|Usually 3{{efn|text=<code>RDPMC</code> can be run outside Ring 0 only if <code>[[Control_register#CR4|CR4.PCE]]=1</code>.}}}}
| {{nowrap|Intel [[Pentium (original)#MMX|Pentium MMX]],}}<br />Intel [[Pentium Pro]],<br />AMD [[AMD K7|K7]],<br />Cyrix [[Cyrix 6x86|6x86MX]],<br />IDT [[WinChip]] C6,<br />AMD [[Geode (processor)#Geode LX|Geode LX]],<br />VIA [[VIA Nano|Nano]]{{efn|The <code>RDPMC</code> instruction is not present in VIA processors prior to the Nano.}}
|-
| {{nowrap|<code>CMOVcc reg,r/m</code>}}
| {{nowrap|<code>0F 4x /r</code>}}{{efn|text=The condition codes supported for <code>CMOV'''cc'''</code> instruction (opcode <code>0F 4'''x''' /r</code>, with the '''x''' nibble specifying the condition) are:
{{(!}} class="wikitable sortable"
! x !! cc !! Condition ([[FLAGS register|EFLAGS]])
{{!}}-
{{!}} 0 {{!!}} O {{!!}} OF=1: "Overflow"
{{!}}-
{{!}} 1 {{!!}} NO {{!!}} OF=0: {{nowrap|"Not Overflow"}}
{{!}}-
{{!}} 2 {{!!}} C,B,NAE {{!!}} CF=1: "Carry", "Below", {{nowrap|"Not Above or Equal"}}
{{!}}-
{{!}} 3 {{!!}} NC,NB,AE {{!!}} CF=0: {{nowrap|"Not Carry"}}, {{nowrap|"Not Below"}}, {{nowrap|"Above or Equal"}}
{{!}}-
{{!}} 4 {{!!}} Z,E {{!!}} ZF=1: "Zero", "Equal"
{{!}}-
{{!}} 5 {{!!}} NZ,NE {{!!}} ZF=0: {{nowrap|"Not Zero"}}, {{nowrap|"Not Equal"}}
{{!}}-
{{!}} 6 {{!!}} NA,BE {{!!}} (CF=1 or ZF=1): {{nowrap|"Not Above"}}, {{nowrap|"Below or Equal"}}
{{!}}-
{{!}} 7 {{!!}} A,NBE {{!!}} (CF=0 and ZF=0): "Above", {{nowrap|"Not Below or Equal"}}
{{!}}-
{{!}} 8 {{!!}} S {{!!}} SF=1: "Sign"
{{!}}-
{{!}} 9 {{!!}} NS {{!!}} SF=0: {{nowrap|"Not Sign"}}
{{!}}-
{{!}} A {{!!}} P,PE {{!!}} PF=1: "Parity", {{nowrap|"Parity Even"}}
{{!}}-
{{!}} B {{!!}} NP,PO {{!!}} PF=0: {{nowrap|"Not Parity"}}, {{nowrap|"Parity Odd"}}
{{!}}-
{{!}} C {{!!}} L,NGE {{!!}} SF≠OF: "Less", {{nowrap|"Not Greater Or Equal"}}
{{!}}-
{{!}} D {{!!}} NL,GE {{!!}} SF=OF: {{nowrap|"Not Less"}}, {{nowrap|"Greater Or Equal"}}
{{!}}-
{{!}} E {{!!}} LE,NG {{!!}} (ZF=1 or SF≠OF): {{nowrap|"Less or Equal"}}, {{nowrap|"Not Greater"}}
{{!}}-
{{!}} F {{!!}} NLE,G {{!!}} (ZF=0 and SF=OF): {{nowrap|"Not Less or Equal"}}, {{nowrap|"Greater"}}
{{!)}}
}}
| Conditional move to register. The source operand may be either register or memory.{{efn|In 64-bit mode, <code>CMOVcc</code> with a 32-bit operand size will clear the upper 32 bits of the destination register even if the condition is false.<br />For <code>CMOVcc</code> 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 [[X86#APX (Advanced Performance Extensions)|APX]] extension defines a set of new [[EVEX prefix|EVEX]]-encoded variants of <code>CMOVcc</code> that will suppress memory exceptions if the condition is false.)}}
| {{yes|3}}
| Intel [[Pentium Pro]],<br />AMD [[AMD K7|K7]],<br />{{nowrap|Cyrix [[Cyrix 6x86|6x86MX]],[[MediaGX]]m,}}<br />Transmeta [[Transmeta Crusoe|Crusoe]],<br />VIA [[VIA C3#Nehemiah cores|C3 "Nehemiah"]],{{efn|On pre-Nehemiah VIA C3 variants ("Samuel"/"Ezra"), the {{nowrap|<code>reg,reg</code>}} but not {{nowrap|<code>reg,[mem]</code>}} forms of the <code>CMOVcc</code> instructions have been reported to be present as undocumented instructions.<ref>https://lists.openwall.net/linux-kernel/2009/11/10/546</ref>}}<br />DM&P [[Vortex86]]DX3
|-
! colspan="5" |
|-
| <code>NOP r/m</code>,<br /><code>NOPL r/m</code>
| {{nowrap|<code>NFx 0F 1F /0</code>}}{{efn|text=Intel's recommended byte encodings for multi-byte NOPs of lengths 2 to 9 bytes in 32/64-bit mode are (in hex):<ref>Intel, [https://cdrdv2-public.intel.com/821612/248966-Optimization-Reference-Manual-V1-050.pdf Intel 64 and IA-32 Architectures Optimization Reference Manual: Volume 1], order no. 248966-050US, April 2024, section 3.5.1.9, page 119. [https://web.archive.org/web/20240509192742/https://cdrdv2-public.intel.com/821612/248966-Optimization-Reference-Manual-V1-050.pdf Archived] on 9 May 2024.</ref>
{{(!}} class="wikitable sortable"
! Length !! Byte Sequence
{{!}}-
{{!}} 2 {{!!}} <code>66 90</code>
{{!}}-
{{!}} 3 {{!!}} <code>0F 1F 00</code>
{{!}}-
{{!}} 4 {{!!}} <code>0F 1F 40 00</code>
{{!}}-
{{!}} 5 {{!!}} <code>0F 1F 44 00 00</code>
{{!}}-
{{!}} 6 {{!!}} <code>66 0F 1F 44 00 00</code>
{{!}}-
{{!}} 7 {{!!}} <code>0F 1F 80 00 00 00 00</code>
{{!}}-
{{!}} 8 {{!!}} <code>0F 1F 84 00 00 00 00 00</code>
{{!}}-
{{!}} 9 {{!!}} <code>66 0F 1F 84 00 00 00 00 00</code>
{{!)}}
For cases where there is a need to use more than 9 bytes of NOP padding, it is recommended to use multiple NOPs.
}}
| Official long [[NOP (code)|NOP]].

Other than AMD K7/K8, broadly unsupported in non-Intel processors released before 2005.{{efn|Unlike other instructions added in [[Pentium Pro]], long NOP does not have a [[CPUID]] feature bit.}}<ref>JookWiki, [https://www.jookia.org/wiki/Nopl "nopl"], sep 24, 2022 – provides a lengthy account of the history of the long NOP and the issues around it. [https://web.archive.org/web/20221028233225/https://www.jookia.org/wiki/Nopl Archived] on oct 28, 2022.</ref>
| {{yes|3}}
| Intel [[Pentium Pro]],{{efn|text=<code>0F 1F /0</code> as long-NOP was introduced in the Pentium Pro, but remained undocumented until 2006.<ref name="longnop2006">Intel Community: [https://community.intel.com/t5/Software-Archive/Multi-byte-NOP-opcode-made-official/td-p/932580 Multibyte NOP Made Official]. [https://web.archive.org/web/20220407203915/https://community.intel.com/t5/Software-Archive/Multi-byte-NOP-opcode-made-official/td-p/932580 Archived] on 7 Apr 2022.</ref>
The whole {{nowrap|<code>0F 18..1F</code>}} opcode range was <code>NOP</code> in Pentium Pro. However, except for {{nowrap|<code>0F 1F /0</code>}}, Intel does not guarantee that these opcodes will remain <code>NOP</code> in future processors, and have indeed assigned some of these opcodes to other instructions in at least some processors.<ref>Intel [https://www.intel.com/content/www/us/en/developer/articles/technical/intel-sdm.html Software Developers Manual, vol 3B] (order no 253669-076us, December 2021), section 22.15 "Reserved NOP"</ref>}}<br />{{nowrap|AMD [[AMD K7|K7]], [[x86-64]],{{efn|Documented for AMD x86-64 since 2002.<ref>AMD, [https://kib.kiev.ua/x86docs/AMD/AMD64/24594_APM_v3-r3.02.pdf AMD 64-bit Technology – AMD x86-64 Architecture Programmer’s Manual Volume 3], publication no. 24594, rev 3.02, aug 2002, page 379.</ref>}}}}<br />VIA [[VIA C7|C7]]<ref>Debian bug report logs, [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464962#148 -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. [https://web.archive.org/web/20190801174955/https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464962#148 Archived] on 1 Aug 2019</ref><!-- No information appears to exist about whether Rise mP6, Transmeta Efficeon or any of the Vortex86 variants support Long NOP. AMD K6, VIA C3, Cyrix MII, Crusoe, GeodeLX do not support it. -->
|-
| <code>UD2</code>,{{efn|While the {{nowrap|<code>0F 0B</code>}} opcode was officially reserved as an invalid opcode from Pentium onwards, it only got assigned the mnemonic <code>UD2</code> from [[Pentium Pro]] onwards.<ref>Intel, [https://www.ardent-tool.com/CPU/docs/Intel/IA/243191-001.pdf Intel Architecture Software Developer’s Manual, Volume 2], 1997, order no. 243191-001, pages 3-9 and A-7.</ref>}}<br /><code>UD2A</code>{{efn|name=ud2_binutils|text=[[GNU Binutils]] have used the <code>UD2A</code> and <code>UD2B</code> mnemonics for the {{nowrap|<code>0F 0B</code>}} and {{nowrap|<code>0F B9</code>}} opcodes since version 2.7.<ref>John Hassey, [https://sourceware.org/pipermail/gas2/1995/000421.html Pentium Pro changes], ''GAS2 mailing list'', 28 dec 1995 – patch that added the <code>UD2A</code> and <code>UD2B</code> instruction mnemomics to GNU Binutils. [https://web.archive.org/web/20230725214633/https://sourceware.org/pipermail/gas2/1995/000421.html Archived] on 25 Jul 2023.</ref><br />Neither <code>UD2A</code> nor <code>UD2B</code> originally took any arguments - <code>UD2B</code> was later modified to accept a [[ModR/M]] byte, in Binutils version 2.30.<ref>Jan Beulich, [https://sourceware.org/pipermail/binutils-cvs/2017-November/046908.html x86: correct UDn], ''binutils-gdb mailing list'', 23 nov 2017 – Binutils patch that added ModR/M byte to <code>UD1</code>/<code>UD2B</code> and added <code>UD0</code>. [https://web.archive.org/web/20230725214642/https://sourceware.org/pipermail/binutils-cvs/2017-November/046908.html Archived] on 25 Jul 2023.</ref>}}
| <code>0F 0B</code>
| rowspan="3" | Undefined Instructions – will generate an [[illegal opcode|invalid opcode]] (#UD) exception in all operating modes.{{efn|The <code>UD2</code> ({{nowrap|<code>0F 0B</code>}}) 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 <code>UD2</code> instruction after the indirect branch.<ref>Intel, [https://web.archive.org/web/20030316105019/http://developer.intel.com/design/pentium4/manuals/24896607.pdf Intel Pentium 4 and Intel Xeon Processor Optimization Reference Manual], order no. 248966-007, see "Assembly/Compiler Coding Rule 13" on page 74. Archived from the [http://developer.intel.com/design/pentium4/manuals/24896607.pdf original] on 16 Mar 2003.</ref>}}

These instructions are provided for software testing to explicitly generate invalid opcodes. The opcodes for these instructions are reserved for this purpose.
| rowspan="3" {{yes|(3)}}
| rowspan="2" | ([[Intel 80186|80186]]),{{efn|name=ud_186|text=The UD0/1/2 opcodes - {{nowrap|<code>0F 0B</code>}}, {{nowrap|<code>0F B9</code>}} and {{nowrap|<code>0F FF</code>}} - will cause an #UD exception on all x86 processors from the [[Intel 80186|80186]] onwards (except [[NEC V20|NEC V-series]] processors), but did not get explicitly reserved for this purpose until P5-class processors.}}<br />Intel [[Pentium (original)|Pentium]]<ref>Intel, [https://www.ardent-tool.com/CPU/docs/Intel/Pentium/241430-004.pdf Pentium® Processor Family Developer's Manual Volume 3], 1995. order no. 241430-004, appendix A, page 943 – reserves the opcodes {{nowrap|<code>0F 0B</code>}} and {{nowrap|<code>0F B9</code>}}.</ref>
|-
| <code>UD1 reg,r/m</code>,{{efn|While the {{nowrap|<code>0F B9</code>}} opcode was officially reserved as an invalid opcode from Pentium onwards, it only got assigned its mnemonic <code>UD1</code> much later – AMD APM started listing <code>UD1</code> in its opcode maps from rev 3.17 onwards,<ref name="amd_ud0_ud1">AMD, [https://kib.kiev.ua/x86docs/AMD/AMD64/24594_APM_v3-r3.17.pdf AMD64 Architecture Programmer’s Manual Volume 3], publication no. 24594, rev 3.17, dec 2011 – see page 416 for <code>UD0</code> and page 415 and 419 for <code>UD1</code>.</ref> while Intel SDM started listing it from rev 061 onwards.<ref name="intel_ud0_ud1">Intel, [https://kib.kiev.ua/x86docs/Intel/SDMs/253667-061.pdf Software Developer's Manual, vol 2B], order no. 253667-061, dec 2016 – lists <code>UD1</code> (with {{nowrap|[[ModR/M]]}} byte) and <code>UD0</code> (without ModR/M byte) on page 4-687.</ref>}}<br />{{nowrap|<code>UD2B reg,r/m</code>{{efn|name=ud2_binutils}}}}
| <code>0F B9</code>,<br /><code>0F B9 /r</code>{{efn|name=ud01_modrm|For both the {{nowrap|<code>0F B9</code>}} and {{nowrap|<code>0F FF</code>}} opcodes, different x86 implementations are known to differ regarding whether the opcodes accept a {{nowrap|[[ModR/M]]}} byte.<ref>{{Cite web |first=Julian |last=Stecklina|date=2019-02-08 |title=Fingerprinting x86 CPUs using Illegal Opcodes |url=https://x86.lol/generic/2019/02/08/fingerprint.html |access-date=2023-12-15 |website=x86.lol |language=en |archive-url=https://web.archive.org/web/20231215165112/https://x86.lol/generic/2019/02/08/fingerprint.html |archive-date=15 Dec 2023 |url-status=live}}</ref><ref>{{Cite web |title=ud0 length fix · intelxed/xed@7561f54 |url=https://github.com/intelxed/xed/commit/7561f549d787edc55949b671dee2255a8435741a |access-date=2023-12-15 |website=GitHub |language=en |archive-url=https://web.archive.org/web/20230601122641/https://github.com/intelxed/xed/commit/7561f549d787edc55949b671dee2255a8435741a |archive-date=1 Jun 2023 |url-status=live}}</ref><ref>AMD, [https://www.amd.com/content/dam/amd/en/documents/processor-tech-docs/programmer-references/24594.pdf AMD64 Architecture Programmer’s Manual Volume 3], publication no. 24594, rev 3.36, march 2024 – see description of <code>UD1</code> instruction on page 356. [https://web.archive.org/web/20241229222758/https://www.amd.com/content/dam/amd/en/documents/processor-tech-docs/programmer-references/24594.pdf Archived] on 29 Dec 2024.</ref>}}
|-
| <code>OIO</code>,<br /><code>UD0</code>,<br /><code>UD0 reg,r/m</code>{{efn|For the {{nowrap|<code>0F FF</code>}} opcode, the <code>OIO</code> mnemonic was introduced by Cyrix,<ref name="cyrix_oio" /> while the <code>UD0</code> menmonic (without arguments) was introduced by AMD and Intel at the same time as the <code>UD1</code> mnemonic for {{nowrap|<code>0F B9</code>}}.<ref name="amd_ud0_ud1" /><ref name="intel_ud0_ud1" /> Later Intel (but not AMD) documentation modified its description of <code>UD0</code> to add a [[ModR/M]] byte and take two arguments.<ref>Intel, [https://kib.kiev.ua/x86docs/Intel/SDMs/253667-064.pdf Software Developer's Manual, vol 2B], order no. 253667-064, oct 2017 – lists <code>UD0</code> (with ModR/M byte) on page 4-683.</ref>}}
| <code>0F FF</code>,<br /><code>0F FF /r</code>{{efn|name=ud01_modrm}}
| ([[Intel 80186|80186]]),{{efn|name=ud_186}}<br />[[Cyrix 6x86]],<ref name="cyrix_oio">Cyrix, [https://ardent-tool.com/CPU/docs/Cyrix/6x86/94175.pdf 6x86 processor data book], 1996, order no. 94175-01, table 6-20, page 209 – uses the mnemonic <code>OIO</code> ("Official invalid opcode") for the {{nowrap|<code>0F FF</code>}} opcode.</ref><br />[[AMD K5]]<ref>AMD, [https://www.ardent-tool.com/CPU/docs/AMD/K5/18524c.pdf AMD-K5 Processor Technical Reference Manual], Nov 1996, order no. 18524C/0, section 3.3.7, page 90 – reserves the {{nowrap|<code>0F FF</code>}} opcode without assigning it a mnemonic.</ref><br />
|-
! colspan="5" |
|-
| <code>SYSCALL</code>
| <code>0F 05</code>
| Fast [[System call]].
| {{yes|3}}
| rowspan="2" | AMD [[AMD K6|K6]],{{efn|On K6, the <code>SYSCALL</code>/<code>SYSRET</code> instructions were available on Model 7 (250nm "Little Foot") and later, not on the earlier Model 6.<ref>AMD, [https://www.ardent-tool.com/CPU/docs/AMD/K6/20695.pdf AMD-K6 Processor Data Sheet], order no. 20695H/0, March 1998, section 24.2, page 283.</ref>}}<br />[[x86-64]]{{efn|<code>SYSCALL</code> and <code>SYSRET</code> 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.<br />Outside 64-bit mode, the instructions are available on AMD processors only.}}{{efn|The exact semantics of <code>SYSRET</code> 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.<ref>George Dunlap, [https://xenproject.org/2012/06/13/the-intel-sysret-privilege-escalation/ The Intel SYSRET Privilege Escalation], ''The Xen Project.'', 13 june 2012. [https://web.archive.org/web/20190315121519/https://xenproject.org/2012/06/13/the-intel-sysret-privilege-escalation/ Archived] on Mar 15, 2019.</ref>}}
|-
| <code>SYSRET</code>
| <code>0F 07</code>{{efn|name="sysret_64bit"|text=For the <code>SYSRET</code> and <code>SYSEXIT</code> instructions under x86-64, it is necessary to add the <code>REX.W</code> prefix for variants that will return to 64-bit user-mode code.<br />Encodings of these instructions without the <code>REX.W</code> 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, <code>IRET</code>/<code>IRETD</code>/<code>IRETQ</code> should be used.)}}
| Fast Return from System Call. Designed to be used together with <code>SYSCALL</code>.
| {{no|0{{efn|name="syscall_realmode"|text=The <code>SYSRET</code>, <code>SYSENTER</code> and <code>SYSEXIT</code> instructions are unavailable in [[Real mode]]. (<code>SYSENTER</code> is, however, available in [[Virtual 8086 mode]].)}}}}
|-
| <code>SYSENTER</code>
| <code>0F 34</code>
| Fast [[System call]].
| {{yes|3{{efn|name="syscall_realmode"}}}}
| rowspan="2" | Intel [[Pentium II]],{{efn|text=The <code>CPUID</code> flags that indicate support for <code>SYSENTER</code>/<code>SYSEXIT</code> are set on the Pentium Pro, even though the processor does not officially support these instructions.<ref>Intel, [http://kib.kiev.ua/x86docs/Intel/AppNote485/241618-039.pdf AP-485: Intel® Processor Identification and the CPUID Instruction], order no. 241618-039, may 2012, section 5.1.2.5, page 32</ref><br />Third party testing indicates that the opcodes are present on the Pentium Pro but too buggy to be usable.<ref>Michal Necasek, [http://www.os2museum.com/wp/sysenter-where-are-you/ "SYSENTER, Where Are You?"], 20 Jul 2017. [https://web.archive.org/web/20231129090510/http://www.os2museum.com/wp/sysenter-where-are-you/ Archived] on 29 Nov 2023.</ref>}}<br />AMD [[AMD K7|K7]],<ref>AMD, [https://pdf.datasheetcatalog.com/datasheet/AdvancedMicroDevices/mXvyvs.pdf Athlon Processor x86 Code Optimization Guide], publication no. 22007, rev K, feb 2002, appendix F, page 284. [https://web.archive.org/web/20170413235648/https://pdf.datasheetcatalog.com/datasheet/AdvancedMicroDevices/mXvyvs.pdf Archived] on 13 Apr 2017.</ref>{{efn|On AMD CPUs, the <code>SYSENTER</code> and <code>SYSEXIT</code> instructions are not available in x86-64 [[long mode]] (#UD).}}<br />Transmeta [[Transmeta Crusoe|Crusoe]],{{efn|On Transmeta CPUs, the <code>SYSENTER</code> and <code>SYSEXIT</code> instructions are only available with version 4.2 or higher of the Transmeta Code Morphing software.<ref>Transmeta, [http://datasheets.chipdb.org/Transmeta/Crusoe/Crusoe_CPUID_5-7-02.pdf Processor Recognition], May 7, 2002.</ref>}}<br />{{nowrap|NatSemi [[Geode (processor)|Geode GX2]],}}<br />VIA [[VIA C3#Nehemiah cores|C3 "Nehemiah"]],{{efn|On Nehemiah, <code>SYSENTER</code> and <code>SYSEXIT</code> are available only on stepping 8 and later.<ref>VIA, [http://datasheets.chipdb.org/VIA/Nehemiah/VIA%20C3%20Nehemiah%20Datasheet%20R113.pdf VIA C3 Nehemiah Processor Datasheet], rev 1.13, sep 29, 2004, page 17</ref>}}<br />DM&P [[Vortex86]]DX3
|-
| <code>SYSEXIT</code>
| <code>0F 35</code>{{efn|name="sysret_64bit"}}
| Fast Return from System Call. Designed to be used together with <code>SYSENTER</code>.
| {{no|0{{efn|name="syscall_realmode"}}}}
|}
{{notelist}}
{{vpad}}

=== 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 (<code>MOVSXD</code> replacing <code>ARPL</code>)
* original instructions with new opcodes (<code>SWAPGS</code>)
* existing instructions extended to a 64 bit address size (<code>JRCXZ</code>)
* existing instructions extended to a 64 bit operand size (remaining instructions)

Most instructions with a 64 bit operand size encode this using a <code>REX.W</code> prefix; in the absence of the <code>REX.W</code> 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.

{| class="wikitable sortable"
! Instruction !! Encoding !! Meaning !! [[Protection ring|Ring]]
|-
| <code>CDQE</code>
| <code>REX.W 98</code>
| Sign extend EAX into RAX
| rowspan="13" {{yes|3}}
|-
| <code>CQO</code>
| <code>REX.W 99</code>
| Sign extend RAX into RDX:RAX
|-
| <code>CMPSQ</code>
| <code>REX.W A7</code>
| CoMPare String Quadword
|-
| {{nowrap|<code>CMPXCHG16B m128</code>}}{{efn|The memory operand to <code>CMPXCHG16B</code> must be 16-byte aligned.}}{{efn|text=The <code>CMPXCHG16B</code> instruction was absent from a few of the earliest Intel/AMD x86-64 processors. On Intel processors, the instruction was missing from [[List of Intel Xeon processors (NetBurst-based)#"Nocona" (90 nm)|Xeon "Nocona"]] stepping D,<ref>CPU-World, [https://www.cpu-world.com/cgi-bin/CPUID.pl?CPUID=75151 CPUID for Intel Xeon 3.40 GHz] – Nocona stepping D CPUID without CMPXCHG16B</ref> but added in stepping E.<ref>CPU-World, [https://www.cpu-world.com/cgi-bin/CPUID.pl?CPUID=75154 CPUID for Intel Xeon 3.60 GHz] – Nocona stepping E CPUID with CMPXCHG16B</ref> On [[AMD K8]] family processors, it was added in stepping F, at the same time as DDR2 support was introduced.<ref>SuperUser StackExchange, [https://superuser.com/questions/187254/how-prevalent-are-old-x64-processors-lacking-the-cmpxchg16b-instruction How prevalent are old x64 processors lacking the cmpxchg16b instruction?]</ref><br />For this reason, <code>CMPXCHG16B</code> has its own CPUID flag, separate from the rest of x86-64.}}
| {{nowrap|<code>REX.W 0F C7 /1</code>}}
| CoMPare and eXCHanGe 16 Bytes.<br />Atomic only if used with LOCK prefix.
|-
| <code>IRETQ</code>
| <code>REX.W CF</code>
| 64-bit Return from Interrupt
|-
| <code>JRCXZ rel8</code>
| <code>E3 ''cb''</code>
| Jump if RCX is zero
|-
| <code>LODSQ</code>
| <code>REX.W AD</code>
| LoaD String Quadword
|-
| {{nowrap|<code>MOVSXD r64,r/m32</code>}}
| <code>REX.W 63 /r</code>{{efn|Encodings of <code>MOVSXD</code> without REX.W prefix are permitted but discouraged<ref>Intel [https://www.intel.com/content/www/us/en/developer/articles/technical/intel-sdm.html SDM order no. 325462-077], apr 2022, vol 2B, p.4-130 "MOVSX/MOVSXD-Move with Sign-Extension" lists MOVSXD without REX.W as "discouraged"</ref> – such encodings behave identically to 16/32-bit <code>MOV</code> ({{nowrap|<code>8B /r</code>}}).}}
| MOV with Sign Extend 32-bit to 64-bit
|-
| <code>MOVSQ</code>
| <code>REX.W A5</code>
| Move String Quadword
|-
| <code>POPFQ</code>
| <code>9D</code>
| POP RFLAGS Register
|-
| <code>PUSHFQ</code>
| <code>9C</code>
| PUSH RFLAGS Register
|-
| <code>SCASQ</code>
| <code>REX.W AF</code>
| SCAn String Quadword
|-
| <code>STOSQ</code>
| <code>REX.W AB</code>
| STOre String Quadword
|-
| <code>SWAPGS</code>
| <code>0F 01 F8</code>
| Exchange GS base with KernelGSBase MSR
| {{no|0}}
|}
{{notelist}}{{vpad}}

==== Bit manipulation extensions ====
{{Main|X86 Bit manipulation instruction set}}

Bit manipulation instructions. For all of the [[VEX prefix|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.
{| class="wikitable sortable"
! Bit Manipulation Extension !! Instruction<br />mnemonics !! Opcode !! Instruction description !! Added in
|-
! colspan="5" |
|-
| rowspan="4" | {{glossary}}{{term|[[Advanced Bit Manipulation|ABM]] (LZCNT){{efn|text=On AMD CPUs, the "ABM" extension provides both <code>POPCNT</code> and <code>LZCNT</code>. On Intel CPUs, however, the CPUID bit for "ABM" is only documented to indicate the presence of the <code>LZCNT</code> instruction and is listed as "LZCNT", while <code>POPCNT</code> has its own separate CPUID feature bit.<br />However, all known processors that implement the "ABM"/"LZCNT" extensions also implement <code>POPCNT</code> and set the CPUID feature bit for POPCNT, so the distinction is theoretical only.<br />(The converse is not true – there exist processors that support <code>POPCNT</code> but not ABM, such as Intel [[Nehalem (microarchitecture)|Nehalem]] and [[VIA Nano]] 3000.)}}}}{{defn|Advanced Bit Manipulation}}{{glossary end}}
| <code>POPCNT r16,r/m16</code><br />{{nowrap|<code>POPCNT r32,r/m32</code>}}
| <code>F3 0F B8 /r</code>
| rowspan="2" | [[Hamming weight|Population Count]]. Counts the number of bits that are set to 1 in its source argument.
| rowspan="4" | [[AMD K10|K10]],<br />[[Bobcat (microarchitecture)|Bobcat]],<br />[[Haswell (microarchitecture)|Haswell]],<br />[[Zhaoxin|ZhangJiang]],<br />[[Gracemont (microarchitecture)|Gracemont]]
|-
| <code>POPCNT r64,r/m64</code>
| <code>F3 REX.W 0F B8 /r</code>
|-
| <code>LZCNT r16,r/m16</code><br /><code>LZCNT r32,r/m32</code>
| <code>F3 0F BD /r</code>
| rowspan="2" | Count Leading zeroes.{{efn|The <code>LZCNT</code> instruction will execute as <code>BSR</code> on systems that do not support the LZCNT or ABM extensions. <code>BSR</code> computes the index of the highest set bit in the source operand, producing a different result from <code>LZCNT</code> for most input values.}}<br />If source operand is all-0s, then <code>LZCNT</code> will return operand size in bits (16/32/64) and set CF=1.
|-
| <code>LZCNT r64,r/m64</code>
| {{nowrap|<code>F3 REX.W 0F BD /r</code>}}
|-
! colspan="5" |
|-
| rowspan="7" | {{glossary}}{{term|BMI1}}{{defn|Bit Manipulation Instruction Set 1}}{{glossary end}}
| <code>TZCNT r16,r/m16</code><br /><code>TZCNT r32,r/m32</code>
| <code>F3 0F BC /r</code>
| rowspan="2" | Count Trailing zeroes.{{efn|The <code>TZCNT</code> instruction will execute as <code>BSF</code> on systems that do not support the BMI1 extension. <code>BSF</code> produces the same result as <code>TZCNT</code> for all input operand values except zero – for which <code>TZCNT</code> returns input operand size, but <code>BSF</code> produces undefined behavior (leaves destination unmodified on most modern CPUs).}}<br />If source operand is all-0s, then <code>TZCNT</code> will return operand size in bits (16/32/64) and set CF=1.
| rowspan="7" | [[Haswell (microarchitecture)|Haswell]],<br />[[Piledriver (microarchitecture)|Piledriver]],<br />[[Jaguar (microarchitecture)|Jaguar]],<br />[[Zhaoxin|ZhangJiang]],<br />[[Gracemont (microarchitecture)|Gracemont]]
|-
| <code>TZCNT r64,r/m64</code>
| {{nowrap|<code>F3 REX.W 0F BC /r</code>}}
|-
| <code>ANDN ra,rb,r/m</code>
| <code>VEX.LZ.0F38 F2 /r</code>
| Bitwise AND-NOT: <code>ra = r/m AND NOT(rb)</code>
|-
| <code>BEXTR ra,r/m,rb</code>
| <code>VEX.LZ.0F38 F7 /r</code>
| Bitfield extract. Bitfield start position is specified in bits [7:0] of <code>rb</code>, length in bits[15:8] of <code>rb</code>. The bitfield is then extracted from the <code>r/m</code> value with zero-extension, then stored in <code>ra</code>. Equivalent to{{efn|For <code>BEXTR</code>, 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 <code>r/m</code> argument (which has the usual 32/64-bit operand size), then the out-of-bounds bits are read out as 0.}}<pre>
mask = (1 << rb[15:8]) - 1
ra = (r/m >> rb[7:0]) AND mask</pre>
|-
| <code>BLSI reg,r/m</code>
| <code>VEX.LZ.0F38 F3 /3</code>
| Extract lowest set bit in source argument. Returns 0 if source argument is 0. Equivalent to<br /><code>dst = (-src) AND src</code>
|-
| <code>BLSMSK reg,r/m</code>
| <code>VEX.LZ.0F38 F3 /2</code>
| Generate a bitmask of all-1s bits up to the lowest bit position with a 1 in the source argument. Returns all-1s if source argument is 0. Equivalent to <br /><code>dst = (src-1) XOR src</code>
|-
| <code>BLSR reg,r/m</code>
| <code>VEX.LZ.0F38 F3 /1</code>
| Copy all bits of the source argument, then clear the lowest set bit. Equivalent to<br /><code>dst = (src-1) AND src</code>
|-
! colspan="5" |
|-
| rowspan="8" | {{glossary}}{{term|BMI2}}{{defn|Bit Manipulation Instruction Set 2}}{{glossary end}}
| <code>BZHI ra,r/m,rb</code>
| {{small|<code>VEX.LZ.0F38 F5 /r</code>}}
| Zero out high-order bits in <code>r/m</code> starting from the bit position specified in <code>rb</code>, then write result to <code>rd</code>. Equivalent to<br /><code>ra = r/m AND NOT(-1 << rb[7:0])</code>
| rowspan="8" | [[Haswell (microarchitecture)|Haswell]],<br />{{nowrap|[[Excavator (microarchitecture)|Excavator]],{{efn|text=On AMD processors before Zen 3, the <code>PEXT</code> and <code>PDEP</code> instructions are quite slow<ref>Anandtech, [https://www.anandtech.com/show/16214/amd-zen-3-ryzen-deep-dive-review-5950x-5900x-5800x-and-5700x-tested/6 AMD Zen 3 Ryzen Deep Dive Review], nov 5, 2020, page 6</ref> 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.<ref>{{Cite tweet |user=instlatx64 |number=1322503571288559617 |date=October 31, 2020 |title=Saving Private Ryzen: PEXT/PDEP 32/64b replacement functions for #AMD CPUs (BR/#Zen/Zen+/#Zen2) based on @zwegner's zp7 |access-date=2023-01-20 |language=en}}</ref><ref>{{cite web |last1=Wegner |first1=Zach |title=zwegner/zp7 |website=[[GitHub]] |url=https://github.com/zwegner/zp7 |date=4 November 2020}}</ref>}}}}<br />[[Zhaoxin|ZhangJiang]],<br />[[Gracemont (microarchitecture)|Gracemont]]
|-
| <code>MULX ra,rb,r/m</code>
| {{small|{{nowrap|<code>VEX.LZ.F2.0F38 F6 /r</code>}}}}
| Widening unsigned integer multiply without setting flags. Multiplies EDX/RDX with <code>r/m</code>, then stores the low half of the multiplication result in <code>ra</code> and the high half in <code>rb</code>. If <code>ra</code> and <code>rb</code> specify the same register, only the high half of the result is stored.
|-
| <code>PDEP ra,rb,r/m</code>
| {{small|{{nowrap|<code>VEX.LZ.F2.0F38 F5 /r</code>}}}}
| Parallel Bit Deposit. Scatters contiguous bits from <code>rb</code> to the bit positions set in <code>r/m</code>, then stores result to <code>ra</code>. Operation performed is:<pre>
ra=0; k=0; mask=r/m
for i=0 to opsize-1 do
   if (mask[i] == 1) then
       ra[i]=rb[k]; k=k+1</pre>
|-
| <code>PEXT ra,rb,r/m</code>
| {{small|{{nowrap|<code>VEX.LZ.F3.0F38 F5 /r</code>}}}}
| Parallel Bit Extract. Uses <code>r/m</code> argument as a bit mask to select bits in <code>rb</code>, then compacts the selected bits into a contiguous bit-vector. Operation performed is:<pre>
ra=0; k=0; mask=r/m
for i=0 to opsize-1 do
   if (mask[i] == 1) then
       ra[k]=rb[i]; k=k+1</pre>
|-
| {{nowrap|<code>RORX reg,r/m,imm8</code>}}
| {{small|{{nowrap|<code>VEX.LZ.F2.0F3A F0 /r ''ib''</code>}}}}
| Rotate right by immediate without affecting flags.
|-
| <code>SARX ra,r/m,rb</code>
| {{small|{{nowrap|<code>VEX.LZ.F3.0F38 F7 /r</code>}}}}
| Arithmetic shift right without updating flags.<br />For <code>SARX</code>, <code>SHRX</code> and <code>SHLX</code>, the shift-amount specified in <code>rb</code> is masked to 5 bits for 32-bit operand size and 6 bits for 64-bit operand size.
|-
| <code>SHRX ra,r/m,rb</code>
| {{small|{{nowrap|<code>VEX.LZ.F2.0F38 F7 /r</code>}}}}
| Logical shift right without updating flags.
|-
| <code>SHLX ra,r/m,rb</code>
| {{small|{{nowrap|<code>VEX.LZ.66.0F38 F7 /r</code>}}}}
| Shift left without updating flags.
|}
{{notelist}}{{vpad}}

==== Added with Intel TSX ====
{{Main|Transactional Synchronization Extensions}}

{| class="wikitable sortable"
! TSX Subset !! Instruction !! Opcode !! Description !! Added in
|-
! colspan="5" |
|-
| rowspan="4" | {{glossary}}{{term|RTM}}{{defn|Restricted [[Transactional memory]]}}{{glossary end}}
| <code>XBEGIN rel16</code><br />{{nowrap|<code>XBEGIN rel32</code>}}
| <code>C7 F8 ''cw''</code><br />{{nowrap|<code>C7 F8 ''cd''</code>}}
| Start transaction. If transaction fails, perform a branch to the given relative offset.
| rowspan="4" | [[Haswell (microarchitecture)|Haswell]]<br />(Deprecated on desktop/laptop CPUs from 10th generation ([[Ice Lake (microprocessor)|Ice Lake]], [[Comet Lake]]) onwards, but continues to be available on [[Xeon]]-branded server parts (e.g. [[Ice Lake (microprocessor)|Ice Lake-SP]], [[Sapphire Rapids (microprocessor)|Sapphire Rapids]]))
|-
| <code>XABORT imm8</code>
| <code>C6 F8 ''ib''</code>
| Abort transaction with 8-bit immediate as error code.
|-
| <code>XEND</code>
| {{nowrap|<code>NP 0F 01 D5</code>}}
| End transaction.
|-
| <code>XTEST</code>
| {{nowrap|<code>NP 0F 01 D6</code>}}
| Test if in transactional execution. Sets <code>[[FLAGS register|EFLAGS]].ZF</code> to 0 if executed inside a transaction (RTM or HLE), 1 otherwise.
|-
! colspan="5" |
|-
| rowspan="2" | {{glossary}}{{term|HLE}}{{defn|Hardware Lock Elision}}{{glossary end}}
| <code>XACQUIRE</code>
| <code>F2</code>
| Instruction prefix to indicate start of hardware lock elision, used with memory atomic instructions only (for other instructions, the <code>F2</code> prefix may have other meanings). When used with such instructions, may start a transaction instead of performing the memory atomic operation.
| rowspan="2" | [[Haswell (microarchitecture)|Haswell]]<br />(Discontinued – the last processors to support HLE were {{nowrap|[[Coffee Lake]]}} and {{nowrap|[[Cascade Lake (microprocessor)|Cascade Lake]])}}
|-
| <code>XRELEASE</code>
| <code>F3</code>
| Instruction prefix to indicate end of hardware lock elision, used with memory atomic/store instructions only (for other instructions, the <code>F3</code> prefix may have other meanings). When used with such instructions during hardware lock elision, will end the associated transaction instead of performing the store/atomic.
|-
! colspan="5" |
|-
| rowspan="2" | {{glossary}}{{term|TSXLDTRK}}{{defn|Load Address Tracking suspend/resume}}{{glossary end}}
| <code>XSUSLDTRK</code>
| {{nowrap|<code>F2 0F 01 E8</code>}}
| Suspend Tracking Load Addresses
| rowspan="2" | {{nowrap|[[Sapphire Rapids (microprocessor)|Sapphire Rapids]]}}
|-
| <code>XRESLDTRK</code>
| {{nowrap|<code>F2 0F 01 E9</code>}}
| Resume Tracking Load Addresses
|}
{{vpad}}

==== Added with [[Control-flow integrity#Intel Control-flow Enforcement Technology|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).
{| class="wikitable sortable"
! CET Subset !! Instruction !! Opcode !! Description !! [[Protection ring|Ring]] !! Added in
|-
! colspan="6" |
|-
| rowspan="12" | {{glossary}}{{term|CET_SS}}{{defn|[[Shadow stack]].<br />When shadow stacks are enabled, return addresses are pushed on both the regular stack and the shadow stack when a function call is made. They are then both popped on return from the function call – if they do not match, then the stack is assumed to be corrupted, and a #CP exception is issued.<br />The shadow stack is additionally required to be stored in specially marked memory pages which cannot be modified by normal memory store instructions.}}{{glossary end}}
| <code>INCSSPD r32</code>
| <code>F3 0F AE /5</code>
| rowspan="2" | Increment shadow stack pointer
| rowspan="8" {{yes|3}}
| rowspan="12" | {{nowrap|[[Tiger Lake]],}}<br />[[Zen 3]]
|-
| <code>INCSSPQ r64</code>
| <code>F3 REX.W 0F AE /5</code>
|-
| <code>RDSSPD r32</code>
| <code>F3 0F 1E /1</code>
| Read shadow stack pointer into register (low 32 bits){{efn|name="rdssp_nop"|text=The <code>RDSSPD</code> and <code>RDSSPQ</code> instructions act as NOPs on processors where shadow stacks are disabled or CET is not supported.}}
|-
| <code>RDSSPQ r64</code>
| <code>F3 REX.W 0F 1E /1</code>
| Read shadow stack pointer into register (full 64 bits){{efn|name="rdssp_nop"}}
|-
| <code>SAVEPREVSSP</code>
| <code>F3 0F 01 EA</code>
| Save previous shadow stack pointer
|-
| <code>RSTORSSP m64</code>
| <code>F3 0F 01 /5</code>
| Restore saved shadow stack pointer
|-
| <code>WRSSD m32,r32</code>
| <code>NP 0F 38 F6 /r</code>
| Write 4 bytes to shadow stack
|-
| <code>WRSSQ m64,r64</code>
| {{nowrap|<code>NP REX.W 0F 38 F6 /r</code>}}
| Write 8 bytes to shadow stack
|-
| <code>WRUSSD m32,r32</code>
| <code>66 0F 38 F5 /r</code>
| Write 4 bytes to user shadow stack
| rowspan="4" {{no|0}}
|-
| {{nowrap|<code>WRUSSQ m64,r64</code>}}
| {{nowrap|<code>66 REX.W 0F 38 F5 /r</code>}}
| Write 8 bytes to user shadow stack
|-
| <code>SETSSBSY</code>
| <code>F3 0F 01 E8</code>
| Mark shadow stack busy
|-
| <code>CLRSSBSY m64</code>
| <code>F3 0F AE /6</code>
| Clear shadow stack busy flag
|-
! colspan="6" |
|-
| rowspan="3" | {{glossary}}{{term|CET_IBT}}{{defn|[[Indirect Branch Tracking]].<br />When IBT is enabled, an indirect branch (jump, call, return) to any instruction that is not an <code>ENDBR32/64</code> instruction will cause a #CP exception.}}{{glossary end}}
| <code>ENDBR32</code>
| <code>F3 0F 1E FB</code>
| Terminate indirect branch in 32-bit mode{{efn|name="endbr_nop"|text=<code>ENDBR32</code> and <code>ENDBR64</code> act as NOPs on processors that don't support CET_IBT or where IBT is disabled.}}
| rowspan="3" {{yes|3}}
| rowspan="3" | [[Tiger Lake]]
|-
| <code>ENDBR64</code>
| <code>F3 0F 1E FA</code>
| Terminate indirect branch in 64-bit mode{{efn|name="endbr_nop"}}
|-
| <code>NOTRACK</code>
| <code>3E</code>{{efn|text=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.<ref>Intel, [https://kib.kiev.ua/x86docs/Intel/CET/334525-003.pdf Control-flow Enforcement Technology Specification] (v3.0, order no. 334525-003, March 2019)</ref><ref>[https://kib.kiev.ua/x86docs/Intel/SDMs/253665-076.pdf Intel SDM, rev 076, December 2021], volume 1, section 18.3.1</ref> (GNU binutils use "notrack"<ref>Binutils mailing list: [https://sourceware.org/pipermail/binutils/2017-June/098516.html x86: CET v2.0: Update NOTRACK prefix]</ref>)}}
| Prefix used with indirect <code>CALL</code>/<code>JMP</code> near instructions (opcodes {{nowrap|<code>FF /2</code>}} and {{nowrap|<code>FF /4</code>}}) to indicate that the branch target is not required to start with an <code>ENDBR32/64</code> instruction. Prefix only honored when NO_TRACK_EN flag is set.
|}
{{notelist}}{{vpad}}

==== Added with XSAVE ====
The XSAVE instruction set extensions are designed to save/restore CPU extended state (typically for the purpose of [[context switch]]ing) 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 <code>EAX=0Dh</code> [[CPUID#EAX=0Dh:_XSAVE_features_and_state-components|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.

{| class="wikitable sortable"
! XSAVE Extension !! Instruction<br />mnemonics !! Opcode{{efn|Under Intel APX, the <code>XSAVE*</code> and <code>XRSTOR*</code> instructions cannot be encoded with the REX2 prefix.}} !! Instruction description !! [[Protection ring|Ring]] !! Added in
|-
! colspan="6" |
|-
| rowspan="4" | {{glossary}}{{term|XSAVE}}{{defn|Processor Extended State Save/Restore.}}{{glossary end}}
| <code>XSAVE mem</code><br /><code>XSAVE64 mem</code>
| <code>NP 0F AE /4</code><br /><code>NP REX.W 0F AE /4</code>
| Save state components specified by bitmap in EDX:EAX to memory.
| rowspan="3" {{yes|3}}
| rowspan="4" | [[Penryn (microarchitecture)|Penryn]],{{efn|XSAVE was added in steppings E0/R0 of Penryn and is not available in earlier steppings.}}<br />[[Bulldozer (microarchitecture)|Bulldozer]],<br />[[Jaguar (microarchitecture)|Jaguar]],<br />[[Goldmont]],<br />[[Zhaoxin|ZhangJiang]]
|-
| <code>XRSTOR mem</code><br /><code>XRSTOR64 mem</code>
| <code>NP 0F AE /5</code><br />{{nowrap|<code>NP REX.W 0F AE /5</code>}}
| Restore state components specified by EDX:EAX from memory.
|-
| <code>XGETBV</code>
| <code>NP 0F 01 D0</code>
| Get value of Extended Control Register.<br />Reads an XCR specified by ECX into EDX:EAX.{{efn|text=On some processors (starting with [[Skylake (microarchitecture)|Skylake]], [[Goldmont]] and [[Zen (first generation)|Zen 1]]), executing <code>XGETBV</code> with ECX=1 is permitted – this will not return <code>XCR1</code> (no such register exists) but instead return <code>XCR0</code> 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).<br />The presence of this functionality of <code>XGETBV</code> is indicated by {{nowrap|1=[[CPUID]].(EAX=0Dh,ECX=1):EAX[bit 2].}}}}
|-
| <code>XSETBV</code>
| <code>NP 0F 01 D1</code>
| Set Extended Control Register.{{efn|The <code>XSETBV</code> instruction will cause a mandatory #VMEXIT if executed under [[Intel VT-x]] virtualization.}}<br />Write the value in EDX:EAX to the XCR specified by ECX.
| {{no|0}}
|-
! colspan="6" |
|-
| {{glossary}}{{term|XSAVEOPT}}{{defn|Processor Extended State Save/Restore Optimized}}{{glossary end}}
| <code>XSAVEOPT mem</code><br />{{nowrap|<code>XSAVEOPT64 mem</code>}}
| <code>NP 0F AE /6</code><br /><code>NP REX.W 0F AE /6</code>
| Save state components specified by EDX:EAX to memory.<br />Unlike the older <code>XSAVE</code> instruction, <code>XSAVEOPT</code> may abstain from writing processor state items to memory when the CPU can determine that they haven't been modified since the most recent corresponding <code>XRSTOR</code>.
| {{yes|3}}
| {{nowrap|[[Sandy Bridge]],}}<br />[[Steamroller (microarchitecture)|Steamroller]],<br />[[Puma (microarchitecture)|Puma]],<br />[[Goldmont]],<br />[[Zhaoxin|ZhangJiang]]
|-
! colspan="6" |
|-
| {{glossary}}{{term|XSAVEC}}{{defn|Processor Extended State save/restore with compaction.}}{{glossary end}}
| <code>XSAVEC mem</code><br /><code>XSAVEC64 mem</code>
| <code>NP 0F C7 /4</code><br /><code>NP REX.W 0F C7 /4</code>
| Save processor extended state components specified by EDX:EAX to memory with compaction.
| {{yes|3}}
| [[Skylake (microarchitecture)|Skylake]],<br />[[Goldmont]],<br />[[Zen (first generation)|Zen 1]]
|-
! colspan="6" |
|-
| rowspan="2" | {{glossary}}{{term|XSS}}{{defn|Processor Extended State save/restore, including supervisor state.}}{{glossary end}}
| <code>XSAVES mem</code><br /><code>XSAVES64 mem</code>
| <code>NP 0F C7 /5</code><br /><code>NP REX.W 0F C7 /5</code>
| Save processor extended state components specified by EDX:EAX to memory with compaction and optimization if possible.
| rowspan="2" {{no|0}}
| rowspan="2" | [[Skylake (microarchitecture)|Skylake]],<br />[[Goldmont]],<br />[[Zen (first generation)|Zen 1]]
|-
| <code>XRSTORS mem</code><br /><code>XRSTORS64 mem</code>
| <code>NP 0F C7 /3</code><br />{{nowrap|<code>NP REX.W 0F C7 /3</code>}}
| Restore state components specified by EDX:EAX from memory.
|}
{{notelist}}
{{vpad}}

==== Added with other cross-vendor extensions ====

{{sticky header}}
{| class="wikitable sortable sticky-header"
! Instruction Set Extension !! Instruction<br />mnemonics !! Opcode !! Instruction description !! [[Protection ring|Ring]] !! Added in
|-
! colspan="6" |
|-
| rowspan="5" | {{glossary}}{{term|[[Streaming SIMD Extensions|SSE]]{{efn|name="k7_mmxext"}}}}{{defn|(non-SIMD)}}{{glossary end}}
| <code>PREFETCHNTA m8</code>
| <code>0F 18 /0</code>
| Prefetch with Non-Temporal Access.<br />Prefetch data under the assumption that the data will be used only once, and attempt to minimize cache pollution from said data. The methods used to minimize cache pollution are implementation-dependent.{{efn|name="prefetch_hint"|text=All of the <code>PREFETCH*</code> 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.}}
| rowspan="5" {{yes|3}}
| rowspan="5" | [[Pentium III]],<br />([[AMD K7|K7]]),{{efn|name="k7_mmxext"|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 [[Extended MMX|"MMX Extensions"]].<ref>AMD, [https://refspecs.linuxfoundation.org/AMD-extensions.pdf Extensions to the 3DNow! and MMX Instruction Sets], ref no. 22466D/0, March 2000, p.11</ref> These extensions (without full SSE) are also present on [[Geode (processor)|Geode GX2]] and later Geode processors.}}<br />{{nowrap|([[Geode (processor)|Geode GX2]]),{{efn|name="k7_mmxext"}}}}<br />[[VIA C3#Nehemiah cores|Nehemiah]],<br />[[Transmeta Efficeon|Efficeon]]
|-
| <code>PREFETCHT0 m8</code>
| <code>0F 18 /1</code>
| Prefetch data to all levels of the cache hierarchy.{{efn|name="prefetch_hint"}}
|-
| <code>PREFETCHT1 m8</code>
| <code>0F 18 /2</code>
| Prefetch data to all levels of the cache hierarchy except L1 cache.{{efn|name="prefetch_hint"}}
|-
| <code>PREFETCHT2 m8</code>
| <code>0F 18 /3</code>
| Prefetch data to all levels of the cache hierarchy except L1 and L2 caches.{{efn|name="prefetch_hint"}}
|-
| <code>SFENCE</code>
| <code>NP 0F AE F8+x</code>{{efn|name="sse_partial_decode"|For the <code>SFENCE</code>, <code>LFENCE</code> and <code>MFENCE</code> 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.}}
| Store Fence.{{efn|The <code>SFENCE</code> instruction ensures that all memory stores after the <code>SFENCE</code> instruction are made globally observable after all memory stores before the <code>SFENCE</code>. This imposes ordering on stores that can otherwise be reordered, such as non-temporal stores and stores to WC (Write-Combining) memory regions.<ref>Hadi Brais, [https://hadibrais.wordpress.com/2019/02/26/the-significance-of-the-x86-sfence-instruction/ The Significance of the x86 SFENCE instruction], 26 Feb 2019.</ref><br />On Intel CPUs, as well as AMD CPUs from Zen1 onwards (but not older AMD CPUs), <code>SFENCE</code> also acts as a reordering barrier on cache flushes/writebacks performed with the <code>CLFLUSH</code>, <code>CLFLUSHOPT</code> and <code>CLWB</code> instructions. (Older AMD CPUs require <code>MFENCE</code> to order <code>CLFLUSH</code>.)<br /><code>SFENCE</code> is not ordered with respect to <code>LFENCE</code>, and an <code>SFENCE+LFENCE</code> sequence is not sufficient to prevent a load from being reordered past a previous store.<ref>Intel, [https://kib.kiev.ua/x86docs/Intel/SDMs/325462-077.pdf Software Developer's Manual], order no. 325426-077, Nov 2022, Volume 1, section 11.4.4.3, page 276.</ref> To prevent such reordering, it is necessary to execute an <code>MFENCE</code>, <code>LOCK</code> or a serializing instruction.}}
|-
! colspan="6" |
|-
| rowspan="4" | {{glossary}}{{term|[[SSE2]]}}{{defn|(non-SIMD)}}{{glossary end}}
| <code>LFENCE</code>
| <code>NP 0F AE E8+x</code>{{efn|name="sse_partial_decode"}}
| Load Fence and Dispatch Serialization.{{efn|The <code>LFENCE</code> instruction ensures that all memory loads after the <code>LFENCE</code> instruction are made globally observable after all memory loads before the <code>LFENCE</code>.<br />On all Intel CPUs that support SSE2, the <code>LFENCE</code> instruction provides a stronger ordering guarantee:<ref>Hadi Brais, [https://hadibrais.wordpress.com/2018/05/14/the-significance-of-the-x86-lfence-instruction/ The Significance of the LFENCE instruction], 14 May 2018</ref> it is ''dispatch-serializing'', meaning that instructions after the <code>LFENCE</code> 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 <code>LFENCE</code> also acts as a [[Speculative execution|speculation]] barrier and a reordering barrier for accesses to non-memory resources such as performance counters (accessed through e.g. <code>RDTSC</code> or <code>RDPMC</code>) and [[Advanced Programmable Interrupt Controller|x2apic]] MSRs.<br />On AMD CPUs, <code>LFENCE</code> is not necessarily dispatch-serializing by default – however, on all AMD CPUs that support any form of non-dispatch-serializing <code>LFENCE</code>, it can be made dispatch-serializing by setting bit 1 of MSR <code>C001_1029</code>.<ref>AMD, [https://www.amd.com/system/files/documents/software-techniques-for-managing-speculation.pdf Software techniques for managing speculation on AMD processor], rev 3.8.22, 8 March 2022, page 4. [https://web.archive.org/web/20220313090311/https://www.amd.com/system/files/documents/software-techniques-for-managing-speculation.pdf Archived] on 13 March 2022.</ref>}}
| rowspan="4" {{yes|3}}
| rowspan="4" | [[Pentium 4]],<br />[[AMD K8|K8]],<br />[[Transmeta Efficeon|Efficeon]],<br />[[VIA C7|C7 Esther]]
|-
| <code>MFENCE</code>
| <code>NP 0F AE F0+x</code>{{efn|name="sse_partial_decode"}}
| Memory Fence.{{efn|The <code>MFENCE</code> instruction ensures that all memory loads, stores and cacheline-flushes after the <code>MFENCE</code> instruction are made globally observable after all memory loads, stores and cacheline-flushes before the <code>MFENCE</code>.<br />On Intel CPUs, <code>MFENCE</code> 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. <code>MFENCE</code> is still ordered with respect to <code>LFENCE</code>, 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 <code>MFENCE</code> followed by an <code>LFENCE</code>.<ref name="rdtsc_ordering">Intel, [https://kib.kiev.ua/x86docs/Intel/SDMs/325462-077.pdf Software Developer's Manual], order no. 325426-077, Nov 2022 – the entry on the <code>RDTSC</code> instruction on p.1739 describes the instruction sequences required to order the <code>RDTSC</code> instruction with respect to earlier and later instructions.</ref><ref>Intel, [https://cdrdv2-public.intel.com/825743/325462-sdm-vol-1-2abcd-3abcd-4.pdf Software Developer's Manual], order no. 325426-084, June 2024, vol 3A, section 11.12.3, page 3411 - covers the use of the <code>MFENCE;LFENCE</code> sequence to enforce ordering between a memory store and a later x2apic MSR write. [https://web.archive.org/web/20240714161441/https://cdrdv2-public.intel.com/825743/325462-sdm-vol-1-2abcd-3abcd-4.pdf Archived] on 4 Jul 2024</ref><br />On AMD CPUs, <code>MFENCE</code> is serializing.}}
|-
| <code>MOVNTI m32,r32</code><br /><code>MOVNTI m64,r64</code>
| <code>NP 0F C3 /r</code><br /><code>NP REX.W 0F C3 /r</code>
| Non-Temporal Memory Store.
|-
| <code>PAUSE</code>
| <code>F3 90</code>{{efn|text=The operation of the <code>PAUSE</code> instruction in 64-bit mode is, unlike <code>NOP</code>, unaffected by the presence of the <code>REX.R</code> prefix. Neither <code>NOP</code> nor <code>PAUSE</code> are affected by the other bits of the <code>REX</code> prefix. A few examples of how opcode <code>90</code> interacts with various prefixes in 64-bit mode are:<ul><li><code>90</code> is <code>NOP</code><li><code>41 90</code> is <code>XCHG R8D,EAX</code><li><code>4E 90</code> is <code>NOP</code><li><code>49 90</code> is <code>XCHG R8,RAX</code><li><code>F3 90</code> is <code>PAUSE</code><li><code>F3 41 90</code> is <code>PAUSE</code><li><code>F3 4F 90</code> is <code>PAUSE</code></ul>}}
| Pauses CPU thread for a short time period.{{efn|The actual length of the pause performed by the <code>PAUSE</code> instruction is implementation-dependent.<br />On systems without SSE2, <code>PAUSE</code> will execute as NOP.}}<br />Intended for use in spinlocks.{{efn|Under VT-x or AMD-V virtualization, executing <code>PAUSE</code> many times in a short time interval may cause a #VMEXIT. The number of <code>PAUSE</code> executions and interval length that can trigger #VMEXIT are platform-specific.}}
|-
! colspan="6" |
|-
| {{glossary}}{{term|CLFSH{{efn|While the <code>CLFLUSH</code> 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 (processor)|Geode LX]] supports <code>CLFLUSH</code> but not SSE2.)}}}}{{defn|Cache Line Flush.}}{{glossary end}}
| {{nowrap|<code>CLFLUSH m8</code>}}
| <code>NP 0F AE /7</code>
| Flush one cache line to memory.<br />In a system with multiple [[cache hierarchy]] levels and/or multiple processors each with their own caches, the line is flushed from all of them.
| {{yes|3}}
| (SSE2),<br />[[Geode (processor)|Geode LX]]
|-
! colspan="6" |
|-
| rowspan="2" | {{glossary}}{{term|MONITOR{{efn|While the <code>MONITOR</code> and <code>MWAIT</code> 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.)}}}}{{defn|Monitor a memory location for memory writes.}}{{glossary end}}
| <code>MONITOR</code>{{efn|name="monitor_explicit_op"|For the <code>MONITOR</code> and <code>MWAIT</code> instructions, older Intel documentation<ref>Intel, [https://math-atlas.sourceforge.net/devel/assembly/sse3.pdf Prescott New Instructions Software Developer’s Guide], order no. 252490-003, june 2003, pages 3-26 and 3-38 list <code>MONITOR</code> and <code>MWAIT</code> with explicit operands. [https://web.archive.org/web/20050509102126/https://math-atlas.sourceforge.net/devel/assembly/sse3.pdf Archived] on 9 May 2005.</ref> lists instruction mnemonics with explicit operands (<code>MONITOR EAX,ECX,EDX</code> and <code>MWAIT EAX,ECX</code>), while newer documentation omits these operands. Assemblers/disassemblers may support one or both of these variants.<ref>Flat Assembler messageboard, [https://board.flatassembler.net/topic.php?p=98558#98558 "BLENDVPS/BLENDVPD/PBLENDVB syntax"], also covers <code>MONITOR</code>/<code>MWAIT</code> mnemonics. [https://web.archive.org/web/20221106013255/https://board.flatassembler.net/topic.php?p=98558#98558 Archived] on 6 Nov 2022.</ref> }}<br />{{nowrap|<code>MONITOR EAX,ECX,EDX</code>}}
| <code>NP 0F 01 C8</code>
| Start monitoring a memory location for memory writes. The memory address to monitor is given by DS:AX/EAX/RAX.{{efn|For <code>MONITOR</code>, the DS: segment can be overridden with a segment prefix.<br />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.<br />The memory location to monitor should have memory type WB (write-back cacheable), or else monitoring may fail.}} <br />ECX and EDX are reserved for extra extension and hint flags, respectively.{{efn|text=As of April 2024, no extensions or hints have been defined for the <code>MONITOR</code> instruction. As such, the instruction requires ECX=0 and ignores EDX.}}
| rowspan="2" {{no2|Usually 0{{efn|name="monitor_ring3"|On some processors, such as Intel [[Xeon Phi]] x200<ref>Intel, [https://web.archive.org/web/20170305002312/https://software.intel.com/en-us/blogs/2016/10/06/intel-xeon-phi-product-family-x200-knl-user-mode-ring-3-monitor-and-mwait Intel® Xeon Phi™ Product Family x200 (KNL) User mode (ring 3) MONITOR and MWAIT] (archived 5 mar 2017)</ref> and AMD K10<ref>AMD, [https://www.amd.com/content/dam/amd/en/documents/archived-tech-docs/programmer-references/31116.pdf BIOS and Kernel Developer’s Guide (BKDG) For AMD Family 10h Processors], order no. 31116, rev 3.62, page 419. [https://www.amd.com/content/dam/amd/en/documents/archived-tech-docs/programmer-references/31116.pdf Archived] on Apr 8, 2024.</ref> and later, there exist documented MSRs that can be used to enable <code>MONITOR</code> and <code>MWAIT</code> to run in Ring 3.}}}}
| rowspan="2" | [[Pentium 4#Prescott|Prescott]],<br />[[Yonah (microprocessor)|Yonah]],<br />[[Bonnell (microarchitecture)|Bonnell]],<br />[[AMD K10|K10]],<br />[[VIA Nano|Nano]]
|-
| <code>MWAIT</code>{{efn|name="monitor_explicit_op"}}<br /><code>MWAIT EAX,ECX</code>
| <code>NP 0F 01 C9</code>
| Wait for a write to a monitored memory location previously specified with <code>MONITOR</code>.{{efn|The wait performed by <code>MWAIT</code>may 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.<br />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 <code>MONITOR</code> before using <code>MWAIT</code> to wait for memory writes again.}}<br />ECX and EAX are used to provide extra extension{{efn|text=The extension flags available for <code>MWAIT</code> in the ECX register are:
{{(!}} class="wikitable sortable"
! Bits !! MWAIT Extension
{{!}}-
{{!}} 0 {{!!}} Treat interrupts as break events, even when masked ([[FLAGS register|EFLAGS]].IF=0). (Available on all non-[[NetBurst]] implementations of <code>MWAIT</code>.)
{{!}}-
{{!}} 1 {{!!}} {{unofficial2|align="left"|Timed MWAIT: end the wait when the [[Time Stamp Counter|TSC]] reaches or exceeds the value in EDX:EBX. (Undocumented, reportedly present in Intel [[Skylake (microarchitecture)|Skylake]] and later Intel processors)<ref>R. Zhang et al, [https://publications.cispa.saarland/3769/1/mwait_sec23.pdf (M)WAIT for It: Bridging the Gap between Microarchitectural and Architectural Side Channels], 3 Jan 2023, page 5. [https://web.archive.org/web/20230105140516/https://publications.cispa.saarland/3769/1/mwait_sec23.pdf Archived] from the original on 5 Jan 2023.</ref>}}
{{!}}-
{{!}} 2 {{!!}} Monitorless MWAIT<ref>Intel, [https://cdrdv2-public.intel.com/819680/architecture-instruction-set-extensions-programming-reference.pdf Architecture Instruction Set Extensions Programming Reference], order no. 319433-052, March 2024, chapter 17. [https://web.archive.org/web/20240407230452/https://cdrdv2-public.intel.com/819680/architecture-instruction-set-extensions-programming-reference.pdf Archived] on Apr 7, 2024.</ref>
{{!}}-
{{!}} 31:3 {{!!}} {{n/a|align="left"|Not used, must be set to zero.}}
{{!)}}
}} and hint{{efn|text=The hint flags available for <code>MWAIT</code> in the EAX register are:
{{(!}} class="wikitable sortable"
! Bits !! MWAIT Hint
{{!}}-
{{!}} 3:0 {{!!}} Sub-state within a C-state (see bits 7:4) (Intel processors only)
{{!}}-
{{!}} 7:4 {{!!}} Target [[ACPI#Processor states|CPU power C-state]] during wait, minus 1. (E.g. 0000b for C1, 0001b for C2, 1111b for C0)
{{!}}-
{{!}} 31:8 {{!!}} {{n/a|align="left"|Not used.}}
{{!)}}
The C-states are processor-specific power states, which do not necessarily correspond 1:1 to [[ACPI#Processor states|ACPI C-states]].
}} flags, respectively. <code>MWAIT</code> hints are commonly used for CPU power management.
|-
! colspan="6" |
|-
| {{glossary}}{{term|SMX}}{{defn|Safer Mode Extensions.<br />Load, authenticate and execute a digitally signed "Authenticated Code Module" as part of Intel [[Trusted Execution Technology]].}}{{glossary end}}
| <code>GETSEC</code>
| {{nowrap|<code>NP 0F 37</code>{{efn|For the <code>GETSEC</code> instruction, the <code>REX.W</code> prefix enables 64-bit addresses for the EXITAC leaf function only - REX prefixes are otherwise permitted but ignored for the instruction.}}}}
| Perform an SMX function. The leaf function to perform is given in EAX.{{efn|text=The leaf functions defined for <code>GETSEC</code> (selected by EAX) are:
{{(!}} class="wikitable sortable"
! EAX !! Function
{{!}}-
{{!}} 0&nbsp;(CAPABILITIES) {{!!}} Report SMX capabilities
{{!}}-
{{!}} 2&nbsp;(ENTERACCES) {{!!}} Enter execution of authenticated code module
{{!}}-
{{!}} 3&nbsp;(EXITAC) {{!!}} Exit execution of authenticated code module
{{!}}-
{{!}} 4 (SENTER) {{!!}} Enter measured environment
{{!}}-
{{!}} 5 (SEXIT) {{!!}} Exit measured environment
{{!}}-
{{!}} 6&nbsp;(PARAMETERS) {{!!}} Report SMX parameters
{{!}}-
{{!}} 7 (SMCTRL) {{!!}} SMX Mode Control
{{!}}-
{{!}} 8 (WAKEUP) {{!!}} Wake up sleeping processors in measured environment
{{!)}}
Any unsupported value in EAX causes an #UD exception.
}}<br />Depending on leaf function, the instruction may take additional arguments in RBX, ECX and EDX.
| {{no2|Usually 0{{efn|text=For <code>GETSEC</code>, most leaf functions are restricted to Ring 0, but the CAPABILITIES (EAX=0) and PARAMETERS (EAX=6) leaf functions are available in Ring 3.}}}}
| {{nowrap|[[Conroe (microprocessor)|Conroe]]/[[Merom (microprocessor)|Merom]],}}<br />[[Zhaoxin|WuDaoKou]],<ref>Guru3D, [https://www.guru3d.com/news-story/via-zhaoxin-x86-4-and-8-core-processors-launched.html VIA Zhaoxin x86 4 and 8-core SoC processors launch], Jan 22, 2018</ref><br />[[Tremont (microarchitecture)|Tremont]]
|-
! colspan="6" |
|-
| {{glossary}}{{term|RDTSCP}}{{defn|Read [[Time Stamp Counter]] and Processor ID.}}{{glossary end}}
| <code>RDTSCP</code>
| <code>0F 01 F9</code>
| Read Time Stamp Counter and processor core ID.{{efn|name="rdtscp_rdpid"}}<br />The TSC value is placed in EDX:EAX and the core ID in ECX.{{efn|text=Unlike the older <code>RDTSC</code> instruction, <code>RDTSCP</code> will delay the TSC read until all previous instructions have retired, guaranteeing ordering with respect to preceding memory loads (but not stores). <code>RDTSCP</code> is not ordered with respect to subsequent instructions, though.}}
| {{yes2|Usually 3{{efn|text=<code>RDTSCP</code> can be run outside Ring 0 only if <code>[[Control_register#CR4|CR4.TSD]]=0</code>.}}}}
| [[AMD K8|K8]],{{efn|Support for <code>RDTSCP</code> was added in stepping F of the AMD K8, and is not available on earlier steppings.}}<br />[[Nehalem (microarchitecture)|Nehalem]],<br />[[Silvermont]],<br />[[VIA Nano|Nano]]
|-
! colspan="6" |
|-
| rowspan="2" | {{glossary}}{{term|POPCNT{{efn|While the <code>POPCNT</code> 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.<br />On AMD processors, it is considered to be a part of the ABM extension, but still has its own CPUID flag.}}}}{{defn|[[Hamming weight|Population Count]].}}{{glossary end}}
| <code>POPCNT r16,r/m16</code><br /><code>POPCNT r32,r/m32</code>
| <code>F3 0F B8 /r</code>
| rowspan="2" | Count the number of bits that are set to 1 in its source argument.
| rowspan="2"  {{yes|3}}
| rowspan="2" | [[AMD K10|K10]],<br />[[Nehalem (microarchitecture)|Nehalem]],<br />[[VIA Nano|Nano 3000]]
|-
| <code>POPCNT r64,r/m64</code>
| <code>F3 REX.W 0F B8 /r</code>
|-
! colspan="6" |
|-
| rowspan="3" |{{glossary}}{{term|[[SSE4#SSE4.2|SSE4.2]]}}{{defn|(non-SIMD)}}{{glossary end}}
| <code>CRC32 r32,r/m8</code>
| <code>F2 0F 38 F0 /r</code>
| rowspan="3" | Accumulate [[Cyclic redundancy check|CRC]] value using the CRC-32C (Castagnoli) polynomial 0x11EDC6F41 (normal form 0x1EDC6F41). This is the polynomial used in iSCSI. In contrast to the more popular one used in Ethernet, its parity is even, and it can thus detect any error with an odd number of changed bits.
| rowspan="3" {{yes|3}}
| rowspan="3" | [[Nehalem (microarchitecture)|Nehalem]],<br />[[Bulldozer (microarchitecture)|Bulldozer]],<br />[[Zhaoxin|ZhangJiang]]
|-
| <code>CRC32 r32,r/m16</code><br /><code>CRC32 r32,r/m32</code>
| <code>F2 0F 38 F1 /r</code>
|-
| <code>CRC32 r64,r/m64</code>
| <code>F2 REX.W 0F 38 F1 /r</code>
|-
! colspan="6" |
|-
| rowspan="4" | {{glossary}}{{term|FSGSBASE}}{{defn|Read/write base address of FS and GS segments from user-mode.<br />Available in 64-bit mode only.}}{{glossary end}}
| <code>RDFSBASE r32</code><br /><code>RDFSBASE r64</code>
| <code>F3 0F AE /0</code><br /><code>F3 REX.W 0F AE /0</code>
| Read base address of FS: segment.
| rowspan="4" {{yes|3}}
| rowspan="4" | [[Ivy Bridge (microarchitecture)|Ivy Bridge]],<br />[[Steamroller (microarchitecture)|Steamroller]],<br />[[Goldmont]],<br />[[Zhaoxin|ZhangJiang]]
|-
| <code>RDGSBASE r32</code><br /><code>RDGSBASE r64</code>
| <code>F3 0F AE /1</code><br /><code>F3 REX.W 0F AE /1</code>
| Read base address of GS: segment.
|-
| <code>WRFSBASE r32</code><br /><code>WRFSBASE r64</code>
| <code>F3 0F AE /2</code><br /><code>F3 REX.W 0F AE /2</code>
| Write base address of FS: segment.
|-
| <code>WRGSBASE r32</code><br /><code>WRGSBASE r64</code>
| <code>F3 0F AE /3</code><br /><code>F3 REX.W 0F AE /3</code>
| Write base address of GS: segment.
|-
! colspan="6" |
|-
| rowspan="4" | {{glossary}}{{term|MOVBE}}{{defn|Move to/from memory with [[Endianness#Byte swapping|byte order swap]].}}{{glossary end}}
| <code>MOVBE r16,m16</code><br /><code>MOVBE r32,m32</code>
| <code>NFx 0F 38 F0 /r</code>
| rowspan="2" | Load from memory to register with byte-order swap.
| rowspan="4" {{yes|3}}
| rowspan="4" | [[Bonnell (microarchitecture)|Bonnell]],<br />[[Haswell (microarchitecture)|Haswell]],<br />[[Jaguar (microarchitecture)|Jaguar]],<br />[[Steamroller (microarchitecture)|Steamroller]],<br />[[Zhaoxin|ZhangJiang]]
|-
| <code>MOVBE r64,m64</code>
| {{nowrap|<code>NP REX.W 0F 38 F0 /r</code>{{efn|name="haswell_movbe"|1=For the <code>MOVBE</code> instruction, encodings that use both the <code>66h</code> prefix and the <code>REX.W</code> prefix will cause #UD on some processors (e.g. Haswell<ref>Intel, [https://web.archive.org/web/20240406115044/https://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/4th-gen-core-family-desktop-specification-update.pdf Desktop 4th Generation Specification Update], order no. 328899-039, apr 2020, see erratum HSD145 on page 56. Archived from the [https://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/4th-gen-core-family-desktop-specification-update.pdf original] on 6 Apr 2024.</ref>) and should therefore be avoided.}}}}
|-
| <code>MOVBE m16,r16</code><br /><code>MOVBE m32,r32</code>
| <code>NFx 0F 38 F1 /r</code>
| rowspan="2" | Store to memory from register with byte-order swap.
|-
| <code>MOVBE m64,r64</code>
| {{nowrap|<code>NP REX.W 0F 38 F1 /r</code>{{efn|name="haswell_movbe"}}}}
|-
! colspan="6" |
|-
| {{glossary}}{{term|INVPCID}}{{defn|Invalidate [[Translation lookaside buffer|TLB]] entries by [[Process-context identifier]].}}{{glossary end}}
| <code>INVPCID reg,m128</code>
| <code>66 0F 38 82 /r</code>
| Invalidate entries in TLB and paging-structure caches based on invalidation type in register{{efn|text=The invalidation types defined for <code>INVPCID</code> (selected by register argument) are:
{{(!}} class="wikitable sortable"
! Value !! Function
{{!}}-
{{!}} 0 {{!!}} Invalidate TLB entries matching PCID and virtual memory address in descriptor, excluding global entries
{{!}}-
{{!}} 1 {{!!}} Invalidate TLB entries matching PCID in descriptor, excluding global entries
{{!}}-
{{!}} 2 {{!!}} Invalidate all TLB entries, including global entries
{{!}}-
{{!}} 3 {{!!}} Invalidate all TLB entries, excluding global entries
{{!)}}
Any unsupported value in the register argument causes a #GP exception.}} and descriptor in m128. The descriptor contains a memory address and a PCID.{{efn|Unlike the older <code>INVLPG</code> instruction, <code>INVPCID</code> will cause a #GP exception if the provided memory address is non-canonical. This discrepancy has been known to cause security issues.<ref>Vulners, [https://vulners.com/xen/XSA-279 x86: DoS from attempting to use INVPCID with a non-canonical addresses], 20 nov 2018</ref>}}

Instruction is serializing on AMD but not Intel CPUs.
| {{no|0}}
| [[Haswell (microarchitecture)|Haswell]],<br />[[Zhaoxin|ZhangJiang]],<br />[[Zen 3]],<br />[[Gracemont (microarchitecture)|Gracemont]]
|-
! colspan="6" |
|-
| rowspan="2" | {{glossary}}{{term|PREFETCHW{{efn|The <code>PREFETCH</code> and <code>PREFETCHW</code> 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!}}}}{{defn|Cache-line prefetch with intent to write.}}{{glossary end}}
| {{nowrap|<code>PREFETCHW m8</code>}}
| <code>0F 0D /1</code>
| Prefetch cache line with intent to write.{{efn|name="prefetch_hint"}}
| rowspan="2" {{yes|3}}
| rowspan="2" | [[AMD K6-2|K6-2]],<br />{{nowrap|([[Pentium 4#Cedar Mill|Cedar Mill]]),{{efn|The opcodes for <code>PREFETCH</code> and <code>PREFETCHW</code> (<code>0F 0D /r</code>) execute as NOPs on Intel CPUs from Cedar Mill (65nm [[Pentium 4]]) onwards, with <code>PREFETCHW</code> gaining prefetch functionality from Broadwell onwards.}}}}<br />[[Silvermont]],<br />[[Broadwell (microarchitecture)|Broadwell]],<br />[[Zhaoxin|ZhangJiang]]
|-
| {{nowrap|<code>PREFETCH m8</code>}}{{efn|The <code>PREFETCH</code> ({{nowrap|<code>0F 0D /0</code>}}) instruction is a [[3DNow!]] instruction, present on all processors with 3DNow! but not necessarily on processors with the PREFETCHW extension.<br />On AMD CPUs with PREFETCHW, opcode {{nowrap|<code>0F 0D /0</code>}} as well as opcodes {{nowrap|<code>0F 0D /2../7</code>}} are all documented to be performing prefetch.<br />On Intel processors with PREFETCHW, these opcodes are documented as performing reserved-NOPs<ref>Intel, [http://kib.kiev.ua/x86docs/Intel/SDMs/325384-078.pdf Intel® 64 and IA-32 Architectures Software Developer’s Manual] volume 3, order no. 325384-078, december 2022, chapter 23.15</ref> (except {{nowrap|<code>0F 0D /2</code>}} being {{nowrap|<code>PREFETCHWT1 m8</code>}} on {{nowrap|[[Xeon Phi]]}} only) – third party testing<ref name="cattius_0f0d">Catherine Easdon, [https://www.cattius.com/images/thesis-unsigned.pdf Undocumented CPU Behaviour on x86 and RISC-V Microarchitectures: A Security Perspective], 10 May 2019, page 39</ref> indicates that some or all of these opcodes may be performing prefetch on at least some Intel Core CPUs.}}
| <code>0F 0D /0</code>
| Prefetch cache line.{{efn|name="prefetch_hint"}}
|-
! colspan="6" |
|-
| rowspan="2" | {{glossary}}{{term|[[Intel ADX|ADX]]}}{{defn|Enhanced variants of add-with-carry.}}{{glossary end}}
| {{nowrap|<code>ADCX r32,r/m32</code>}}<br /><code>ADCX r64,r/m64</code>
| <code>66 0F 38 F6 /r</code><br />{{nowrap|<code>66 REX.W 0F 38 F6 /r</code>}}
| Add-with-carry. Differs from the older <code>ADC</code> instruction in that it leaves flags other than <code>EFLAGS.CF</code> unchanged.
| rowspan="2" {{yes|3}}
| rowspan="2" | [[Broadwell (microarchitecture)|Broadwell]],<br />[[Zen (first generation)|Zen 1]],<br />[[Zhaoxin|ZhangJiang]],<br />[[Gracemont (microarchitecture)|Gracemont]]
|-
| {{nowrap|<code>ADOX r32,r/m32</code>}}<br /><code>ADOX r64,r/m64</code>
| <code>F3 0F 38 F6 /r</code><br />{{nowrap|<code>F3 REX.W 0F 38 F6 /r</code>}}
| Add-with-carry, with the overflow-flag <code>EFLAGS.OF</code> serving as carry input and output, with other flags left unchanged.
|-
! colspan="6" |
|-
| rowspan="2" | {{glossary}}{{term|SMAP}}{{defn|[[Supervisor Mode Access Prevention]].<br />Repurposes the <code>EFLAGS.AC</code> (alignment check) flag to a flag that prevents access to user-mode memory while in ring 0, 1 or 2.}}{{glossary end}}
| <code>CLAC</code>
| <code>NP 0F 01 CA</code>
| Clear <code>EFLAGS.AC</code>.
| rowspan="2" {{no|0}}
| rowspan="2" | [[Broadwell (microarchitecture)|Broadwell]],<br />[[Goldmont]],<br />[[Zen (first generation)|Zen 1]],<br />[[Zhaoxin|LuJiaZui]]{{efn|name=lujiazui_step2|text=The SMAP, PKU and RDPID instruction set extensions are supported on stepping 2<ref>Instlatx64, [http://users.atw.hu/instlatx64/CentaurHauls/CentaurHauls00307B2_KX6000_01_CPUID.txt Zhaoxin Kaixian KX-6000G CPUID dump], May 15, 2023</ref>  and later of [[Zhaoxin]] LuJiaZui, but not on earlier steppings.}}
|-
| <code>STAC</code>
| <code>NP 0F 01 CB</code>
| Set <code>EFLAGS.AC</code>.
|-
! colspan="6" |
|-
| {{glossary}}{{term|CLFLUSHOPT}}{{defn|Optimized Cache Line Flush.}}{{glossary end}}
| {{nowrap|<code>CLFLUSHOPT m8</code>}}
| <code>NFx 66 0F AE /7</code>
| Flush cache line.<br />Differs from the older <code>CLFLUSH</code> instruction in that it has more relaxed ordering rules with respect to memory stores and other cache line flushes, enabling improved performance.
| {{yes|3}}
| [[Skylake (microarchitecture)|Skylake]],<br />[[Goldmont]],<br />[[Zen (first generation)|Zen 1]]
|-
! colspan="6" |
|-
| {{glossary}}{{term|PREFETCHWT1}}{{defn|Cache-line prefetch into L2 cache with intent to write.}}{{glossary end}}
| <code>PREFETCHWT1 m8</code>
| <code>0F 0D /2</code>
| Prefetch data with T1 locality hint (fetch into L2 cache, but not L1 cache) and intent-to-write hint.{{efn|name="prefetch_hint"}}
| {{yes|3}}
| {{nowrap|[[Xeon Phi#Knights Landing|Knights Landing]],}}<br />[[Zhaoxin|YongFeng]]
|-
! colspan="6" |
|-
| rowspan="2" | {{glossary}}{{term|PKU}}{{defn|Protection Keys for user pages.}}{{glossary end}}
| <code>RDPKRU</code>
| <code>NP 0F 01 EE</code>
| Read User Page Key register into EAX.
| rowspan="2" {{yes|3}}
| rowspan="2" | [[Skylake (microarchitecture)|Skylake-X]],<br />[[Comet Lake]],<br />[[Gracemont (microarchitecture)|Gracemont]],<br />[[Zen 3]],<br />[[Zhaoxin|LuJiaZui]]{{efn|name=lujiazui_step2}}
|-
| <code>WRPKRU</code>
| <code>NP 0F 01 EF</code>
| Write data from EAX into User Page Key Register, and perform a Memory Fence.
|-
! colspan="6" |
|-
| {{glossary}}{{term|CLWB}}{{defn|Cache Line Writeback to memory.}}{{glossary end}}
| <code>CLWB m8</code>
| {{nowrap|<code>NFx 66 0F AE /6</code>}}
| Write one cache line back to memory without invalidating the cache line.
| {{yes|3}}
| [[Skylake (microarchitecture)|Skylake-X]],<br />[[Zen 2]],<br />[[Tiger Lake]],<br />[[Tremont (microarchitecture)|Tremont]]
|-
! colspan="6" |
|-
| {{glossary}}{{term|RDPID}}{{defn|Read processor core ID.}}{{glossary end}}
| <code>RDPID r32</code>
| <code>F3 0F C7 /7</code>
| Read processor core ID into register.{{efn|name="rdtscp_rdpid"|text=The "core ID" value read by <code>RDTSCP</code> and <code>RDPID</code> is actually the <code>TSC_AUX</code> MSR (MSR <code>C000_0103h</code>). Whether this value actually corresponds to a processor ID is a matter of operating system convention.}}
| {{yes|3{{efn|text=Unlike the older <code>RDTSCP</code> instruction which can also be used to read the processor ID, user-mode <code>RDPID</code> is not disabled by <code>[[Control_register#CR4|CR4.TSD]]=1</code>.}}}}
| {{nowrap|[[Goldmont Plus]],}}<br />[[Zen 2]],<br />[[Ice Lake (microprocessor)|Ice Lake]],<br />[[Zhaoxin|LuJiaZui]]{{efn|name=lujiazui_step2}}
|-
! colspan="6" |
|-
| {{glossary}}{{term|MOVDIRI}}{{defn|Move to memory as Direct Store.}}{{glossary end}}
| <code>MOVDIRI m32,r32</code><br /><code>MOVDIRI m64,r64</code>
| <code>NP 0F 38 F9 /r</code><br />{{nowrap|<code>NP REX.W 0F 38 F9 /r</code>}}
| Store to memory using Direct Store (memory store that is not cached or write-combined with other stores).
| {{yes|3}}
| [[Tiger Lake]],<br />[[Tremont (microarchitecture)|Tremont]],<br >[[Zen 5]]
|-
! colspan="6" |
|-
| {{glossary}}{{term|MOVDIR64B}}{{defn|Move 64 bytes as Direct Store.}}{{glossary end}}
| {{nowrap|<code>MOVDIR64B reg,m512</code>}}
| <code>66 0F 38 F8 /r</code>
| Move 64 bytes of data from m512 to address given by ES:reg. The 64-byte write is done atomically with Direct Store.{{efn|For <code>MOVDIR64</code>, the destination address given by ES:reg must be 64-byte aligned.<br />The operand size for the register argument is given by the address size, which may be overridden by the <code>67h</code> prefix.<br />The 64-byte memory source argument does not need to be 64-byte aligned, and is not guaranteed to be read atomically.}}
| {{yes|3}}
| [[Tiger Lake]],<br />[[Tremont (microarchitecture)|Tremont]],<br >[[Zen 5]]
|-
! colspan="6" |
|-
| {{glossary}}{{term|WBNOINVD}}{{defn|Whole Cache Writeback without invalidate.}}{{glossary end}}
| <code>WBNOINVD</code>
| <code>F3 0F 09</code>
| Write back all dirty cache lines to memory without invalidation.{{efn|The <code>WBNOINVD</code> instruction will execute as <code>WBINVD</code> if run on a system that doesn't support the WBNOINVD extension.<br /><code>WBINVD</code> differs from <code>WBNOINVD</code> in that <code>WBINVD</code> will invalidate all cache lines after writeback.}} Instruction is serializing.
| {{no|0}}
| [[Zen 2]],<br />[[Ice Lake (microprocessor)|Ice Lake-SP]]
|-
! colspan="6" |
|-
| rowspan="2" | {{glossary}}{{term|PREFETCHI}}{{defn|Instruction prefetch.}}{{glossary end}}
| <code>PREFETCHIT0 m8</code>
| <code>0F 18 /7</code>
| Prefetch code to all levels of the cache hierarchy.{{efn|name=prefetchi_note|text=In initial implementations, the <code>PREFETCHIT0</code> and <code>PREFETCHIT1</code> instructions will perform code prefetch only when using the RIP-relative addressing mode and act as NOPs otherwise.<br/>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.}}
| rowspan="2" {{yes|3}}
| rowspan="2" | [[Zen 5]],<br />{{nowrap|[[Granite Rapids]]}}
|-
| <code>PREFETCHIT1 m8</code>
| <code>0F 18 /6</code>
| Prefetch code to all levels of the cache hierarchy except first-level cache.{{efn|name=prefetchi_note}}
|}
{{notelist}}{{vpad}}

==== Added with other Intel-specific extensions ====

{{sticky header}}
{| class="wikitable sortable sticky-header"
! Instruction Set Extension !! Instruction<br />mnemonics !! Opcode !! Instruction description !! [[Protection ring|Ring]] !! Added in
|-
! colspan="6" |
|-
| rowspan="2" | {{glossary}}{{term|SSE2 [[Branch (computer science)#Branch prediction hints|branch hints]]}}{{defn|Instruction prefixes that can be used with the <code>Jcc</code> instructions to provide branch taken/not-taken hints.}}{{glossary end}}
| <code>HWNT</code>,<br/><code>hint-not-taken</code>{{efn|name=wmt_hint|1=The branch hint mnemonics <code>HWNT</code> and <code>HST</code> are listed in early [[Pentium 4#Willamette|Willamette]] documentation only<ref>Intel, [https://web.archive.org/web/20050205035023/http://developer.intel.com/design/processor/WmtSDG.pdf Willamette Processor Software Developer’s Guide], order no. 245355-001, feb 2000, section 3.5.3, page 294 - lists <code>HWNT</code>/<code>HST</code> mnemonics for the branch hint prefixes. Archived from the [http://developer.intel.com/design/processor/WmtSDG.pdf original] on 5 Feb 2005.</ref> - later Intel documentation lists the branch hint prefixes without assigning them a mnemonic.<ref>Intel, [https://kib.kiev.ua/x86docs/Intel/SDMs/325462-083.pdf Software Developer's Manual], order no. 325462-083, March 2024 - volume 1, chapter 11.4.5, page 281 and volume 2A, chapter 2.1.1, page 525.</ref><p>Intel XED uses the mnemonics {{nowrap|<code>hint-taken</code>}} and {{nowrap|<code>hint-not-taken</code>}} for these branch hints.<ref>Intel XED source code, [https://github.com/intelxed/xed/blob/d4d502003bfff51c55c2808804301a62878d7cc8/src/dec/xed-disas.c#L325 src/dec/xed-disas.c, line 325], 11 Nov 2024. [https://web.archive.org/web/20241124214618/https://github.com/intelxed/xed/blob/d4d502003bfff51c55c2808804301a62878d7cc8/src/dec/xed-disas.c#L325 Archived] on 24 Nov 2024.</ref></p>}}
| <code>2E</code>{{efn|name=wmt_prefix|The <code>2E</code> and <code>3E</code> prefixes are interpreted as branch hints only when used with the <code>Jcc</code> conditional branch instructions (opcodes <code>70..7F</code> and {{nowrap|<code>0F 80..8F</code>}}) - 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 <code>CS:</code> and <code>DS:</code>, respectively). On processors that don't support branch hints, these prefixes are accepted but ignored when used with <code>Jcc</code>.}}
| Instruction prefix: branch hint weakly not taken.
| rowspan="2" {{Yes|3}}
| rowspan="2" | [[Pentium 4]],{{efn|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.}}<br />[[Meteor Lake]]<ref>Intel, [https://cdrdv2-public.intel.com/814198/248966-Optimization-Reference-Manual-V1-050.pdf Intel 64 and IA-32 Architectures Optimization Reference Manual: Volume 1], order no. 248966-050US, April 2024, chapter 2.1.1.1, page 46. [https://web.archive.org/web/20250105153741/https://cdrdv2-public.intel.com/814198/248966-Optimization-Reference-Manual-V1-050.pdf Archived] on 25 Jan 2025.</ref>
|-
| <code>HST</code>,<br/><code>hint-taken</code>{{efn|name=wmt_hint}}
| <code>3E</code>{{efn|name=wmt_prefix}}
| Instruction prefix: branch hint strongly taken.
|-
! colspan="6" |
|-
| rowspan="3" | {{glossary}}{{term|SGX}}{{defn|[[Software Guard Extensions]].<br />Set up an encrypted enclave in which a guest can execute code that a compromised or malicious host cannot inspect or tamper with.}}{{glossary end}}
| <code>ENCLS</code>
| {{nowrap|<code>NP 0F 01 CF</code>}}
| Perform an SGX Supervisor function. The function to perform is given in EAX{{efn|text=The leaf functions defined for <code>ENCLS</code> (selected by EAX) are:
{{(!}} class="wikitable sortable"
! EAX !! Function
{{!}}-
{{!}} 0&nbsp;(ECREATE) {{!!}} Create an enclave
{{!}}-
{{!}} 1&nbsp;(EADD) {{!!}} Add a page
{{!}}-
{{!}} 2&nbsp;(EINIT) {{!!}} Initialize an enclave
{{!}}-
{{!}} 3&nbsp;(EREMOVE) {{!!}} Remove a page from EPC (Enclave Page Cache)
{{!}}-
{{!}} 4&nbsp;(EDBGRD) {{!!}} Read data by debugger
{{!}}-
{{!}} 5&nbsp;(EDBGWR) {{!!}} Write data by debugger
{{!}}-
{{!}} 6&nbsp;(EEXTEND) {{!!}} Extend EPC page measurement
{{!}}-
{{!}} 7&nbsp;(ELDB) {{!!}} Load an EPC page as blocked
{{!}}-
{{!}} 8&nbsp;(ELDU) {{!!}} Load an EPC page as unblocked
{{!}}-
{{!}} 9&nbsp;(EBLOCK) {{!!}} Block an EPC page
{{!}}-
{{!}} A&nbsp;(EPA) {{!!}} Add version array
{{!}}-
{{!}} B&nbsp;(EWB) {{!!}} Writeback/invalidate EPC page
{{!}}-
{{!}} C&nbsp;(ETRACK) {{!!}} Activate EBLOCK checks
{{!}}-
! colspan="2" {{!}} Added with SGX2
{{!}}-
{{!}} D&nbsp;(EAUG) {{!!}} Add page to initialized enclave
{{!}}-
{{!}} E&nbsp;(EMODPTR) {{!!}} Restrict permissions of EPC page
{{!}}-
{{!}} F&nbsp;(EMODT) {{!!}} Change type of EPC page
{{!}}-
! colspan="2" {{!}} Added with OVERSUB<ref name="sgx_oversub" />
{{!}}-
{{!}} 10&nbsp;(ERDINFO) {{!!}} Read EPC page type/status info
{{!}}-
{{!}} 11&nbsp;(ETRACKC) {{!!}} Activate EBLOCK checks
{{!}}-
{{!}} 12&nbsp;(ELDBC) {{!!}} Load EPC page as blocked with enhanced error reporting
{{!}}-
{{!}} 13&nbsp;(ELDUC) {{!!}} Load EPC page as unblocked with enhanced error reporting
{{!}}-
! colspan="2" {{!}} Other
{{!}}-
{{!}} 18&nbsp;(EUPDATESVN) {{!!}} Update SVN (Security Version Number) after live microcode update<ref>Intel, [https://cdrdv2-public.intel.com/648682/648682%20Runtime_Microcode_Update_with_Intel_SGX_rev1p0.pdf Runtime Microcode Updates with Intel® Software Guard Extensions], sep 2021, order no. 648682 rev 1.0. [https://web.archive.org/web/20230331103022/https://cdrdv2-public.intel.com/648682/648682%20Runtime_Microcode_Update_with_Intel_SGX_rev1p0.pdf Archived] from the original on 31 mar 2023.</ref>
{{!)}}
Any unsupported value in EAX causes a #GP exception.
}} — depending on function, the instruction may take additional input operands in RBX, RCX and RDX.

Depending on function, the instruction may return data in RBX and/or an error code in EAX.
| {{no|0}}
| rowspan="3" | {{glossary}}{{term|SGX1}}{{defn|[[Skylake (microarchitecture)|Skylake]],{{efn|SGX is deprecated on desktop/laptop processors from 11th generation ([[Rocket Lake]], [[Tiger Lake]]) onwards,<ref>Intel, [https://cdrdv2-public.intel.com/634648/634648-004.pdf 11th Generation Intel® Core™ Processor Desktop Datasheet, Volume 1], may 2022, order no. 634648-004, section 3.5, page 65. [https://web.archive.org/web/20250219182337/https://cdrdv2-public.intel.com/634648/634648-004.pdf Archived] on 19 Feb 2025.</ref> but continues to be available on [[Xeon]]-branded server parts.}}<br />[[Goldmont Plus]]}}{{term|SGX2}}{{defn|{{nowrap|[[Goldmont Plus]],}}<br />[[Ice Lake (microprocessor)|Ice Lake-SP]]<ref>Intel, [https://www.intel.com/content/www/us/en/support/articles/000058764/software/intel-security-products.html Which Platforms Support Intel® Software Guard Extensions (Intel® SGX) SGX2?] [https://archive.today/20220505112200/https://www.intel.com/content/www/us/en/support/articles/000058764/software/intel-security-products.html Archived] on 5 May 2022.<!-- archived with archive.today because Intel's website does strange stuff that messes up attempts to archive with archive.org --></ref>}}{{term|OVERSUB<ref name="sgx_oversub">Intel, [https://cdrdv2-public.intel.com/671471/sgx-oversubscription.pdf Intel® Software Guard Extensions (Intel® SGX) Architecture for Oversubscription of Secure Memory in a Virtualized Environment], 25 Jun 2017. [https://web.archive.org/web/20230331203252/https://cdrdv2-public.intel.com/671471/sgx-oversubscription.pdf Archived] on 31 Mar 2023.</ref>}}{{defn|[[Ice Lake (microprocessor)|Ice Lake-SP]],<br />[[Tremont (microarchitecture)|Tremont]]}}{{glossary end}}
|-
| <code>ENCLU</code>
| {{nowrap|<code>NP 0F 01 D7</code>}}
| Perform an SGX User function. The function to perform is given in EAX{{efn|text=The leaf functions defined for <code>ENCLU</code> (selected by EAX) are:
{{(!}} class="wikitable sortable"
! EAX !! Function
{{!}}-
{{!}} 0 (EREPORT) {{!!}} Create a cryptographic report
{{!}}-
{{!}} 1 (EGETKEY) {{!!}} Create a cryptographic key
{{!}}-
{{!}} 2 (EENTER) {{!!}} Enter an Enclave
{{!}}-
{{!}} 3 (ERESUME) {{!!}} Re-enter an Enclave
{{!}}-
{{!}} 4 (EEXIT) {{!!}} Exit an Enclave
{{!}}-
! colspan="2" {{!}} Added with SGX2
{{!}}-
{{!}} 5 (EACCEPT) {{!!}} Accept changes to EPC page
{{!}}-
{{!}} 6 (EMODPE) {{!!}} Extend EPC page permissions
{{!}}-
{{!}} 7&nbsp;(EACCEPTCOPY) {{!!}} Initialize pending page
{{!}}-
! colspan="2" {{!}} Added with TDX<ref name="intel_tdx">Intel, [https://cdrdv2-public.intel.com/733582/intel-tdx-cpu-architectural-specification.pdf Trust Domain CPU Architectural Extensions], order no. 343754-002, may 2021. [https://web.archive.org/web/20221226025041/https://cdrdv2-public.intel.com/733582/intel-tdx-cpu-architectural-specification.pdf Archived] on 26 Dec 2022.</ref>
{{!}}-
{{!}} 8&nbsp;(EVERIFYREPORT2) {{!!}} Verify a cryptographic report of a trust domain
{{!}}-
! colspan="2" {{!}} Added with AEX-Notify<ref>Intel, [https://cdrdv2-public.intel.com/736463/aex-notify-white-paper-public.pdf Asynchronous Enclave Exit Notify and the EDECCSSA User Leaf Function], 30 Jun 2022. [https://web.archive.org/web/20221121073302/https://cdrdv2-public.intel.com/736463/aex-notify-white-paper-public.pdf Archived] on 21 Nov 2022.</ref>
{{!}}-
{{!}} 9&nbsp;(EDECCSSA) {{!!}} Decrement TCS.CSSA
{{!}}-
! colspan="2" {{!}} Added with 256BITSGX<ref>Intel, [https://cdrdv2-public.intel.com/851355/319433-057-architecture-instruction-set-extensions-programming-reference.pdf Intel Architecture Instruction Set Extensions and Future Features] order no. 319433-057, March 2025, chapter 14. [https://web.archive.org/web/20250406100407/https://cdrdv2-public.intel.com/851355/319433-057-architecture-instruction-set-extensions-programming-reference.pdf Archived] on 6 Apr 2025.</ref>
{{!}}-
{{!}} A&nbsp;(EREPORT2) {{!!}} Create a cryptographic report that contains SHA384 measurements
{{!}}-
{{!}} B&nbsp;(EGETKEY256) {{!!}} Create a 256-bit cryptographic key
{{!)}}
Any unsupported value in EAX causes a #GP exception.<br />The <code>EENTER</code> and <code>ERESUME</code> functions cannot be executed inside an SGX enclave – the other functions can only be executed inside an enclave.
}} — depending on function, the instruction may take additional input operands in RBX, RCX and RDX.

Depending on function, the instruction may return data/status information in EAX and/or RCX.
| {{yes|3{{efn|<code>ENCLU</code> can only be executed in ring 3, not rings 0/1/2.}}}}
|-
| <code>ENCLV</code>
| {{nowrap|<code>NP 0F 01 C0</code>}}
| Perform an SGX Virtualization function. The function to perform is given in EAX{{efn|text=The leaf functions defined for <code>ENCLV</code> (selected by EAX) are:
{{(!}} class="wikitable sortable"
! EAX !! Function
{{!}}-
! colspan="2" {{!}} Added with OVERSUB<ref name="sgx_oversub" />
{{!}}-
{{!}} 0&nbsp;(EDECVIRTCHILD) {{!!}} Decrement VIRTCHILDCNT in SECS
{{!}}-
{{!}} 1&nbsp;(EINCVIRTCHILD) {{!!}} Increment VIRTCHILDCNT in SECS
{{!}}-
{{!}} 2&nbsp;(ESETCONTEXT) {{!!}} Set ENCLAVECONTEXT field in SECS
{{!)}}
Any unsupported value in EAX causes a #GP exception.<br />The <code>ENCLV</code> instruction is only present on systems that support the EPC Oversubscription Extensions to SGX ("OVERSUB").
}} — depending on function, the instruction may take additional input operands in RBX, RCX and RDX.

Instruction returns status information in EAX.
| {{no|0{{efn|<code>ENCLV</code> is only available if Intel VMX operation is enabled with <code>VMXON</code>, and will produce #UD otherwise.}}}}
|-
! colspan="6" |
|-
| {{glossary}}{{term|PTWRITE}}{{defn|Write data to a Processor Trace Packet.}}{{glossary end}}
| <code>PTWRITE r/m32</code><br /><code>PTWRITE r/m64</code>
| <code>F3 0F AE /4</code><br />{{nowrap|<code>F3 REX.W 0F AE /4</code>}}
| Read data from register or memory to encode into a PTW packet.{{efn|For <code>PTWRITE</code>, the write to the Processor Trace Packet will only happen if a set of enable-bits (the "TriggerEn", "ContextEn", "FilterEn" bits of the <code>RTIT_STATUS</code> MSR and the "PTWEn" bit of the <code>RTIT_CTL</code> MSR) are all set to 1.<br />The <code>PTWRITE</code> instruction is indicated in the SDM to cause an #UD exception if the 66h instruction prefix is used, regardless of other prefixes.}}
| {{yes|3}}
| [[Kaby Lake]],<br />{{nowrap|[[Goldmont Plus]]}}
|-
! colspan="6" |
|-
| {{glossary}}{{term|PCONFIG}}{{defn|Platform Configuration, including TME-MK ("Total Memory Encryption – Multi-Key") and TSE ("Total Storage Encryption").}}{{glossary end}}
| <code>PCONFIG</code>
| <code>NP 0F 01 C5</code>
| Perform a platform feature configuration function. The function to perform is specified in EAX{{efn|text=The leaf functions defined for <code>PCONFIG</code> (selected by EAX) are:
{{(!}} class="wikitable sortable"
! EAX !! Function
{{!}}-
{{!}} 0 {{!!}} MKTME_KEY_PROGRAM:<br />Program key and encryption mode to use with an TME-MK Key ID.
{{!}}-
! colspan="2" {{!}} Added with TSE
{{!}}-
{{!}} 1 {{!!}} TSE_KEY_PROGRAM:<br />Direct key programming for TSE.
{{!}}-
{{!}} 2 {{!!}} TSE_KEY_PROGRAM_WRAPPED:<br />Wrapped key programming for TSE.
{{!)}}
Any unsupported value in EAX causes a #GP(0) exception.}} - depending on function, the instruction may take additional input operands in RBX, RCX and RDX.

If the instruction fails, it will set EFLAGS.ZF=1 and return an error code in EAX. If it is successful, it sets EFLAGS.ZF=0 and EAX=0.
| {{no|0}}
| [[Ice Lake (microprocessor)|Ice Lake-SP]]
|-
! colspan="6" |
|-
| {{glossary}}{{term|CLDEMOTE}}{{defn|Cache Line Demotion Hint.}}{{glossary end}}
| <code>CLDEMOTE m8</code>
| <code>NP 0F 1C /0</code>
| Move cache line containing m8 from CPU L1 cache to a more distant level of the cache hierarchy.{{efn|For <code>CLDEMOTE</code>, the cache level that it will demote a cache line to is implementation-dependent.<br />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.<br />On systems that do not support the CLDEMOTE extension, it executes as a NOP.}}
| {{yes|3}}
| ([[Tremont (microarchitecture)|Tremont]]),<br />([[Alder Lake]]),<br />{{nowrap|[[Sapphire Rapids (microprocessor)|Sapphire Rapids]]{{efn|text=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.<ref>{{Cite tweet |user=InstLatX64 |number=1521562151848132609 |date=May 3, 2022 |title=The CLDEMOTE Story |access-date=2023-01-23 |language=en}}</ref><br />As of April 2023, the CPUID feature bit for CLDEMOTE has been observed to be set for Sapphire Rapids.<ref>{{Cite tweet |user=Instlatx64 |number=1648008172974514193 |date=Apr 17, 2023 |title=20-Core Intel Xeon w7-2475X (SapphireRapids-64L) 806F8 CPUID dump |access-date=2023-04-20 |language=en}}</ref>}}}}
|-
! colspan="6" |
|-
| rowspan="3" | {{glossary}}{{term|WAITPKG}}{{defn|User-mode memory monitoring and waiting.}}{{glossary end}}
| <code>UMONITOR r16/32/64</code>
| <code>F3 0F AE /6</code>
| Start monitoring a memory location for memory writes. The memory address to monitor is given by the register argument.{{efn|For <code>UMONITOR</code>, the operand size of the address argument is given by the address size, which may be overridden by the <code>67h</code> prefix. The default segment used is DS:, which can be overridden with a segment prefix.}}
| {{yes|3}}
| rowspan="3" | [[Tremont (microarchitecture)|Tremont]],<br />[[Alder Lake]]
|-
| <code>UMWAIT r32</code><br /><code>UMWAIT r32,EDX,EAX</code>
| <code>F2 0F AE /6</code>
| Timed wait for a write to a monitored memory location previously specified with <code>UMONITOR</code>. In the absence of a memory write, the wait will end when either the TSC reaches the value specified by EDX:EAX or the wait has been going on for an OS-controlled maximum amount of time.{{efn|name=umwait_ctrl|For the <code>UMWAIT</code> and <code>TPAUSE</code> instructions, the operating system can use the <code>IA32_UMWAIT_CONTROL</code> MSR to limit the maximum amount of time that a single <code>UMWAIT</code>/<code>TPAUSE</code> invocation is permitted to wait. The <code>UMWAIT</code> and <code>TPAUSE</code> instructions will set <code>RFLAGS.CF</code> to 1 if they reached the <code>IA32_UMWAIT_CONTROL</code>-defined time limit and 0 otherwise.}}
| rowspan="2" {{yes2|Usually 3{{efn|name="waitpkg_cr4tsd"|text=<code>TPAUSE</code> and <code>UMWAIT</code> can be run outside Ring 0 only if <code>[[Control_register#CR4|CR4.TSD]]=0</code>.}}}}
|-
| <code>TPAUSE r32</code><br /><code>TPAUSE r32,EDX,EAX</code>
| <code>66 0F AE /6</code>
| Wait until the [[Time Stamp Counter]] reaches the value specified in EDX:EAX.{{efn|name=umwait_ctrl}}

The register argument to the <code>UMWAIT</code> and <code>TPAUSE</code> instructions specifies extra flags to control the operation of the instruction.{{efn|name=umwait_flags|text=For the register argument to the <code>UMWAIT</code> and <code>TPAUSE</code> instructions, the following flag bits are supported:{{(!}} class="wikitable sortable"
! Bits !! Usage
{{!}}-
{{!}} 0 {{!!}} Preferred optimization state.
* 0 = C0.2 (slower wakeup, improves performance of other SMT threads on same core)
* 1 = C0.1 (faster wakeup)
{{!}}-
{{!}} 31:1 {{!!}} {{n/a|(Reserved)}}
{{!)}}}}
|-
! colspan="6" |
|-
| {{glossary}}{{term|SERIALIZE}}{{defn|Instruction Execution Serialization.}}{{glossary end}}
| <code>SERIALIZE</code>
| <code>NP 0F 01 E8</code>
| Serialize instruction fetch and execution.{{efn|While serialization can be performed with older instructions such as e.g. <code>CPUID</code> and <code>IRET</code>, these instructions perform additional functions, causing side-effects and reduced performance when stand-alone instruction serialization is needed. (<code>CPUID</code> additionally has the issue that it causes a mandatory #VMEXIT when executed under virtualization, which causes a very large overhead.) The <code>SERIALIZE</code> instruction performs serialization only, avoiding these added costs.}}
| {{yes|3}}
| [[Alder Lake]]
|-
! colspan="6" |
|-
| {{glossary}}{{term|HRESET}}{{defn|Processor History Reset.}}{{glossary end}}
| <code>HRESET imm8</code>
| {{nowrap|<code>F3 0F 3A F0 C0 ''ib''</code>}}
| Request that the processor reset selected components of hardware-maintained prediction history. A bitmap of which components of the CPU's prediction history to reset is given in EAX (the imm8 argument is ignored).{{efn|text=A bitmap of CPU history components that can be reset through <code>HRESET</code> is provided by {{nowrap|1=CPUID.(EAX=20h,ECX=0):EBX.}}<br />As of July 2023, the following bits are defined:
{{(!}} class="wikitable sortable"
! Bit !! Usage
{{!}}-
{{!}} 0 {{!!}} Intel Thread Director history
{{!}}-
{{!}} 31:1 {{!!}} {{n/a|(Reserved)}}
{{!)}}}}
| {{no|0}}
| [[Alder Lake]]
|-
! colspan="6" |
|-
| rowspan="5" | {{glossary}}{{term|UINTR}}{{defn|User Interprocessor interrupt.<br />Available in 64-bit mode only.}}{{glossary end}}
| <code>SENDUIPI reg</code>
| <code>F3 0F C7 /6</code>
| Send Interprocessor User Interrupt.{{efn|The register argument to <code>SENDUIPI</code> is an index to pick an entry from the UITT (User-Interrupt Target Table, a table specified by the new <code>UINTR_TT</code> and <code>UINT_MISC</code> [[Model-specific register|MSRs.]])}}
| rowspan="5" {{yes|3}}
| rowspan="5" | [[Sapphire Rapids (microprocessor)|Sapphire Rapids]]
|-
| <code>UIRET</code>
| <code>F3 0F 01 EC</code>
| User Interrupt Return.

Pops [[Program counter|RIP]], [[FLAGS register|RFLAGS]] and [[Stack register|RSP]] off the stack, in that order.{{efn|text=On [[Sapphire Rapids (microprocessor)|Sapphire Rapids]] processors, the <code>UIRET</code> instruction always sets UIF (User Interrupt Flag) to 1. On [[Sierra Forest]] and later processors, <code>UIRET</code> will set UIF to the value of bit 1 of the value popped off the stack for RFLAGS - this functionality is indicated by <code>CPUID.(EAX=7,ECX=1):EDX[17]</code>.}}
|-
| <code>TESTUI</code>
| <code>F3 0F 01 ED</code>
| Test User Interrupt Flag.<br />Copies UIF to [[FLAGS register|EFLAGS]].CF .
|-
| <code>CLUI</code>
| <code>F3 0F 01 EE</code>
| Clear User Interrupt Flag.
|-
| <code>STUI</code>
| <code>F3 0F 01 EF</code>
| Set User Interrupt Flag.
|-
! colspan="6" |
|-
| rowspan="2" | {{glossary}}{{term|ENQCMD}}{{defn|Enqueue Store.<p>Part of Intel DSA ([[Sapphire Rapids#Accelerators|Data Streaming Accelerator]] Architecture).<ref>Intel, [https://cdrdv2-public.intel.com/671116/341204-intel-data-streaming-accelerator-spec.pdf Intel Data Streaming Accelerator Architecture Specification], order no. 341204-004, Sep 2022, pages 13 and 23. [https://web.archive.org/web/20230720233510/https://cdrdv2-public.intel.com/671116/341204-intel-data-streaming-accelerator-spec.pdf Archived] on 20 Jul 2023.</ref></p>}}{{glossary end}}
| <code>ENQCMD reg,m512</code>
| <code>F2 0F 38 F8 /r</code>
| Enqueue Command. Reads a 64-byte "command data" structure from memory (m512 argument) and writes atomically to a memory-mapped Enqueue Store device (register argument provides the memory address of this device, using ES segment and requiring 64-byte alignment.{{efn|text=For <code>ENQCMD</code> and <code>EMQCMDS</code>, the operand-size of the register argument is given by the current address-size, which can be overridden with the <code>67h</code> prefix.}}) Sets ZF=0 to indicate that device accepted the command, or ZF=1 to indicate that command was not accepted (e.g. queue full or the memory location was not an Enqueue Store device.)
| {{yes|3}}
| rowspan="2" | {{nowrap|[[Sapphire Rapids (microprocessor)|Sapphire Rapids]]}}
|-
| {{nowrap|<code>ENQCMDS reg,m512</code>}}
| <code>F3 0F 38 F8 /r</code>
| Enqueue Command Supervisor. Differs from <code>ENQCMD</code> in that it can place an arbitrary PASID (process address-space identifier) and a privilege-bit in the "command data" to enqueue.
| {{no|0}}
|-
! colspan="6" |
|-
| {{glossary}}{{term|WRMSRNS}}{{defn|Non-serializing Write to [[Model-specific register]].}}{{glossary end}}
| <code>WRMSRNS</code>
| <code>NP 0F 01 C6</code>
|Write Model-specific register. The MSR to write is specified in ECX, and the data to write is given in EDX:EAX.

The instruction differs from the older <code>WRMSR</code> instruction in that it is not serializing.
| {{no|0}}
| {{nowrap|[[Sierra Forest]]}}
|-
! colspan="6" |
|-
| rowspan="2" | {{glossary}}{{term|MSRLIST}}{{defn|Read/write multiple [[Model-specific register]]s.<br />Available in 64-bit mode only.}}{{glossary end}}
| <code>RDMSRLIST</code>
| <code>F2 0F 01 C6</code>
| Read multiple MSRs. RSI points to a table of up to 64 MSR indexes to read (64 bits each), RDI points to a table of up to 64 data items that the MSR read-results will be written to (also 64 bits each), and RCX provides a 64-entry bitmap of which of the table entries to actually perform an MSR read for.{{efn|name=msrlist_align|text=For the <code>RDMSRLIST</code> and <code>WRMSRLIST</code> instructions, the addresses specified in the RSI and RDI registers must be 8-byte aligned.}}
| rowspan="2" {{no|0}}
| rowspan="2" | {{nowrap|[[Sierra Forest]]}}
|-
| <code>WRMSRLIST</code>
| <code>F3 0F 01 C6</code>
| Write multiple MSRs. RSI points to a table of up to 64 MSR indexes to write (64 bits each), RDI points to a table of up to 64 data items to write into the MSRs (also 64 bits each), and RCX provides a 64-entry bitmap of which of the table entries to actually perform an MSR write for.{{efn|name=msrlist_align}} The MSRs are written in table order.<p>The instruction is not serializing.</p>
|-
! colspan="6" |
|-
| {{glossary}}{{term|CMPCCXADD}}{{defn|Atomically perform a compare - and a [[fetch-and-add]] if the condition is met.<br />Available in 64-bit mode only.}}{{glossary end}}
| {{nowrap|<code>CMPccXADD m32,r32,r32</code>}}<br />{{nowrap|<code>CMPccXADD m64,r64,r64</code>}}<br />&nbsp;
| {{small|{{nowrap|<code>VEX.128.66.0F38.W0 E<b>x</b> /r</code>}}<br />{{nowrap|<code>VEX.128.66.0F38.W1 E<b>x</b> /r</code>}}}}<br />{{efn|name=setcc_conds|text=The condition codes supported for the <code>CMP'''cc'''XADD</code> instructions (opcode <code>VEX.128.66.0F38 E'''x''' /r</code> with the '''x''' nibble specifying the condition) are:
{{(!}} class="wikitable sortable"
! x !! cc !! Condition ([[FLAGS register|EFLAGS]])
{{!}}-
{{!}} 0 {{!!}} O {{!!}} OF=1: "Overflow"
{{!}}-
{{!}} 1 {{!!}} NO {{!!}} OF=0: {{nowrap|"Not Overflow"}}
{{!}}-
{{!}} 2 {{!!}} B {{!!}} CF=1: "Below"
{{!}}-
{{!}} 3 {{!!}} NB {{!!}} CF=0: {{nowrap|"Not Below"}}
{{!}}-
{{!}} 4 {{!!}} Z {{!!}} ZF=1: "Zero"
{{!}}-
{{!}} 5 {{!!}} NZ {{!!}} ZF=0: {{nowrap|"Not Zero"}}
{{!}}-
{{!}} 6 {{!!}} BE {{!!}} (CF=1 or ZF=1): {{nowrap|"Below or Equal"}}
{{!}}-
{{!}} 7 {{!!}} NBE {{!!}} (CF=0 and ZF=0): {{nowrap|"Not Below or Equal"}}
{{!}}-
{{!}} 8 {{!!}} S {{!!}} SF=1: "Sign"
{{!}}-
{{!}} 9 {{!!}} NS {{!!}} SF=0: {{nowrap|"Not Sign"}}
{{!}}-
{{!}} A {{!!}} P {{!!}} PF=1: "Parity"
{{!}}-
{{!}} B {{!!}} NP {{!!}} PF=0: {{nowrap|"Not Parity"}}
{{!}}-
{{!}} C {{!!}} L {{!!}} SF≠OF: "Less"
{{!}}-
{{!}} D {{!!}} NL {{!!}} SF=OF: {{nowrap|"Not Less"}}
{{!}}-
{{!}} E {{!!}} LE {{!!}} (ZF=1 or SF≠OF): {{nowrap|"Less or Equal"}}
{{!}}-
{{!}} F {{!!}} NLE {{!!}} (ZF=0 and SF=OF): {{nowrap|"Not Less or Equal"}}
{{!)}}<!--The condition codes are the same as for <code>Jcc</code>/<code>CMOVcc</code>/<code>SETcc</code>, but as of November 2024, Intel documentation (325462-085) provides fewer name aliases for the <code>CMPccXADD</code> condition names, e.g. the "C" or "NAE" names are accepted as aliases for "B" for <code>Jcc</code>/<code>CMOVcc</code>/<code>SETcc</code> but not for <code>CMPccXADD</code>.-->}}{{efn|Even though the <code>CMPccXADD</code> instructions perform a locked memory operation, they do not require or accept the <code>LOCK</code> (<code>F0h</code>) prefix - attempting to use this prefix results in #UD.}}&nbsp;
| Read value from memory, then compare to first register operand. If the comparison passes, then add the second register operand to the memory value. The instruction as a whole is performed atomically.<br />The operation of {{nowrap|<code>CMPccXADD [mem],reg1,reg2</code>}} is:<pre>
temp1 := [mem]
EFLAGS := CMP temp1, reg1 // sets EFLAGS like regular compare
reg1 := temp1
if( condition )
    [mem] := temp1 + reg2</pre>
| {{yes|3}}
| {{nowrap|[[Sierra Forest]],}}<br/>[[Lunar Lake]]
|-
! colspan="6" |
|-
| {{glossary}}{{term|PBNDKB}}{{defn|Platform Bind Key to Binary Large Object.<p>Part of Intel TSE (Total Storage Encryption), and available in 64-bit mode only.</p>}}{{glossary end}}
| <code>PBNDKB</code>
| <code>NP 0F 01 C7</code>
| Bind information to a platform by encrypting it with a platform-specific wrapping key. The instruction takes as input the addresses to two 256-byte-aligned "bind structures" in RBX and RCX, reads the structure pointed to by RBX and writes a modified structure to the address given in RCX.

If the instruction fails, it will set EFLAGS.ZF=1 and return an error code in EAX. If it is successful, it sets EFLAGS.ZF=0 and EAX=0.
| {{no|0}}
| [[Lunar Lake]]
|}
{{notelist}}{{vpad}}

==== Added with other AMD-specific extensions ====
{{sticky header}}
{| class="wikitable sortable sticky-header"
! Instruction Set Extension !! Instruction<br />mnemonics !! Opcode !! Instruction description !! [[Protection ring|Ring]] !! Added in
|-
! colspan="6" |
|-
| rowspan="2" | {{glossary}}{{term|AltMovCr8}}{{defn|Alternative mechanism to access the CR8 [[control register]].{{efn|The standard way to access the CR8 register is to use an encoding that makes use of the <code>REX.R</code> prefix, e.g. {{nowrap|<code>44 0F 20 07</code>}} ({{nowrap|<code>MOV RDI,CR8</code>}}). However, the <code>REX.R</code> prefix is only available in 64-bit mode.<br />The AltMovCr8 extension adds an additional method to access CR8, using the <code>F0</code> (<code>LOCK</code>) prefix instead of <code>REX.R</code> – this provides access to CR8 outside 64-bit mode.}}}}{{glossary end}}
| <code>MOV reg,CR8</code>
| <code>F0 0F 20 /0</code>{{efn|name="altmovcr8_encoding"|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 <code>11b</code>.<br />The AltMovCr8 encodings are available in 64-bit mode. However, combining the <code>LOCK</code> prefix with the <code>REX.R</code> prefix is not permitted and will cause an #UD exception.}}
| Read the CR8 register.
| rowspan="2" {{no|0}}
| rowspan="2" | [[AMD K8|K8]]{{efn|Support for AltMovCR8 was added in stepping F of the AMD K8, and is not available on earlier steppings.}}
|-
| {{nowrap|<code>MOV CR8,reg</code>}}
| {{nowrap|<code>F0 0F 22 /0</code>}}{{efn|name="altmovcr8_encoding"}}
| Write to the CR8 register.
|-
! colspan="6" |
|-
| rowspan="2" | {{glossary}}{{term|MONITORX}}{{defn|Monitor a memory location for writes in user mode.}}{{glossary end}}
| <code>MONITORX</code>
| <code>NP 0F 01 FA</code>
| Start monitoring a memory location for memory writes. Similar to older <code>MONITOR</code>, except available in user mode.
| rowspan="2" {{yes|3}}
| rowspan="2" | [[Excavator (microarchitecture)|Excavator]]
|-
| <code>MWAITX</code>
| <code>NP 0F 01 FB</code>
| Wait for a write to a monitored memory location previously specified with <code>MONITORX</code>.<br /><code>MWAITX</code> differs from the older <code>MWAIT</code> instruction mainly in that it runs in user mode and that it can accept an optional timeout argument (given in TSC time units) in EBX (enabled by setting bit[1] of ECX to 1.)
|-
! colspan="6" |
|-
| {{glossary}}{{term|CLZERO}}{{defn|Zero out full cache line.}}{{glossary end}}
| {{nowrap|<code>CLZERO rAX</code>}}
| <code>NP 0F 01 FC</code>
| Write zeroes to all bytes in a memory region that has the size and alignment of a CPU cache line and contains the byte addressed by DS:rAX.{{efn|For <code>CLZERO</code>, 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.<br />The <code>CLZERO</code> 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.<ref>Wikichip, [https://en.wikichip.org/w/index.php?title=x86/clzero&oldid=94738 CLZERO – x86]</ref>}}
| {{yes|3}}
| [[Zen (first generation)|Zen 1]]
|-
! colspan="6" |
|-
| {{glossary}}{{term|RDPRU}}{{defn|Read processor register in user mode.}}{{glossary end}}
| <code>RDPRU</code>
| <code>NP 0F 01 FD</code>
| Read selected [[Model-specific register|MSRs]] (mainly performance counters) in user mode. ECX specifies which register to read.{{efn|text=The register numbering used by <code>RDPRU</code> does not necessarily match that of <code>RDMSR</code>/<code>WRMSR</code>.<br />The registers supported by <code>RDPRU</code> as of December 2022 are:
{{(!}} class="wikitable sortable"
! ECX !! Register
{{!}}-
{{!}} 0 {{!!}} MPERF (MSR 0E7h: Maximum Performance Frequency Clock Count)
{{!}}-
{{!}} 1 {{!!}} APERF (MSR 0E8h: Actual Performance Frequency Clock Count)
{{!)}}
Unsupported values in ECX return 0.}}

The value of the MSR is returned in EDX:EAX.
| {{yes2|Usually 3{{efn|text=If <code>[[Control_register#CR4|CR4.TSD]]=1</code>, then the <code>RDPRU</code> instruction can only run in ring 0.}}}}
| [[Zen 2]]
|-
! colspan="6" |
|-
| {{glossary}}{{term|MCOMMIT}}{{defn|Commit Stores To Memory.}}{{glossary end}}
| <code>MCOMMIT</code>
| <code>F3 0F 01 FA</code>
| Ensure that all preceding stores in thread have been committed to memory, and that any errors encountered by these stores have been signalled to any associated error logging resources. The set of errors that can be reported and the logging mechanism are platform-specific.<br />Sets <code>EFLAGS.CF</code> to 0 if any errors occurred, 1 otherwise.
| {{yes|3}}
| [[Zen 2]]
|-
! colspan="6" |
|-
| rowspan="2" | {{glossary}}{{term|INVLPGB}}{{defn|Invalidate TLB Entries with broadcast.}}{{glossary end}}
| <code>INVLPGB</code>
| <code>NP 0F 01 FE</code>
| Invalidate TLB Entries for a range of pages, with broadcast. The invalidation is performed on the processor executing the instruction, and also broadcast to all other processors in the system.<br />rAX takes the virtual address to invalidate and some additional flags, ECX takes the number of pages to invalidate, and EDX specifies ASID and PCID to perform TLB invalidation for.
| rowspan="2" {{no|0}}
| rowspan="2" | [[Zen 3]]
|-
| <code>TLBSYNC</code>
| <code>NP 0F 01 FF</code>
| Synchronize TLB invalidations.<br />Wait until all TLB invalidations signalled by preceding invocations of the <code>INVLPGB</code> instruction on the same logical processor have been responded to by all processors in the system. Instruction is serializing.
|}
{{notelist}}{{vpad}}