编写编译器;哪个VM?

时间:2010-07-20 21:05:53

标签: compiler-construction

我将尝试为动态语言编写编译器。对某些现有的虚拟机最好 - 我还没有(还)想要处理垃圾收集以及一个好的VM为你处理的无数其他问题。您建议使用哪些虚拟机?

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

此外,基于堆栈和基于寄存器的VM有哪些优缺点?

性能和工具支持非常重要。我将在Haskell中编写编译器,因此一个好的接口是一个加号。

3 个答案:

答案 0 :(得分:9)

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

CLR有一个优点 - 它的设计目的是从一开始就支持多种语言,并且它(IMO)稍微容易使用,特别是如果你不打算写一个适合的语言针对该运行时的初始语言的原始“模具”。单声道效果很好,我不会因为它而回避CLR目标。

答案 1 :(得分:4)

LLVM为您提供了比直接x86程序集更好的编程模型。是的,这是低级别的。但是您不必担心寄存器schedulign或完全优化您的输出。此外,当你还在编写前端时,你可以利用它的类型系统来捕捉你可能犯的错误。

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

答案 2 :(得分:1)

.NET具有动态语言运行时,如Reed Copsey所述。但我甚至不知道CLR,更不用说DLR了 - 我也说不出任何一件事。 LLVM应该比普通的x86更好,但它仍然是低级别的。但我也不能说太多 - 只是一瞥。

但是,我看着帕罗特。这个想法本身非常棒,实现看起来很合理。如果我做一个动态语言,我很确定它将瞄准鹦鹉。 PIR(Parrot中间表示)对于VM来说是非常高级的。你有语法糖(arimethic运算符,assigments,调用子程序和从它们返回是一块蛋糕,...),不要弄乱确切的寄存器号码,但只需要尽可能多的数量,并为他们分配任何数字,甚至命名变量!

如果我必须选择,我认为我更喜欢基于寄存器的VM。研究表明,这些交易字节码的大小对于执行速度来说,这很适合我。另外,当我试图理解它们时,太复杂的堆栈操作往往会融合我的大脑 - 基于寄存器的操作变得更加自然。