字节码堆栈与三个地址答案

【问题标题】：Byte code stack versus three address字节码堆栈与三个地址
【发布时间】：2011-09-15 23:53:03
【问题描述】：

在设计字节码解释器时，这些天是否就堆栈或三地址格式（或其他什么？）更好？我正在考虑这些注意事项：

【问题讨论】：

【解决方案1】：

如果您想到 JIT，那么字节码是唯一的选择。

【讨论】：

OP 已经决定使用字节码 - 他要求解释器的一些实现细节
@Ken Wayne VanderLinde：啊，那个......答案取决于该语言将拥有什么样的内存模型以及对项目整体复杂性/规模的要求。基于堆栈的简单而紧凑。 TIScript 是基于堆栈的单值寄存器（又名累加器）。我认为这是合理的速度/尺寸折衷。实际上 accumulator 有一个 256 个槽的数组，用于从函数返回多个值。

【解决方案2】：

阅读The evolution of Lua 和The implementation of Lua 5.0，了解 Lua 如何从基于堆栈的虚拟机转变为基于寄存器的虚拟机，以及它为何获得性能提升。

【讨论】：

【解决方案3】：

我在这方面没有太多（实际上没有）经验，因此您可能想自己验证以下一些内容（或者其他人可以在必要时纠正我？）。

我现在最常使用的两种语言是 C# 和 Java，所以我自然倾向于他们的方法。正如大多数人所知，两者都编译为字节码，并且两个平台（CLR 和 JVM）都使用 JIT（至少在主流实现中）。另外，我猜每个平台的抖动都是用 C/C++ 编写的，但我真的不确定。

总而言之，这些语言及其各自的平台与您的情况非常相似（除了动态部分，但我不确定这是否重要）。此外，由于它们是如此主流的语言，我相信它们的实现可以作为您设计的一个很好的指南。

除此之外，我确信 CLR 和 JVM 都是基于堆栈的架构。我记得基于堆栈与基于寄存器的一些优势是

另外，我发现基于堆栈更直观和可读，但这是一个主观的事情，就像我之前说的，我还没有看到太多的字节码。

基于寄存器的架构的一些优点是

当然，总有办法抵消每种方法的缺点，但我认为这些描述了要考虑的显而易见的事情。

【讨论】：

CLR 看起来不像“基于堆栈”。它从来不是为解释而设计的。如果您仔细查看它的指令集，您不会发现除了琐碎的 pop 和 dup 之外的任何堆栈操作。没有交换和类似的东西，就像在 JVM 中一样。所有现有的 .NET JIT 都首先将这个“堆栈”表示转换为 3 地址形式，然后是 SSA 转换。而对于 JVM，这一步要复杂得多，因为堆栈行为的可预测性较差 - 有关详细信息，请参阅 HotSpot 源代码。

【解决方案4】：

看看 OCaml 字节码解释器 - 它是同类中最快的之一。它几乎是一个堆栈机器，在加载时转换为线程代码（使用 GNU 计算的 goto 扩展）。也可以生成类似 Forth 的线程代码，应该比较容易做到。

但是，如果您要考虑将来的 JIT 编译，请确保您的堆栈计算机不是真正功能齐全的堆栈计算机，而是表达式树序列化形式（如 .NET CLI）- 这样您就可以d 能够将您的“堆栈”字节码转换为 3 地址形式，然后转换为 SSA。

【讨论】：

【解决方案5】：

David Gregg 和 Roberto Ierusalimschy 所做的实验表明，基于寄存器的字节码比基于堆栈的字节码更有效，因为执行相同任务所需的字节码指令更少（因此解码开销也更少）。所以三地址格式显然是赢家。

【讨论】：