Talk:x86 instruction listings

This article was nominated for deletion on 30 June 2022. The result of the discussion was no consensus.

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing
Low	This article has been rated as Low-importance on the project's importance scale.
	This article is supported by WikiProject Software (assessed as Low-importance).
	This article is supported by Computer hardware task force (assessed as Low-importance).

SGX Instructions Missing

No Secure enclave processing instructions listed. — Preceding unsigned comment added by 100.6.80.179 (talk) 01:04, 8 October 2018 (UTC)[reply]

MMX, 3DNow!

wich instructions are integer, wich are floating point, wich are "other"? (similar distinction as in SSE/2/3 lists) Alinor 14:03, 25 February 2006 (UTC)[reply]

missing instructions

Some processors are not mentioned in the "instructions added with" lists:

80187 [ Note: THe 80187 is the FPU for the i80c186, because the i80188 is 8 bit ][ Intel 187 ]
80487 [actualy a i80486DX integrated FPU]

"The i487 SX was not really a Co Processor. It was a normal i80486 DX processor when installed to disable the onboard SX Processor and take over main operation of the CPU and add an FPU. The i487 has one pin more than a normal 486 cpu, so you need a special socket to install this chip."</endblockquote>[ i80487sx ]207.53.252.58 (talk) 20:27, 17 July 2023 (UTC)[reply]

There is no mention of the F0 0F bug:207.53.252.58 (talk) 20:27, 17 July 2023 (UTC)[reply]

"The Pentium F00F bug is a design flaw in the majority of Intel Pentium, Pentium MMX, and Pentium OverDrive processors (all in the P5 micro architecture). Discovered in 1997, it can result in the processor ceasing to function until the computer is physically rebooted. The bug has been circumvented through operating system updates."

"In the x86 architecture, the byte sequence F0 0F C7 C8 represents the instruction lock cmpxchg8b eax (locked compare and exchange of 8 bytes in register EAX). The bug also applies to opcodes ending in C9 through CF, which specify register operands other than EAX. The F0 0F C7 C8 instruction does not require any special privileges." </endblockquote>[ Pentium F0 0F https://wiki.riteme.site/wiki/Pentium_F00F_bug]207.53.252.58 (talk) 20:27, 17 July 2023 (UTC)[reply]

Athlon64/Opteron in both x86 and x87 lists (CMP...16B is added by EM64T and later Athlon64 revisions, but maybe there are other instructions added with the initial AMD64 revision)

Pentium II in x87 [Note: THe Pentium II included a math co-processor]
Pentium III (only SSE are new)

Pentium 4 (only SSE2/SSE3/VMX are new)
Pentium M in both x86 and x87 lists [Note: The Pentium M was a member of the Pentium 4 Family]

Maybe no new instructions are added with these CPUs, but does someone know for sure?
Also, there are some CPUs that are not mentioned in some particular lists, but this is OK, because they have not added new instructions there for sure:

Anyway it would be good to put (a) placeholder(s) for each of these CPUs with a "nothing added" mark, so that it is clear that the list is complete. Alinor 14:03, 25 February 2006 (UTC) Readablity edit JSo9-10 (talk) 06:30, 17 June 2010 (UTC)[reply]

The Haswell chips have introduced new instructions also (MOVBE is one - it already is in the ATOM chips). It needs to be listed here also. Johnreagan (talk) 18:02, 23 April 2013 (UTC)[reply]

exotic x86 CPUs

there are many more x86 CPU manufacturers. Maybe some of them support some additional instructions. It would be good to at least add a section "Other x86 CPUs - list-stub": Chips and Technologies Super386, Cyrix 386/486/5x86/6x86/6x86MX, Cyrix/NatSemi MediaGX/AMD Geode, VIA Cyrix C3, VIA Centaur C3, IDT Centaur, NEC V10/V20, Rise Technology mP6, SiS SoC, NexGen Nx586/Nx587/K6, Transmeta Cursoe/Efficeon, UMC Super486, SGS-Thomson/IBM/Texas Instruments/others generic manufacturers, ALi/ULi/other embedded designs.

Actual instructions

I'd like to see this list have actual x86 instruction - like the MIPS page has. Like, with this list, you should be able to learn the assembly. Fresheneesz 18:41, 13 April 2006 (UTC)[reply]

The wikipedia site (and encyclopedias in general) isn't an instruction manual or howto, but Wikibooks (a related site) is. Perhaps you'd be interested in wikibooks:X86 Assembly/X86 Instructions? --Interiot 20:09, 13 April 2006 (UTC)[reply]

...and the MIPS architecture page does not have the full MIPS instruction set, just a sample of the early R3000 instructions, to give a general idea of the instruction set. Guy Harris 20:43, 13 April 2006 (UTC)[reply]

Well, I didn't *mean* a "how to". What I meant was a reference listing. This isn't indiscriminate, how many more people do you think would care about this page if it had actual usable instruction on it? Who the hell cares *what* the names of instructions are, if it doesn't tell you what they do? I believe this page is more of an "indiscriminate colletion of info" as it is, but would be less so if it contained actual instructions.

I'm not talking about a manual, or a how to, or a text book, or anything that would sequentially teach each instruction. I'm talking about a simple list.

As for MIPS, I think the page (or at least *a* page somewhere) should list the full MIPS instruction set - meaning non-pseudo instructions. I've edited that page slightly to list the most basic real instructions - and I think it would be very nice for this page to do the same? Comments again? Fresheneesz 02:00, 14 April 2006 (UTC)[reply]

Good resources to finish listing the instructions.

Firstly, there is the 102 page (yes, I printed it out) appendix b of the NASM manual. Then there is Intel's documentation regarding the Pentium 4 and other specifications. I'm sure that the GNU assembler has some sort of helpful documentation as well, but I haven't checked.

CPUID

Was CPUID introduced in the 486? This article says that it was, but I think it might have been introduced with the Pentium and not earlier. - Richardcavell 04:17, 3 January 2007 (UTC)[reply]

To quote Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 3A: System Programming Guide, Part 1, page 17-6 (the 600th page of the PDF document in question), "The CPUID instruction is available in all Pentium and P6 family processors and in later models of the Intel486 processors. The ability to set and clear the ID flag (bit 21) in the EFLAGS register indicates the availability of the CPUID instruction.", so it was introduced in later 486 models - some had it, some didn't. Guy Harris 09:39, 3 January 2007 (UTC)[reply]

It is certainly not listed in programming manuals dated around the time. Specifically, "Using Assembly Language", which covers the 80486, has no mention of this instruction. —Preceding unsigned comment added by 92.232.150.252 (talk) 20:26, 7 September 2009 (UTC)[reply]

Overhauling the article...anybody want to help?

I'm going to be converting the lists of instructions that aren't in table form (e.g. 486 instructions and up) and converting it into tables as a way to spend my summer. If you want to help with this or have any questions / comments, post them on my usertalk. Thanks! Andreyvul (talk) 07:23, 31 July 2008 (UTC)[reply]
Specifically, help with tabulating the floating-point instructions would be nice. Andreyvul (talk) 17:01, 31 July 2008 (UTC)[reply]

Clarification of supported instructions

The instructions bswap,cmpxchg,invd,invlpg,wbinvd,xadd

Do they exist on the AMD K5 and AMD K6? What about on the Cyrix 686?

And the Pentium instructions: cmpxchg8b, rdmsr, rdtsc, wrmsr ...

Do they exist on the AMD K5 and AMD K6? What about on the Cyrix 686?

Mark Hobley —Preceding undated comment was added at 20:36, 8 February 2009 (UTC).[reply]

Which instruction set is used in 32 bit windows programs today?

When you compile a program for a windows 32 bit system, which assembly language and which machine language is used? In other words, which of the instruction sets is it that is used in .exe-files? I can't find it in the article, maybe it could be put there? --Kri (talk) 23:49, 26 February 2009 (UTC)[reply]

It depends which compiler you're using, and what options you passed to it. JulesH (talk) 11:01, 7 March 2009 (UTC)[reply]

I'm not talking about any specialized exe-programs that works for your processor only, but about the general .exe files that work on all windows 32 bit computers (for example VLC in exe format is supposet to work on all windows computers). So I wonder, which set of machine language instructions does Windows require of the processor to support? Also, is this required set of instructions the same for Linux, since it is run on PC:s as well? --Kri (talk) 19:25, 7 March 2009 (UTC)[reply]

Is there really no one who knows the answer to that question? Ok, which is the most commonly used x86 instruction set then? --Kri (talk) 16:52, 17 March 2009 (UTC)[reply]

First, a modern compiler compiles directly to machine code. Second, there actually are no "general .exe files"; it really depends on the compiler you are using. For example, Microsoft C++ compiler options allow you to enable SSE or SSE2 instructions to be generated. MazeGen (talk) 19:07, 13 May 2009 (UTC)[reply]

Yes it's true that compilers can choose to emit whatever code they want. But the questioner(s) asked about the common-or-garden win32 exe that might be found on a 32-bit Windows box. The answer is (a) 386 instruction set at a minimum, but (b) it is rather more likey nowadays that if you were to dig into more recently built exes you would find that the compiler was told to assume that a Pentium Pro (the first of the 686 family if you like) or higher be present, and indeed you might well find that (c) SSEv.xx instructions will be present in some apps where the authors know that they are not going to be deployed on very old machines because the authors do not support ancient operating systems. So either 386 or 686 is the answer. For PCs running 64-bit Windows (ie AMD64 aka x64), then you will find two different types of windows exes: the native 64-bit ones written in the x64 instruction set and running in the new x64 "long mode", and you may also find some 32-bit app exes which will run too just as in 32-bit windows.83.105.29.227 (talk) 12:49, 1 June 2009 (UTC)[reply]

Common practice is to code a bunch of critical functions in SIMD (SSE 1/2/3/4 etc.), include them all in the exe, and use runtime CPUID checking to see the machine's capabilities. Then, using dynamic binding (e.g. function pointers), the most optimised available version is used. Therefore this "general exe" will run in scalar mode on a 386, but use the latest SSE X functions on a Core i7, for example. I'm not too sure about auto-vectorisation; I suspect different codepaths would all be included, and again dynamic binding used. It would be quite irresponsible for compiler makers to break output for older CPUs. C xong (talk) 04:49, 16 March 2010 (UTC)[reply]

RDTSC

This was broken out into a section for instructions added in the Pentium II. This is incorrect. The Pentium Pro instruction reference [1] lists it as available since the Pentium. I don't have a reference to the original Pentium manuals, but I see no reason to believe that it was not listed in those; certainly when I was working on NASM the instruction was well known, and I'm pretty certain it wasn't on our list as undocumented.

Even if it wasn't officially documented at the time, it has since been officially documented as available on the Pentium, so it belongs in the section for Pentium. I have moved it back. JulesH (talk) 22:35, 28 March 2009 (UTC)[reply]

Check my brain pls - LODSW and 386

The 386 table lists LODSW as new. That should be deleted surely? As not "new" - was in the 8086? Check thatI'm not going mad, and feel free to correct the table, or I'll do it.83.105.29.227 (talk) 12:51, 1 June 2009 (UTC)[reply]

Removed. C xong (talk) 04:51, 16 March 2010 (UTC)[reply]

Wrong link in instruction table

OR is linked to http://wiki.riteme.site/wiki/Logical_NOR instead of http://wiki.riteme.site/wiki/Logical_OR. As i'm pretty new to assembly, i won't change it but would like to have it checked by someone who knows what he's doing.

Changed. Be bold! C xong (talk) 04:56, 16 March 2010 (UTC)[reply]

Undocumented Instructions

I think that MOV {DS|ES|SS},r/m are very documented instructions and perhaps the most popular way to load segment registers. (The other popular way is PUSH <something> / POP {DS|ES|SS}. The MOV CS,r/m is indeed undocumented. Although, the 8086 datasheet contains generic 'register/memory to segment register' opcode, and doesn't show MOV CS,r/m as an exception. Moreover I verified MOV CS,r/m instruction on various versions ('78, '78 '81 and '79 '83) of Intel 8088, on Intel and Harris 80C88, AMD 8088, and NEC V20 and V20HL, and it works on all of them, causing a far jump.
AAD (and probably AAM) instruction with argument doesn't work properly on NEC V20, V30 and probably other NEC CPUs. They always assume that argument is 0Ah.
I don't think that AAD implementation was buggy on first Intel CPUs (as Original 8086/8088 instructions sections mentions). It simply was not documented to accept any argument other than 0Ah —Preceding unsigned comment added by 71.111.52.89 (talk) 20:39, 22 January 2011 (UTC)[reply]

Hello, i hope my question back can answered after so long time. I have a question for "MOV CS,r/m"..."and it works on all of them, causing a far jump", if you only modify the CS and not the IP-Register, that kind of "far jump" is done by an "MOV CS,r/m"-Instruction? Do you realy have tested it on old physical CPUs?
I can remember on original Documentation (from Intel and others) about the 386 and there are the "MOV SR,r/m" (0x8E ...) and "MOV r/m,SR" (0x8C ...) described as normal OpCodes with all 6 possible Segment-Registers for both Directions (only the valid usecase for "MOV CS,r/m" was not described).
Greatings, Erik --2003:ED:F7FF:17D1:E03F:66BD:87C5:5946 (talk) 22:58, 21 October 2022 (UTC)[reply]

The far jump that occurs is that the segment is changed but the offset remains the same. So e.g. if you load CS with 1234 with the address following the move begin dead:beef, you jump to 1234:beef. On the 80186 and later, loading CS through anything but an explicit jump instruction is instead forbidden. --FUZxxl (talk) 14:43, 23 October 2022 (UTC)[reply]

AAD Immediate Operand

My first "PC" back in the '80s had an NEC V20, and the assorted paperwork that came with it said the exact opposite: The <evil> Intel 8088/86 didn't care what you put in the 2nd opcode because when the processor saw the primary opcode it read 0x0A regardless of what was actually in the byte stream, whereas the <good> NEC V20 would faithfully use whatever operand you put in there and thus was useful in a general-purpose baseshifting routine. This, they went on to explain, was a quick way to determine if a program was running on an Intel or NEC chip. Anyone here have a quick way to be sure which is correct? I do not have an operable 8088/86 _or_ V-series computer. SandyJax (talk) 21:00, 24 January 2011 (UTC)[reply]

I do have a working 8088 motherboard and some 8088, 80C88, NEC V20, and NEC V20HL CPUs. I verified AAD behavior. On all 8088 processors (including soviet clone - KM1810VM88) AAD accepts the argument and does AL = AH * arg + AL; AH = 0, on NEC V20 and V20HL CPUs AAD ignores the argument, and does AL = AH * 0x0A + AL; AH = 0 — Preceding unsigned comment added by Skiselev (talk • contribs) 00:39, 26 January 2011 (UTC)[reply]

Thank you for that; at the time my programming skills were not up to verifying the claim either way. SandyJax (talk) 16:51, 26 January 2011 (UTC)[reply]

Thanks for verifying this! And what about AAM? Does the NEC V20 ignore its argument too? Лъчезар☭共产主义万岁★ 10:02, 9 July 2011 (UTC)[reply]

Hmm; story time. This is part of an old CPU detector routine. Looks like NEC followed the documentation without checking it against the hardware.

       ; Try for an NEC V20/30
       mov ax, 0208h
       db 0D5h,16      ; Only the 8088 actually checks the arg to AAD
       cmp al, 28h     ; as intel ran out of microcode space
       jz short cmos
       mov bx, 4       ; NEC V20
       jmp short test8

2001:470:1F09:10D6:F21F:AFFF:FE54:B8C (talk) 09:12, 19 December 2013 (UTC)[reply]

An opcode notation legend would be helpful

For instance what is /r? WvvvvL01 69 /r /is4 say what? This stuff is not so easy to find out, and isn't generally covered in ASM manuals. PS: Not asking for help, just saying it's too opaque as is. --67.54.192.52 (talk) 05:42, 3 February 2011 (UTC)[reply]

I agree — Preceding unsigned comment added by 69.25.132.5 (talk) 00:45, 14 September 2011 (UTC)[reply]

The ENTER instruction is more complex than presented

The presented information about the ENTER instruction (that it is equivalent to PUSH BP / MOV BP, SP / SUB SP, n) is correct only if the second operand (the nesting level) is zero. If it's non-sero, the behaviour of ENTER is more complex. See for example the Am186™ and Am188™ Family Instruction Set Manual (p. 4-53) for a description of this instruction.

Лъчезар☭共产主义万岁★ 15:17, 4 April 2011 (UTC)[reply]

"Added" relative to what ?

The sections 1.2 ("Added in specific processors") and 2.2 ("Added in specific processors") state that the instructions listed in its sub-sections have been added with some processor, but they miss to describe what the basis for the addition was. Not in all cases is the addition relative to the previous section / processor. In most cases, it is not the base 8086/8087 instruction set, either.

These sections should be updated to explicitly state relative to which other section or processor the instructions listed in the current section were added.

Gandalf44 (talk) 15:38, 11 May 2011 (UTC)[reply]

SSEx processor vs. SSEx instruction set

Section 1.2 ("Added in specific processors") describes SSEx as processors and lists certain instructions that were added. Section 3 ("SIMD instructions") describes SSEx as a set of instructions (which is correct). There are multiple issues with this approach:

It is confusing to describe SSEx as both a processor and as a set of instructions. It is really only a set of instructions, there are no processors or microarchitectures with these names, however there are processors that support these sets of instructions (and sometimes there are flavors of the same processor type that support these differently, e.g. I believe that Pentium 4 has a flavor that supports just SSE2 and one that supports SSE3 in addition).
The set of instructions in both descriptions is sometimes similar, and sometimes quite different (e.g. 1.2.9 "Added with SSE" and 3.6.2 "SSE SIMD Integer Instructions" list very different instructions, while the instructions in 1.2.15 "Added with SSE4a" are a subset of those in 3.10.2 "SSE4a"). This is very confusing, even after one gets beyond the previous issue by interpreting that as processors.

I suggest that section 1.2 really only mentions instructions added by processors (or microarchitectures, as a means to refer to all the processors implementing that microarchitecture), and that specific named instruction sets are only described in section 3. If processor types need to be qualified because there are different flavors supporting different instruction sets, than such a qualification simply needs to be added.

Gandalf44 (talk) 15:56, 11 May 2011 (UTC)[reply]

NOP in SSE instructions

The instruction list shown in the table in section 3.6.2 ("SSE SIMD Integer Instructions") lists NOP with opcode 0F 1F. This is different from the NOP in the 8086 base instruction set (opcode 90). It would be helpful to explain why a different NOP was needed (if anyone knows ... - or at least to point out that this is a different opcode that shares the same mnemonic).

Gandalf44 (talk) 16:52, 11 May 2011 (UTC)[reply]

This is about a multi-byte NOP. The "new NOP" accepts different addressing modes, allowing for different instruction sizes. If you need 1 byte, you still have to use the old XCHG AX,AX NOP. DiederikH (talk) 19:30, 16 October 2012 (UTC)[reply]

Opcode 0F 04 on 80286

I have made some tests with this (apparent) HCF opcode and I had to conclude the following:

The opcode is not an alias for RESET or LOADALL, because substituting LOADALL286 (0F 05) in a working program for 0F 04 still hangs the CPU in real mode.
When executed in protected mode at CPL=3, the opcode generates Exception 0dh (General Protection Exception). This means that it is an actual instruction and not a bug. The error code is 0, regardless of segment register contents.
Executing 0F 04 at CPL=0 hangs the computer, even with null selectors loaded in DS and ES.
Oddly enough, executing LOADALL at CPL=3 RESETS the computer, despite the fact that all exceptions are handled and RESET is routed to ensure clean return to DOS.

The CPU is an Am286-16.

DiederikH (talk) 17:19, 14 October 2012 (UTC)[reply]

Thanks for the investigation! I do not have any of that hardware, so can't do anything with it...

Error code 0 on CPL=3 is strange. At least bit U shall be set.
Have you tried a null IDT on CPL=0?

Intelfx (talk) 11:45, 24 March 2013 (UTC)[reply]

Executing 0F 04 at CPL=0 hangs the computer with null IDT on CPL=0. The CPU is Am286-12.

180.64.31.71 (talk) 00:02, 22 September 2013 (UTC)[reply]

The 80286 opcode 0F 04 might be a version of the 8086 opcode F4 (HLT) that disables interrupts completely, so the processor simply waits indefinitely... Note the matching nibbles. --rtc (talk) 20:59, 1 August 2017 (UTC)[reply]

Research about 0F 04 can be found at [2]. They traced it down to being SAVEALL for ICE purposes.

AT&T syntax/mnemonics

I believe it would be useful to add AT&T mnemonics to help finding instructions such as movl/addl/etc, both to help search engine results and also when doing textual searches inside the page.

However, this could complicate a bit things, since for instance many such instructions (e.g. mov) are defined for 8086 on Intel syntax, but might have to be added under a different family for the "extended" version. — Preceding unsigned comment added by Dhekir (talk • contribs) 07:25, 20 July 2015 (UTC)[reply]

External links modified

Hello fellow Wikipedians,

I have just modified 2 external links on X86 instruction listings. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 13:36, 21 July 2016 (UTC)[reply]

Compatibility instructions

the page lacks 8A ** ** ** instruction, which is from 8086 or older and compatiblity is kept till today. I tried today to disassemble some program and it seems my disassembler also don't know it. here is some info, I don't fully understand: http://ref.x86asm.net/coder32.html#x8A — Preceding unsigned comment added by 89.74.199.35 (talk) 02:12, 9 August 2016 (UTC)[reply]

according to http://aturing.umcs.maine.edu/~meadow/courses/cos335/8086-instformat.pdf "8a 86 d5" is mov al, D5 — Preceding unsigned comment added by 89.74.199.35 (talk) 02:53, 9 August 2016 (UTC)[reply]

sorry it were new instruction "8a 86 d5 00 00 00" mov al, [esi + 0xd5] — Preceding unsigned comment added by 89.74.199.35 (talk) 06:42, 9 August 2016 (UTC)[reply]

ARM instruction listings

Is there a similar page for ARM listings? If not, then one could create by automating from the ARM documentation itself. Anyone up for it? — Preceding unsigned comment added by Temp00guy (talk • contribs) 01:51, 29 April 2017 (UTC)[reply]

LOL, it's not as easy as you might think, because "ARM" has many different instruction sets / architectures / cores. For useability, most end users don't give a crap about architectures or instruction sets, instead they care what is in a specific core, and unfortunately cores may be a SUBSET of an architecture and support one or more instructions sets (or sub-instruction sets). In past years, I took a stab at doing all "ARM Cortex-M#Instruction sets" cores and it was very difficult to do. A very high percentage of the top of the ARM Cortex-M was created by me. • Sbmeirow • Talk • 09:45, 29 April 2017 (UTC)[reply]

No one should try to attack this issue without planning the article and table layout first. It's better for multiple people to hash it out concepts and issues first. We either need to do it right or NOT do it at all. • Sbmeirow • Talk • 09:45, 29 April 2017 (UTC)[reply]

ARM has released machine readable architecture specification for their v8-A processor. Perhaps we can start from there? Temp00guy (talk) 00:18, 5 May 2017 (UTC)[reply]

Add graph

[[|thumb|https://hsto.org/webt/ph/4k/70/ph4k700mdvxwacaepm4uzqoq188.png]] from https://habr.com/ru/post/503486/ — Preceding unsigned comment added by Arkeke (talk • contribs) 06:31, 24 November 2020 (UTC)[reply]

Operands

I would like an operands column in the table under integer instruction listings. I don't think the notes column would suffice. This text might not be sufficient, in that case, ask and I shall provide info. This may be unnecessary, in that case ignore this. — Preceding unsigned comment added by BigGayDinosaur (talk • contribs) 04:56, 4 January 2021 (UTC)[reply]

Restructuring

Hey User:Punpcklbw; I see you've been active on this article and I was wondering if you'd like to help me split it off into sublists which would help make the main article more accessible (which would also allow more space for references, context about prefixes and encoding, etc.) I'll propose a structure in a bit if you're interested. Love the username, by the way; had to use vpunpckl(hd)q recently. :) Ovinus (talk) 03:46, 21 June 2022 (UTC)[reply]

Probably yes - I would like to see your proposed structure first, though.

When looking at the article as it is, the SIMD section in particular stands out as making up a huge and not very well-organized chunk of the article as a whole - and a chunk that may grow considerably still (it's still missing much of AVX512, XOP and MIC, at least) - and as such, I think it would help considerably just to move that one out to its own listings article.

I don't think I would want to split it up further right now - a whole lot of the instructions added in SSE2, MIC and AVX1/2/512 are basically just extended versions of old MMX/SSE instructions, using basically the same opcodes/mnemonics as the MMX/SSE originals, just with added prefixes to add support for more vector widths and new functionality (e.g. AVX three-operand encoding, AVX512 broadcast/opmask stuff) (have a look at https://sandpile.org/x86/opc_2.htm for an opcode table that shows just how pervasively Intel has been doing this) - and I think this could be used to group the instructions in a more sensible way (e.g. by augmenting the MMX instruction table with extra columns and descriptive text to cover the SSE2/AVX2/AVX512 extended variants of each MMX instruction, rather than having them put in separate tables for each extension.)

Other than the SIMD stuff, the x87-instruction section and the undocumented-instruction section also stand out to me as items that are big enough and self-contained enough to be split out into separate articles without too much difficulty.

Does this align with the sort of split that you had in mind? Punpcklbw (talk) 19:48, 21 June 2022 (UTC)[reply]

I think we're on the same page; I'm still brainstorming. Yep; a lot of duplication! (And from what I understand, adding VEX and EVEX prefixes for the exact same instruction even if operating on xmm registers only?? Glorious.) I like your idea about just augmenting the table with different instruction sizes, which is essentially what Intel's manuals do as far as I can tell. That way it's abundantly clear when AVX-bleh is adding vs. widening an operation. To make it easier, could do something like attach a footnote to every instruction which has an extension to 256- or 512-bit registers. Examples: punpcklbw xmm, xmm, xmm^[a]; pshufb xmmm, xmm^[b] My overall concept is: Order by instruction type, then by chronology, and finally split off less-important or very fat instruction sets. The article sort of does that already, although the header "x86 integer instructions" is a bit misleading—it's currently integer instructions and miscellaneous instructions, so maybe rename it to "general-purpose" (but I don't know how descriptive that is either). I'd say the first thing to do is to split off obsolete instructions like most of the stuff in "Added in specific non-Intel processors" into List of nonstandard x86 instructions or List of obsolete x86 instructions. I'd also move 3DNow! (excluding prefetch), MPX, EMMI, and maybe XOP since AMD isn't supporting it anymore. The rationale is that those instructions are just... not useful anymore, and the reader shouldn't have to wade through them. If they're really curious they can check the links, but I think presenting these random instruction sets in the same article as SSE is quite misleading.

Then split off x87 instructions into its own article, List of x87 instructions, because they're quite uncommon.

Then for SSE up to AVX2, I'm not sure. There are benefits and drawbacks to splitting it, the main downside being that contain actually common and important instructions. There's a third option: Split the article into a "list of SSE instructions" page, then only include a compact table of each mnemonic in this article.

Then for AVX512 and its ungodly number of new instructions and quirks, just put them all into AVX-512 or List of AVX-512 instructions, with a couple paragraph summary of what it adds.

Also, in general I think the article deserves a quick background section on stuff like "what is a word/doubleword/quadword? What does this fancy xmm1/m64 syntax mean?" I don't think that'll be too hard to write. Anyway, this is all just brainstorming; let me know what you think! Ovinus (talk) 05:36, 22 June 2022 (UTC)[reply]

For the class of old and little-used instructions that you're mentioning, I think I agree that, yes, they should be separated out into an article of their own. I think I'd prefer to use the word "discontinued" (as in List of discontinued x86 instructions) rather than "nonstandard" or "obsolete" to categorize the instructions in question, though. ("Nonstandard instructions" sounds to me like it would not be referring to well-documented-but-obscure instructions like, say, SCHEOL or BB1_RESET - but rather to instructions that are undocumented (e.g. SAVEALL, PSWAPW), unimplemented (e.g. ZALLOC, PCOMMIT), software-only (e.g. VPCEXT, F2X, BOP) or similarly abnormal (e.g. VIA's Alternate Instruction Set). "Obsolete" sounds a bit too subjective, e.g. I've seen the old 80286 protected-mode instructions described as "obsolete" a number of times, but every modern x86 CPU continues to support them, so I think they should be kept in the main article. "Discontinued" seems rather more precise than either.)

As for the SIMD instructions, I've prepared an example of the sort of augmented-table I had in mind, using the Pentium MMX opcodes as a starting point - see [3] - with this sort of table layout, I suspect that an article that lists the AVX512 instructions alone won't actually end up all that much shorter than an article that lists all of MMX/SSE/AVX/AVX512; this is why I think I would prefer to have one SIMD instruction-listings article rather than trying to split it up along the lines of MMX vs SSE vs AVX vs AVX512. (A table like this is pretty obviously going to require something like perhaps 3-5 paragraphs of introductory text in front of it to explain what's going on in it, but that seems kinda inescapable for basically anything that's supposed to introduce anything related to any of the AVX/AVX512 variants.) Punpcklbw (talk) 02:45, 24 June 2022 (UTC)[reply]

I really like the table you've linked, actually; compact, informative, and quite aesthetic. Would work well in an article dedicated to SSE and friends. And I agree that "discontinued" is a better and more precise word than either of my proposals. I also think your table mixes well with clarifying footnotes, which aren't needed for most instructions, but for gotchas like vpshufb it makes sense to make abundantly clear to the reader what a widened instruction is really doing. Also, I think it'd be apt to have footnotes for instructions that can't run in ring 3, so smth like HLT^[c] and MOV ...^[d], and maybe alignment information for the handful of instructions which allow unaligned loads. In the table, do you think we should group scalar SSE instructions, e.g. MULSD xmm, xmm, separately from vector instructions?

In terms of introductory material for SIMD instructions, I'll try draft something up over the next few days (if you haven't started something already). Ovinus (talk) 05:48, 24 June 2022 (UTC)[reply]

For the SSE floating-point scalar vs vector instructions, I think I prefer to group them together. I have now prepared a table that combines SSE scalar and vector operations for all the operations that follow the "sta4 3

1 0 2 4 34 3 1 0 2 4 3ndard" SSE pattern (FP32 vector with no prefix, FP32 scalar with F3h prefix, FP64 vector with 66h prefix, FP64 scalar with F2h prefix + the new AVX512-FP16 instructions) as well as indicators for AVX/AVX512 extensions of these instructions. My main concern was that such a table would become too impractically wide, however with a table now prepared - at [4] - it did get a bit unwieldy and visually noisy, but not nearly as much as I feared. Also, I've tried to add a few footnotes, and yes, it does seem to fit well with this kind of table approach.

For the case of indicating which instructions can or cannot run in ring 3 for, say, the old 8086/286/386 tables, I'm a bit unsure whether I'd prefer a footnote-based approach or adding an extra column to the opcode tables to indicate the ring - either is probably OK. (There is also an issue where some instructions' rings depend on various control bits, e.g. IOPL for STI or CR4.UMIP for SMSW, but that is probably orthogonal to the question of how to best express the rings.)

As for the "undocumented", "discontinued" and "x87" instructions, it seems to me that we are in pretty much agreement about what should be split out, so I intend to try that over the next few days. For the "discontinued" instructions, I note that not all of the processors supporting MPX and XOP have been fully officially discontinued yet (e.g. [5]) - they probably should still be moved to the discontinued-article, but placed into a "being phased out" section or similar. The main article should then probably also get a brief listing of the instruction set extensions that have been moved to the discontinued-article. Punpcklbw (talk) 01:38, 27 June 2022 (UTC)[reply]

You're a machine.... I've been busy the past few days but I'll get to understanding your full table in due time. I'm not sure about having FP16 in the same column as the SSE instructions. The instruction set is all but unsupported and it's taking up precious vertical space. Maybe just consign them to the AVX-512 instruction list? Ovinus (talk) 05:47, 27 June 2022 (UTC)[reply]

At User:Ovinus/sandbox3 I have a draft intro for the SSE article, targeted toward people who have learned a bit of asm (perhaps in an undergrad CS class) but who otherwise haven't had much exposure to x86. I'll admit that the instruction encoding stuff is totally outside my comfort zone (I'm somewhat of an x86 apprentice--if even that) and I would appreciate any critiques and corrections. And otherwise, I'll iron out any factual errors when I source everything. Ovinus (talk) 15:54, 27 June 2022 (UTC)[reply]

Also, a minor detail (perhaps this is bikeshedding), but should we use "AVX-512" or "AVX512"? They seem to both occur pretty frequently, but Intel consistently uses the hyphen. Ovinus (talk) 15:59, 27 June 2022 (UTC)[reply]

Interesting that opcodes have different ring requirements depending on processor state. Is rdtsc/rdtscp one of them? I'm thinking footnotes, because the vast majority of instructions will run in any ring. "Phased out" makes sense, but it's important to avoid original research, so I'd suggest, instead of an entirely separate section called "phased out", just presenting them in rough order of deprecation, and saying which was/were the last processor(s) to support the instruction. Ovinus (talk) 16:22, 27 June 2022 (UTC)[reply]

I have now split out List of discontinued x86 instructions and List of undocumented x86 instructions - this appears to have cut the size of the main article by about a third or so.

Your draft intro looks OK so far, I think - it will probably be necessary to add at some point a description of how the VEX/EVEX prefixes work and the Intel notation for them ("EVEX.LLIG.F3.0F.W0 5E /r"), and some examples of instructions encoded both using so-called "legacy SSE" encoding and VEX/EVEX encoding.

As for instructions whose ring depend on CPU state, the ones I've found in the Intel SDM are:

EFLAGS.IOPL : affects IN,OUT,INS,OUTS,CLI,STI
CR4.TSD : affects RDTSC,RDTSCP
CR4.PCE : affects RDPMC
CR4.UMIP : affects SGDT,SIDT,SLDT,SMSW,STR

All of these seem reasonable to handle as footnotes.

As for the SSE-FP table (current version at [6], together with a pile of other SIMD tables I've been working on) - while having AVX512-FP16 instructions in the table IMO doesn't look too bad on my desktop, it does look a bit obnoxious on my laptop and it doesn't really add that much value, so yeah, it's probably better to split them out (which I haven't gotten around to try out yet).

For "AVX-512" vs "AVX512" - as it looks to me, the hyphen seems to be present when they're mentioning AVX-512 in general, but goes away when discussing its specific subsets, e.g. the foundation subset seems to always be referred to as "AVX512F", never "AVX-512F" or "AVX-512-F". Punpcklbw (talk) 00:51, 29 June 2022 (UTC)[reply]

Thanks for splitting them off! I'll do some reading on instruction encoding. Quick question: is the preferred terminology for mm/xmm/ymm/zmm logical registers "MMX/SSE/AVX/AVX-512" registers, or is there a meaningful difference between them? Ovinus (talk) 00:57, 29 June 2022 (UTC)[reply]

^ Instruction extended to 256-bit registers in AVX2, and to 512-bit registers in AVX-512.
^ Instruction extended to 256-bit registers in AVX2, and to 512-bit registers in AVX-512, but are in-lane only: shuffles may not cross 128-bit boundaries. Cross-lane permuting of double- and quadwords was added in AVX2 (vpermd and vpermq) and cross-lane byte permuting was added in AVX512 VBMI (vpermi2b {k}{z} zmm, zmm, zmm).
^ Instruction can only run in ring 0
^ Moves to and from control registers can only run in ring 0

Sources

Kusswurm, Daniel (2018). Modern X86 assembly language programming : covers X86 64-Bit, AVX, AVX2, and AVX-512 (2 ed.). New York, NY. ISBN 978-1484240625.{{cite book}}: CS1 maint: location missing publisher (link) [7]
[8] (modern instruction set listings)

India Education Program course assignment

This article was the subject of an educational assignment supported by Wikipedia Ambassadors through the India Education Program.

The above message was substituted from {{IEP assignment}} by PrimeBOT (talk) on 20:01, 1 February 2023 (UTC)[reply]

[1] Instruction extended to 256-bit registers in AVX2, and to 512-bit registers in AVX-512.

[2] Instruction extended to 256-bit registers in AVX2, and to 512-bit registers in AVX-512, but are in-lane only: shuffles may not cross 128-bit boundaries. Cross-lane permuting of double- and quadwords was added in AVX2 (vpermd and vpermq) and cross-lane byte permuting was added in AVX512 VBMI (vpermi2b {k}{z} zmm, zmm, zmm).

[3] Instruction can only run in ring 0

[4] Moves to and from control registers can only run in ring 0

[a]

[b]

[c]

[d]