clr - 为什么CLR和JVM使用基于堆栈的体系结构？

Question

我一直很好奇为什么JVM和CLR具有基于堆栈的体系结构？
他们为什么不使用基于寄存器的方法？
与基于寄存器的方法相比，它有什么好处？

Answer 1

我曾经考虑过寄存器和堆栈机之间的差异，比较指令序列，并运行基准测试...

然后，我花了几年的时间在Parrot VM(这是一台注册机)上工作时实现了这两种类型的机器。我们天真地从固定的寄存器集开始，结合了数据和寄存器堆栈，但最终得出结论，这是人为的限制，因此我们改为使用无限的寄存器集和分配器。在某些时候，Parrot快速核心(GCC计算的goto)的性能优于Mono和JVM解释器核心(非JIT)，但差异归结为JIT。派诺特的准时生产技术从未达到其他产品的水平。最终机器的制造者是JITter的素质，而这正是人们所关心的。如果所有虚拟机都遵循相同的规则(例如，它们具有在没有JIT的解释模式下运行的约束)，那么我的证据表明，寄存器计算机在等效堆栈计算机上的性能优势。更大的指令，但是更少的指令==更高的吞吐量(IPC)，以及更好的引用缓存位置。 Dalvik JVM实际上支持了我的发现，Dalvik几年没有JIT，并且与其解释器内核竞争。

很少有主流VM专门以解释模式(AFAIK)运行，它们通过JIT进行编译，这就是我们的基准。解释器核心的重点是在平台上建立状态，执行字节码验证并在没有JIT的情况下提供故障保护执行核心。当然，这不是规则。有数十亿个设备在不使用JIT的情况下运行ARM加速JVM的设备，但是在没有内存或CPU限制的情况下，这适用。

我一直在努力调整内核，测试和调优，但最终发现我们确实需要快速的JIT。我得出的结论是，如果您最终要进行JIT，则执行堆栈还是注册机器并开始执行您喜欢的事情并不重要。但是使用堆叠机可以更快地“推向市场”。对虚拟机内核的字节码解释进行大量的伪寄存器计算机虚拟优化，部分是浪费的工作，因为这不是真正的 native 优化。软核不像真实处理器那样进行分支预测，寄存器重命名，指令重排序，并行执行或预取。我的感觉是，一旦我们拥有了针对本地二进制文件的高质量JIT，我们便到达了相同的目的地。

出于这些原因，从技术上讲，我赞成基于堆栈的计算机:

简单性-更少的代码维护=更少的错误

实现

的时间

但是从视觉和情感上来说，我都喜欢使用注册机来实现:

视觉概念模型与机器更匹配，并且我的
脑

灵活性-编译器可以评估其表达式树
使用SSA以不同的顺序排列。

请注意，我并不是说编译器可以更“轻松”地生成代码。这似乎是那些主要使用堆栈计算机工作的人喜欢争论的东西。我不相信，也没有发现这是真的。我看到很短时间内在Parrot和CLR上编写了许多业余爱好的编译器，尽管我承认CLR上的编译器质量较高，但这主要是生态系统和可用工具的质量之一。我自己在两个平台上编写了编译器，但发现有一些折衷之处，但不足以使自己陷入沉睡。

这是一个有根据的猜测，因为我的实际经验不包括编写完整的JITter，因此我没有第一手经验来比较JIT各种形式的操作码的优缺点，但是我的看法是，如果您打算包括一个JIT，然后创建一个极其复杂的虚拟机操作码核心，这是过早的优化。您的时间最好花在其他地方。