我知道人们之前已经提出了类似这样的问题，但是有太多相互矛盾的信息，我真的想尝试一劳永逸地清理它。我将通过明确区分指令集架构（ISA）和实际硬件实现来尝试这样做。首先我尝试澄清：
1。）目前还有intel64和amd64 CPU（除其他外，但这些都是重点）
2.）鉴于ISA是一个或多个CPU指令的二进制表示，这意味着ISA与其实际硬件实现完全分开。
我的问题：
intel 64和amd64 CPU之间的区别是否与不同或扩展的x86-64 ISA有关？或者x86-64 ISA的不同硬件实现？或两者兼而有之？
答案 0 :(得分：5)
是的，ISA是文档/规范，而不是硬件。正确实现所有这些是x86 CPU的原因，而不仅仅是与x86具有相似性的东西。
请参阅x86代码维基以获取官方文档的链接（英特尔手册）。
英特尔和AMD的implementations of the x86 ISA differ主要是在性能方面，以及对它们支持的指令集的扩展。软件可以使用CPUID指令查询支持的内容。
这个相关的问题有几个答案，涉及这个问题所询问的一些相同的事情。
这里的一个主要分歧是英特尔，AMD和威盛each have their own hardware-virtualization extensions甚至都试图兼容。因此，像Xen这样的VM需要单独的驱动程序＆＃34;或＆＃34;后端＆＃34;每个扩展的代码。但这些仍然是扩展，而不是基线x86的一部分。
用户空间程序使用的SIMD扩展最终可用于两者，由于Intel's efforts to screw over AMD with anti-competitive practices，通常会延迟。这花费了其他所有人的时间，并且通常对整个x86生态系统有害（例如，SSSE3本来可以被认为是更多软件的基准），但有助于英特尔的底线。这里有一个很好的例子：AMD Bulldozer支持FMA4，但英特尔在最后一刻改变了主意，并在Haswell中实施了FMA3。在他们的下一个微型游戏（Piledriver）之前，AMD并没有支持它。
鉴于ISA是一个或多个CPU指令的二进制表示。
不，ISA远不止于此。英特尔记录在所有x86 CPU上的所有内容都是ISA的一部分。这不仅仅是每条指令的详细行为，还有像控制寄存器那样做的东西，以及内存排序规则。基本上，英特尔和AMD发布的手册中的所有内容都没有在这样一个特定的CPU模型上开始，并且＃34;
我预计在某些情况下，英特尔和AMD的系统编程指南在x86应如何工作方面存在差异。 （如果他们为自己的x86 CPU发布了自己的版本，那就是VIA）。我还没有检查过，但我非常确定用户空间不会受此影响：如果存在差异，它们仅限于特权指令，只有在内核运行它们时才有效。无论如何，在这种情况下，我想你可以说x86 ISA是英特尔和AMD文档的通用子集。
请注意，尝试查找实际硬件在实践中的作用对于理解文档很有用，但不能替代阅读文档。您不希望您的代码依赖于指令在您测试的CPU上的行为方式。
然而，英特尔确实使用真实软件测试他们的新设计，因为无法运行现有版本的Windows将是商业上的缺点。例如Windows9x doesn't invalidate a TLB entry that could only have been filled speculatively（此示例的所有其余部分只是该详细博客文章的摘要和推断）。这可能是基于它是安全的（并且当时在硬件上是安全的）假设的性能黑客，或者是未被注意到的错误。当时通过硬件测试无法检测到它。
现代英特尔CPU进行推测性的页面行走，但即使最近Haswell检测并击落了错误推测，因此假设这种情况不会发生的代码仍然有用。
这意味着真正的硬件提供了比ISA更强的订购保证，它说：
处理器可以缓存预取和访问所需的转换，这些转换是在执行的代码路径中实际上永远不会发生的推测性执行的结果。
尽管如此，依赖于这种更强的行为将是一个错误，除非你只在已知的微体系结构上进行。 AMD K8 / K10就像英特尔，但Bulldozer家族推测没有任何检测+回滚机制来提供连贯性，因此Win9x内核代码在该硬件上并不安全。未来的英特尔硬件也可能会放弃检测+回滚机制。
TL：DR：所有的搜索都实现了x86 ISA所说的内容，但有些提供了更强的保证。如果你像微软一样大，那么英特尔和AMD将设计出能够重现代码所依赖的非ISA指定行为的CPU。至少在软件过时之前。不能保证未来的英特尔搜索将保留回滚机制。
另一个例子：输入为零的 bsf指令会使其输出未定义according to the paper spec in Intel's insn ref manual。
但是对于任何特定的CPU，都会有一些行为模式，比如将输出设置为零或保持不变。从理论上讲，由于不同的微体系结构状态，对于相同的输入，无序执行CPU实际上会产生不可预测的结果是有效的。
但英特尔选择在芯片中实施的行为是在bsf或bsr输入为零时始终保持目的地不变。 AMD也做同样的事情，甚至是文件的行为。它基本上是一个非官方的保证，mov eax,32 / bsf eax, ebx将完全像tzcnt一样工作（标志设置除外，例如基于输入为0的ZF，而不是输出）
这就是popcnt / lzcnt / tzcnt have a false dependency on the output register in Intel CPUs!。
CPU供应商通常超越了纸质ISA规范，以避免破坏某些依赖于此行为的现有代码（例如，如果该代码是Windows的一部分，或者是英特尔的其他主要软件/ AMD测试他们的新CPU设计。）
As Andy Glew said in a comment thread关于上面提到的连贯的页面漫游事项，以及关于自我修改代码：
特定实现必须实现与架构语句兼容但更强的规则，这是很常见的。但并非所有实现都必须采用相同的方式。