是否可以制造一个支持多个ISA的处理器? (例如:ARM + x86)

时间:2020-08-16 18:46:37

标签: x86 arm hardware cpu-architecture processor

自从他们的Skylake(?)体系结构以来,英特尔一直在内部将CISC指令解码为RISC指令,而自从其K5处理器以来,AMD一直在这样做。那么,这是否意味着x86指令在执行期间会转换为某些奇怪的内部RISC ISA?如果这是正在发生的事情,那么我想知道是否有可能创建一个能够同时理解(即,内部转换为其专有指令)x86和ARM指令的处理器。如果可能的话,性能会如何?为何还没有完成呢?

2 个答案:

答案 0 :(得分:3)

ISA越不同,难度就越大。 这将花费更多的开销,尤其是后端。这并不像将另一个前端划分到通用的后端微体系结构设计上那样容易。

如果这只是不同解码器的裸片面积成本,而不是其他功率或性能差异,那将是微不足道的,并且如今随着晶体管预算的增加是完全可行的。 (在芯片的关键部分占用空间,使重要的东西彼此远离,这仍然是一项成本,但在前端不太可能成为问题)。时钟或什至电源门控都可以完全关闭没有使用的解码器。但是,正如我说的那样,这不是很简单,因为后端必须设计为支持ISA的指令和其他规则/功能。 CPU不会解码为完全通用/中性的RISC后端。相关信息:Why does Intel hide internal RISC core in their processors?对现代英特尔设计中内部类似于RISC的控件有什么想法和信息。

例如,在Skylake中添加ARM支持功能将使其在运行纯x86代码时更加缓慢且功耗更低,并且会增加芯片面积。考虑到它的市场有限,并且需要特殊的OS或虚拟机管理程序软件才能充分利用它,因此在商业上不值得这样做。 (尽管随着苹果公司AArch64变得越来越重要,这种情况可能会开始改变。)

与仅处理一个代码的纯设计相比,一个可以同时运行ARM和x86代码的CPU的性能要差得多。

  • 要有效地运行32位ARM,需要支持完全确定的执行,包括对装载/存储的故障抑制。 (与AArch64或x86不同,后者仅具有ALU选择类型的指令,例如csinccmov / setcc,它们仅对FLAGS及其其他输入具有正常的数据依赖性。)

  • ARM和AArch64(尤其是SIMD改组)具有多个产生2个输出的指令,而几乎所有x86指令仅写入一个输出寄存器。因此,建立了x86微体系结构来跟踪可读取最多3个输入(在Haswell / Broadwell之前2个)并且仅写入1个输出(或1 reg + EFLAGS)的uops。

  • x86需要跟踪CISC指令的各个组成部分,例如内存源操作数的负载和ALU运算符,或内存目标的负载,ALU和存储。

  • x86需要一致的指令高速缓存,并监听用于修改已经获取并在管道中运行的指令的存储,或者以某种方式至少处理x86强大的自修改代码ISA保证(Observing stale instruction fetching on x86 with self-modifying code)。

  • x86需要一个strongly-ordered memory model 。 (程序顺序+具有存储转发功能的存储缓冲区)。您必须将其放入加载和存储缓冲区中,因此我希望即使在运行ARM代码时,这样的CPU基本上仍会使用x86强大得多的内存模型。 (现代Intel CPU推测性地提早加载,并在错误推测的情况下清除了内存订购机器,因此也许您可以让这种情况发生,而进行这些流水线操作。除非是由于错误而造成的。 -预测加载是否正在通过此线程重新加载最近的存储;当然仍然必须正确处理该加载。)

    一个纯ARM可以具有较简单的加载/存储缓冲区,它们之间的交互作用不大。 (除了为了使stlr / ldar发行/获得便宜而不仅仅是完全停滞的目的。)

  • 不同的页表格式。 (您可能会选择一个或另一个供操作系统使用,并且仅在本机内核下为用户空间支持另一个ISA。)

  • 如果您 did 尝试完全处理两个ISA中的特权/内核内容,例如因此,您可以使用任一ISA的VM进行硬件虚拟化,并且还拥有诸如控制注册和调试功能之类的东西。


对于ISA的其他组合(特别是AArch64 + ARM )已经存在,但是x86-64和32位x86的计算机代码格式略有不同,并且寄存器集更大。这些对ISA当然被设计为兼容的,并且新ISA的内核具有将旧ISA作为用户空间进程运行的支持。

在最简单的范围内,我们拥有x86-64 CPU,它们支持在64位内核下运行32位x86机器代码(以“ compat模式”)。对于所有模式,它们完全使用相同的管道获取/解码/发行/乱序执行管道。 64位x86机器码特意类似于16位和32位模式,可以使用相同的解码器,但与模式相关的解码差异很小。 (就像inc / dec与REX前缀一样。)不幸的是,AMD故意非常保守,在64位模式下,许多小的x86疣保持不变,以使解码器尽可能相似。 (也许万一AMD64甚至没有流行起来,他们也不想卡住人们不愿使用的额外晶体管。)

AArch64和ARM 32位是单独的机器代码格式,在编码方面有显着差异。例如立即数操作数的编码方式不同,我认为大多数操作码都不同。假定流水线具有2个独立的解码器块,并且前端根据模式通过一个或另一个路由指令流。与x86不同,两者都相对容易解码,因此大概还不错。要将指令转换成一致的内部格式,这两个块都不必很大。但是,支持32位ARM确实意味着在整个管道中实现了对谓词的有效支持。

早期的Itanium(IA-64)也具有对x86的硬件支持,定义了x86寄存器状态如何映射到IA-64寄存器状态。这些ISA完全不同。我的理解是x86的支持或多或少被“强化”了,芯片的一个单独区域专门用于运行x86机器代码。性能不好,比好的软件仿真还差,因此,一旦准备好,硬件设计就会放弃它。 (https://en.wikipedia.org/wiki/IA-64#Architectural_changes

那么这是否意味着x86指令在执行过程中被转换为一些奇怪的内部RISC ISA?

是的,但是“ RISC ISA”与ARM不同。例如它具有x86的所有特性,例如,如果移位计数为0,则移位使FLAGS保持不变。(现代Intel通过将shl eax, cl解码为3 oups来处理该问题;如果后面的指令想要从班次中读取标志。)

可能需要一个更好的后端怪异示例,例如x86部分寄存器,例如写入AL和AH,然后读取EAX。后端的RAT(寄存器分配表)必须跟踪所有这些,并发出合并uops或由它处理。 (请参见Why doesn't GCC use partial registers?)。

答案 1 :(得分:0)

简短回答。是的,可以做到。参见/ Google“大型机微码”。是的,已经完成了大型机和小型机的安装。由于这些天的cpus已针对其自身的体系结构进行了高度优化,因此如果使用备用微代码,则不太可能获得良好的性能。经验表明,在微码中用cpu y对cpu x进行仿真是一个不小的问题。您最终需要比原始设计人员更了解这两个cpus。天堂帮助您改变面具。最好编写更高级别的仿真器。经验之声。

相关问题