编写编译器；哪个虚拟机？答案

【问题标题】：Writing a compiler; which VM?编写编译器；哪个虚拟机？
【发布时间】：2010-07-20 21:05:52
【问题描述】：

我将尝试为动态语言编写编译器。最好是一些现有的虚拟机——我（还）不想处理垃圾收集和无数其他问题，一个好的虚拟机可以为你处理。您建议使用哪些虚拟机？

我在 Linux 上，所以我不知道 .NET（通过 Mono）是否是个好主意。我听说 Parrot 对动态语言很有用，但我还没有听说过任何语言使用它。我应该自己发明吗？ LLVM 甚至算作我应该编译的 VM，还是和直接 x86 一样难？

另外，基于堆栈的虚拟机与基于寄存器的虚拟机有什么优缺点？

性能和工具支持很重要。我将在 Haskell 中编写编译器，所以一个好的接口是加分项。

【问题讨论】：

著名的 Donald E. Knuth 设计用来解释他的算法的“神话机器”怎么样？仍然有几个 MIX 模拟器。

标签： compiler-construction

【解决方案1】：

JVM (Java) 和 CLR (.NET) 似乎是这两个最常见的目标，因为它们都为您处理了大部分这些问题。两者都提供了相当简单的指令集。

CLR 有一个优势 - 它的设计目标是从一开始就支持多种语言，而且 (IMO) 使用起来稍微容易一些，特别是如果您不打算编写适合的语言针对该运行时的初始语言的原始“模具”。 Mono 运行良好，我不会因此而回避 CLR 目标。

【讨论】：

但是动态语言，例如 Python，是否必须使用邪恶的变通方法才能工作？毕竟，.NET 是为 C# 设计的……此外，工具对非 C# 语言的支持如何？我的意思是，我肯定会有字节码级别的调试，但是编写更高级别的工具有多容易？
@pavpanchekha：CLR 并不是专门为 C# 设计的——它从一开始就考虑了其他语言（例如 VB.NET）。有了 DLR，它就更好了 - 请参阅 IronPython、IronRuby、VB.NET、C# 以及此处的所有语言：en.wikipedia.org/wiki/Microsoft_.NET_Languages
这就是我说 CLR 在这里有一些优势的主要原因——从第一天开始它就被设计为“语言中立”——JVM 可以通过这种方式完成，它是为 Java 设计的开始...

【解决方案2】：

LLVM 为您提供比直接 x86 汇编更好的编程模型。是的，它是低级的。但是您不必担心注册计划或完全优化您的输出。此外，当您仍在编写前端时，您可以利用它的类型系统来捕捉您可能犯的错误。

也就是说，您必须开发自己的运行时层来处理语言的“动态”部分。仅就这部分而言，我可能倾向于坚持使用 CLR。

【讨论】：

您仍然需要担心完全优化您的输出。寄存器调度在 x86 上是否有用是值得怀疑的。您从它的 6 个“通用”寄存器中获得了哪些性能优势？
LLVM 的指令集公开了无限数量的 SSA 寄存器。作为程序员，您不必担心将所有变量放入平台实际提供的寄存器数量中，也不必担心如何最好地将它们溢出到堆栈中。
在 LLVM 中，获取 IR 表示只是编译器前端完成的第一步。大多数优化都是在后端的 IR 上完成的。如果您编写了一个输出 IR 的工具，您可以利用现有的后端优化器，这样您就不必设计您的系统来执行循环不变的代码运动。

【解决方案3】：

.NET 具有动态语言运行时，如 Reed Copsey 所述。但我什至不知道 CLR，更不用说 DLR 了——我也什么都说不出来。 LLVM 应该比普通的 x86 更好，但它仍然是低级的。但我也说不上太多——只看几眼。

不过，我调查了 Parrot。这个想法本身非常棒，实现看起来很合理。如果我曾经制作过一种动态语言，我很确定它会针对鹦鹉。 PIR（Parrot 中间表示）对于 VM 来说是非常高级的。你有语法糖（算术运算符，分配，调用子程序并从它们返回是小菜一碟，......），不要弄乱确切的寄存器编号，而只需取你想要的任意数量并为它们分配任何数字，甚至还有命名变量！

如果我必须选择，我认为我更喜欢基于寄存器的 VM。研究表明，这些以字节码大小换取执行速度，这很适合我。另外，当我尝试理解它们时，过于复杂的堆栈操作往往会使我的大脑变得混乱 - 基于寄存器的操作更自然地恕我直言。

【讨论】：