Search code examples
assemblyx86-64instruction-set

How are instruction sets standardized?


My understanding is the AMD64 was invented by AMD as a 64 bit version of x86.

New instructions are added by both AMD and Intel (because those are the only two companies that implement AMD64). In effect, there is no central standard like there is in C++.

When new instructions are added, they are usually a part of a "set" like sse or avx.

In my research, the designation for some instructions is inconsistent, ie, it's not always clear which set an instruction belongs to.

What defines the instruction sets? Is there a universal agreement on what instructions are in which instruction sets or is it decided by convention?


Solution

  • There is no such thing, and I cannot imagine how there would be.

    One or more people at intel define their instruction sets for their products, period. If AMD happens to have been able to make legal clones (which they have) and as part of that agreement or perhaps even not but with some penalty, they add additional instructions/features. First off it is on them to do it and keep some sense of compatibility, if they even want to be compatible. Second if they want to add extensions and can get away with it it is purely within AMD one or more engineers. Then if intel goes and makes some new instructions, it is one or more intel engineers. As history played out you then have other completely disconnected parties like gnu tools folks, microsoft tools folks and a list of others, as well as operating system folks that use tools and make their products, choosing directly or indirectly what instructions get used. And as history plays out some of these intel only or amd only instructions may be favored by one party or another. And if that party happens to have influence (microsoft windows, linux, etc), to the point that it puts pressure on intel or amd to lean one way or another, they it is their management and engineering that does that, within their company. They can choose to not go with what the users want and try to push users in their direction. Simple sales of one product line or another may dictate the success or failure of each parties decisions.

    I cannot think of a or many standards that folks actually agree on even though they might have representatives that wear shirts with the same logo on them that participate in the standards bodies. From pcie to java to C++, etc (C and C++ being really bad since they were written then attempts to standardize later, which are just patches and too much left to individual compiler authors choices of interpretation). You want to win at business you differentiate yourself from the others. I have an x86 clone that is much cheaper but performs 95% as well as intel. Plus I added my own stuff that intel does not have that I pay employees to add to open source stuff, making those open source things optional to gain that feature/performance boost. That differentiates me from the competition, and for some users locks me in as their only choice.

    Instruction sets for an architecture (x86 has a long line of architectures over time, arm does too and they are more organized about it imo, etc) are defined by that individual or teams within that company. End of story. At best they may have to avoid patents (yep there have been patents you have to avoid, making it hard to make a new instruction set). If two competing and compatible architectures like intel and amd (or intel team a vs intel team b, amd team a vs ...) happen to adopt each others features/instructions it is more market driven not some standards body.

    Basically go look at itanium vs amd64 and how that played out.

    The x86 history is a bit of a nightmare and I still cannot fathom why it still even exists (has nothing to do with the quality of the instruction set but instead how the business works), and as such attempting to put labels on things and organize them into individual boxes, really does not add any value and creates some chaos. Generation r of intel has this, generation m of amd has that, my tool supports gen r of this and gen m of that. Next year I will personally choose if I want to support the next gen of each or not. Repeat forever until the products die. You also have to choose if you want to support an older generation as those may have the same instructions but with different features/side effects despite in theory being compatible.