是否可以制造一个支持多个ISA的处理器？（例如：ARM和x86）

英特尔自Skylake（？）架构以来一直在内部将CISC指令解码为RISC指令，AMD自K5处理器以来一直在这样做。那么这是否意味着x86指令在执行过程中会被转换成一些奇怪的内部RISC ISA？如果这就是正在发生的事情，那么我想知道是否有可能创建一个既能理解x86指令又能理解ARM指令的处理器（即内部转换为自己的专有指令）。如果可能的话，表演会是什么样子？为什么还没有这样做呢？

国际审计准则越是不同，就越难做到和更高的开销，尤其是后端。这并不像将不同的前端放到一个普通的后端微体系结构设计上那么容易

如果这只是不同解码器的芯片面积成本，而不是其他功率或性能差异，那么在晶体管预算较大的情况下，这将是次要且完全可行的。（在芯片的关键部分占用空间，使重要的东西彼此相距更远，这仍然是一项成本，但这不太可能成为前端的问题）。无论哪个解码器没有被使用，时钟甚至功率门都可以完全断电。但是正如我所说的，它不是那么简单，因为后端的设计必须支持ISA的指令和其他规则/功能；CPU不解码到完全通用/中立的RISC后端。相关：对现代英特尔设计中类似RISC的UOP的内部结构有一些想法和信息

例如，在Skylake中添加ARM支持功能将使其在运行纯x86代码时运行速度变慢，功耗降低，并且会占用更多的芯片面积。考虑到it市场的有限性，以及对特殊操作系统或虚拟机监控程序软件的需求，这在商业上是不值得的。（不过，多亏了苹果，AARC64变得更加相关，这可能会开始改变。）

可以同时运行ARM和x86代码的CPU在任何一个方面都比只处理一个代码的纯设计糟糕得多

• 高效运行32位ARM需要支持完全谓词执行，包括加载/存储的故障抑制。（与AArch64或x86不同，AArch64或x86仅具有ALU select类型指令，如

  csinc

  vs.

  cmov

  /

  setcc

  ，它们仅对标志及其其他输入具有正常的数据依赖性。）

• ARM和AArch64（尤其是SIMD随机数）有多条指令产生2个输出，而几乎所有x86指令只写入一个输出寄存器。因此，x86微体系结构用于跟踪最多读取3个输入（Haswell/Broadwell之前的2个输入）且仅写入1个输出（或1个reg+EFLAGS）的UOP

• x86要求跟踪CISC指令的独立组件，例如内存源操作数的加载和ALU UOP，或内存目标的加载、ALU和存储

• x86需要一致的指令缓存，并对修改已获取并在管道中传输的指令的存储进行窥探，或者以某种方式至少处理x86的强自修改代码（）

• x86需要一个。（程序订单+带存储转发的存储缓冲区）。您必须将其烘焙到加载和存储缓冲区中，因此我希望即使在运行ARM代码时，这样的CPU基本上仍将使用x86强大得多的内存模型。（现代Intel CPU会推测性地提前加载，并在错误推测时清除内存订单机，因此，也许您可以让这种情况发生，而不执行那些管道核弹。除非是由于错误预测加载是否由该线程重新加载最近的存储；当然，这仍然需要正确处理。）
  一个纯ARM可以有更简单的加载/存储缓冲区，它们之间没有太多的交互。（除了为了使

  stlr

  /

  ldar

  发布/获取更便宜，而不仅仅是完全暂停。）

• 不同的页面表格格式。（您可能会选择一个或另一个供操作系统使用，并且只支持另一个ISA供本机内核下的用户空间使用。）

• 如果您确实尝试完全处理来自两个ISA的特权/内核内容，例如，您可以使用任一ISA的虚拟机进行硬件虚拟化，那么您还可以使用控制寄存器和调试工具

---

这已经适用于其他ISA组合，尤其是AARC64+ARM，但x86-64和32位x86的机器代码格式略有不同，寄存器集更大。这些对ISA当然是为了兼容而设计的，新ISA的内核支持将旧ISA作为用户空间进程运行

最简单的是，我们有x86-64 CPU，它支持在64位内核下运行32位x86机器代码（在“兼容模式”下）。对于所有模式，它们完全使用相同的管道获取/解码/发布/无序执行管道。64位x86机器码有意地与16位和32位模式足够相似，因此可以使用相同的解码器，只有少数依赖于模式的解码差异。（比如inc/dec vs.REX prefix。）不幸的是，AMD故意非常保守，在64位模式下保留了许多x86的小缺点，以尽可能保持解码器的相似性。（也许，如果AMD64甚至没有流行起来，他们不想被困在人们不会使用的额外晶体管上。）

AArch64和ARM 32位是两种独立的机器码格式，在编码方面存在显著差异。e、 立即数操作数的编码不同，我假设大多数操作码都不同。管道大概有2个独立的解码器块，以及前端路由