指令集是如何标准化的？
How are instruction sets standardized?
我的理解是 AMD64 是 AMD 作为 x86 的 64 位版本发明的。
AMD 和英特尔都添加了新指令（因为只有这两家公司实施了 AMD64）。实际上，没有像 C++ 那样的中央标准。
添加新指令时，它们通常是“集合”的一部分，例如 sse 或 avx。
在我的研究中，一些指令的指定是不一致的，即指令属于哪个集合并不总是很清楚
什么定义了指令集？哪些指令在哪些集合中，是否存在普遍共识，还是由惯例决定？
没有这样的东西，也不敢想象怎么会有。
英特尔的一个或多个人为其产品定义指令集，期间。如果 AMD 碰巧能够制造合法的克隆（他们拥有）并且作为该协议的一部分，或者甚至可能没有但有一些惩罚，他们会添加额外的 instructions/features。首先，如果他们想要兼容的话，他们应该这样做并保持某种兼容性。其次，如果他们想要添加扩展并且可以摆脱它，那完全是 AMD 内部的一名或多名工程师。然后，如果英特尔去制定一些新的指令，那就是一个或多个英特尔工程师。随着历史的发展，你会遇到其他完全不相关的各方，例如 gnu 工具人员、Microsoft 工具人员和一系列其他人员，以及使用工具和制造产品的操作系统人员，直接或间接地选择使用哪些指令。随着历史的发展，其中一些只有英特尔或只有指令可能会受到一方或另一方的青睐。如果那一方碰巧有影响力（微软 windows、linux 等），以至于它给英特尔或 AMD 施加压力，使其以某种方式倾斜，那是他们的管理和工程在他们的公司内这样做。他们可以选择不满足用户的需求，并尝试将用户推向他们的方向。一条或另一条产品线的简单销售可能会决定双方决策的成败。
我想不出人们实际上同意的一个或多个标准，即使他们可能有代表穿着带有相同徽标的衬衫参加标准机构。从 pcie 到 java 再到 C++ 等（C 和 C++ 真的很糟糕，因为它们是在编写后尝试标准化的，它们只是补丁，太多留给了各个编译器作者的解释选择）。您想在业务中取胜，您就会使自己与众不同。我有一个 x86 克隆，它便宜得多，但性能与英特尔一样好 95%。另外，我添加了我自己的英特尔没有的东西，我付钱给员工添加到开源的东西，让这些开源的东西成为可选的，以获得 feature/performance 的提升。这使我在竞争中脱颖而出，对于一些用户来说，我是他们唯一的选择。
架构的指令集（随着时间的推移，x86 有很长的架构线，arm 也有，而且它们在 imo 方面更有条理，等等）由该公司内的个人或团队定义。故事结局。充其量他们可能不得不避免专利（是的，有些专利你必须避免，这使得很难制作新的指令集）。如果英特尔和 AMD（或英特尔团队 a vs 英特尔团队 b，amd 团队 a vs ...）等两个相互竞争且兼容的架构碰巧相互采用 features/instructions 它更多地是由市场驱动的，而不是某些标准机构。
基本上去看看 itanium 与 amd64 以及结果如何。
x86 的历史有点像噩梦，我仍然无法理解为什么它仍然存在（与指令集的质量无关，而是业务的运作方式），因此尝试将在事物上贴上标签并将它们组织到单独的盒子中，实际上不会增加任何价值并且会造成一些混乱。 intel的r代有这个，amd的m代有那个，我的工具支持r代这个，m代那个。明年我将亲自选择是否要支持每个人的下一代。永远重复，直到产品死亡。您还必须选择是否要支持老一代，因为它们可能具有相同的指令，但具有不同的 features/side 效果，尽管理论上是兼容的。
80x86 is/was 本质上是 8086 指令集（从 1970 年代后期开始）加上不同供应商添加的“可选”扩展；许多扩展变得无处不在（一段时间后所有供应商都支持有效的“伪标准”）； cross-licensing 协议允许一个供应商提供另一个供应商扩展的兼容实现。
随着时间的推移，这个（所有“可选但无处不在”的扩展）变得很尴尬。帮助解决这个问题； AMD 创建了“AMD64”，这是给大量不同扩展（来自不同供应商）的名称，以形成一个新的 base-line。它由长模式（来自 AMD 的 64 位扩展，从 Intel 扩展了一些不同的扩展 - 主要是 32 位保护模式扩展和“PAE 分页”扩展），加上 SSE（来自 Intel），加上 SYCALL（来自 AMD），加上很多 smaller/older 的东西（TSC，CPUID，INVLPG，MSR，...... - 主要来自英特尔）。当然，cross-licensing 协议意味着其他供应商可以实施所有这些不同的扩展（因此实施新的“AMD64”base-line）；因此英特尔和威盛都在他们的 CPU 中添加了对 AMD64 的支持。
每个其他 ISA 的相似之处在于都有一个基本标准（例如 Aarch64）和特定于供应商的扩展（例如 Apple 添加到其 M1 芯片中的矩阵和机器学习加速器）。根本区别在于没有针对任何其他 ISA 的 cross-licensing 协议（例如，如果高通想要实施 Apple 的扩展，他们可能最终会打一场长达数年的官司）。
另一个区别是 80x86 有一个明确的方法让软件识别可选扩展（通过 cpuid 指令），它被分成供应商特定的范围（例如英特尔的 extensions/features 从0x0000000，hypervisor extensions/features 从 0x4000000 开始，AMD 的 extensions/features 从 0x8000000 开始，Transmeta 从 0x8086000 开始，Centaur/VIA 从 0xC000000 开始）。这允许供应商在不引起冲突的情况下随时添加自己的扩展；并允许软件在所有供应商 CPUs（以及来自同一供应商的旧 CPUs 和新 CPUs）上正常工作然后启用对 CPU 提供的扩展的支持（例如粗略地像“if( CPU_supports(thing) ) { use_thing(); } else { use_alternative(); }”）。
What defines the instruction sets? Is there a universal agreement what what instructions are in which sets or is it decided by convention?
每个供应商都定义了自己的扩展（不会浪费 3 年时间与竞争对手争论以最终达成“由委员会设计”的妥协）。
请注意，有时这意味着您会获得相互竞争的替代扩展（例如 3DNow 与 SSE，或 SYSCALL 与 SYSENTER，或 AMD 的虚拟化扩展与 Intel 的，或...）。他们中很少有人正式死亡（例如 3DNow）。
另一件值得一提的事情是，对于 ISA 本身，非常强调向后兼容性。您几乎可以保证明年的 CPU 仍然能够使用 40 年前的 运行 16 位软件。不管是好是坏，破坏向后兼容性的是其他一切（OS、设备、固件......），而不是 ISA 或扩展。
我的理解是 AMD64 是 AMD 作为 x86 的 64 位版本发明的。
AMD 和英特尔都添加了新指令（因为只有这两家公司实施了 AMD64）。实际上，没有像 C++ 那样的中央标准。
添加新指令时，它们通常是“集合”的一部分，例如 sse 或 avx。
在我的研究中，一些指令的指定是不一致的，即指令属于哪个集合并不总是很清楚
什么定义了指令集？哪些指令在哪些集合中，是否存在普遍共识，还是由惯例决定？
没有这样的东西，也不敢想象怎么会有。
英特尔的一个或多个人为其产品定义指令集，期间。如果 AMD 碰巧能够制造合法的克隆（他们拥有）并且作为该协议的一部分，或者甚至可能没有但有一些惩罚，他们会添加额外的 instructions/features。首先，如果他们想要兼容的话，他们应该这样做并保持某种兼容性。其次，如果他们想要添加扩展并且可以摆脱它，那完全是 AMD 内部的一名或多名工程师。然后，如果英特尔去制定一些新的指令，那就是一个或多个英特尔工程师。随着历史的发展，你会遇到其他完全不相关的各方，例如 gnu 工具人员、Microsoft 工具人员和一系列其他人员，以及使用工具和制造产品的操作系统人员，直接或间接地选择使用哪些指令。随着历史的发展，其中一些只有英特尔或只有指令可能会受到一方或另一方的青睐。如果那一方碰巧有影响力（微软 windows、linux 等），以至于它给英特尔或 AMD 施加压力，使其以某种方式倾斜，那是他们的管理和工程在他们的公司内这样做。他们可以选择不满足用户的需求，并尝试将用户推向他们的方向。一条或另一条产品线的简单销售可能会决定双方决策的成败。
我想不出人们实际上同意的一个或多个标准，即使他们可能有代表穿着带有相同徽标的衬衫参加标准机构。从 pcie 到 java 再到 C++ 等（C 和 C++ 真的很糟糕，因为它们是在编写后尝试标准化的，它们只是补丁，太多留给了各个编译器作者的解释选择）。您想在业务中取胜，您就会使自己与众不同。我有一个 x86 克隆，它便宜得多，但性能与英特尔一样好 95%。另外，我添加了我自己的英特尔没有的东西，我付钱给员工添加到开源的东西，让这些开源的东西成为可选的，以获得 feature/performance 的提升。这使我在竞争中脱颖而出，对于一些用户来说，我是他们唯一的选择。
架构的指令集（随着时间的推移，x86 有很长的架构线，arm 也有，而且它们在 imo 方面更有条理，等等）由该公司内的个人或团队定义。故事结局。充其量他们可能不得不避免专利（是的，有些专利你必须避免，这使得很难制作新的指令集）。如果英特尔和 AMD（或英特尔团队 a vs 英特尔团队 b，amd 团队 a vs ...）等两个相互竞争且兼容的架构碰巧相互采用 features/instructions 它更多地是由市场驱动的，而不是某些标准机构。
基本上去看看 itanium 与 amd64 以及结果如何。
x86 的历史有点像噩梦，我仍然无法理解为什么它仍然存在（与指令集的质量无关，而是业务的运作方式），因此尝试将在事物上贴上标签并将它们组织到单独的盒子中，实际上不会增加任何价值并且会造成一些混乱。 intel的r代有这个，amd的m代有那个，我的工具支持r代这个，m代那个。明年我将亲自选择是否要支持每个人的下一代。永远重复，直到产品死亡。您还必须选择是否要支持老一代，因为它们可能具有相同的指令，但具有不同的 features/side 效果，尽管理论上是兼容的。
80x86 is/was 本质上是 8086 指令集（从 1970 年代后期开始）加上不同供应商添加的“可选”扩展；许多扩展变得无处不在（一段时间后所有供应商都支持有效的“伪标准”）； cross-licensing 协议允许一个供应商提供另一个供应商扩展的兼容实现。
随着时间的推移，这个（所有“可选但无处不在”的扩展）变得很尴尬。帮助解决这个问题； AMD 创建了“AMD64”，这是给大量不同扩展（来自不同供应商）的名称，以形成一个新的 base-line。它由长模式（来自 AMD 的 64 位扩展，从 Intel 扩展了一些不同的扩展 - 主要是 32 位保护模式扩展和“PAE 分页”扩展），加上 SSE（来自 Intel），加上 SYCALL（来自 AMD），加上很多 smaller/older 的东西（TSC，CPUID，INVLPG，MSR，...... - 主要来自英特尔）。当然，cross-licensing 协议意味着其他供应商可以实施所有这些不同的扩展（因此实施新的“AMD64”base-line）；因此英特尔和威盛都在他们的 CPU 中添加了对 AMD64 的支持。
每个其他 ISA 的相似之处在于都有一个基本标准（例如 Aarch64）和特定于供应商的扩展（例如 Apple 添加到其 M1 芯片中的矩阵和机器学习加速器）。根本区别在于没有针对任何其他 ISA 的 cross-licensing 协议（例如，如果高通想要实施 Apple 的扩展，他们可能最终会打一场长达数年的官司）。
另一个区别是 80x86 有一个明确的方法让软件识别可选扩展（通过 cpuid 指令），它被分成供应商特定的范围（例如英特尔的 extensions/features 从0x0000000，hypervisor extensions/features 从 0x4000000 开始，AMD 的 extensions/features 从 0x8000000 开始，Transmeta 从 0x8086000 开始，Centaur/VIA 从 0xC000000 开始）。这允许供应商在不引起冲突的情况下随时添加自己的扩展；并允许软件在所有供应商 CPUs（以及来自同一供应商的旧 CPUs 和新 CPUs）上正常工作然后启用对 CPU 提供的扩展的支持（例如粗略地像“if( CPU_supports(thing) ) { use_thing(); } else { use_alternative(); }”）。
What defines the instruction sets? Is there a universal agreement what what instructions are in which sets or is it decided by convention?
每个供应商都定义了自己的扩展（不会浪费 3 年时间与竞争对手争论以最终达成“由委员会设计”的妥协）。
请注意，有时这意味着您会获得相互竞争的替代扩展（例如 3DNow 与 SSE，或 SYSCALL 与 SYSENTER，或 AMD 的虚拟化扩展与 Intel 的，或...）。他们中很少有人正式死亡（例如 3DNow）。
另一件值得一提的事情是，对于 ISA 本身，非常强调向后兼容性。您几乎可以保证明年的 CPU 仍然能够使用 40 年前的 运行 16 位软件。不管是好是坏，破坏向后兼容性的是其他一切（OS、设备、固件......），而不是 ISA 或扩展。