最佳编译器目的地

Question

我正在构建几种解释器语言。当我准备迈出“下一步”时，什么是非本地编译格式的最佳选择……它们各自的优缺点是什么？

我一直在研究编译成CLR或LLVM，并多次考虑C-midcompile，但我不完全确定。

我希望能够移植以下几个特性：

1. REPL- 我正在构建的其中一种语言支持运行时块级别的评估。
2. 强大的宏- 我正在构建的其中一种语言需要在标记化之前和解析之间进行代码筛选的能力。

好吧，其实只有两个。我想我能够将我的语言支持的任何其他功能移植到“任何地方”。

哪些选项是最佳的，以及它们的优缺点是什么？

- user54650

Answer 1

代码生成是我的业务 :-)

对几个选项的评论：

• CLR:

  • 优点：工业支持
  • 缺点：你必须完全接受他们的类型系统；根据你想用类型做什么，这可能并不重要
  • 缺点：只有 Windows 平台真正具备实用性

• LLVM:

  • 优点：热情洋溢的用户社区和 charismati 领导人
  • 优点：得到了苹果公司的严肃支持
  • 优点：许多有趣的性能改进
  • 缺点：接口有些复杂
  • 缺点：工程方面历史上存在漏洞；随着 LLVM 的成熟，预计将通过增加接口的复杂性来弥补这些漏洞。

• C--

  • 优点：目标是一个实际编写的语言，而不是一个 API；您可以轻松检查、调试和编辑您的 C-- 代码
  • 优点：设计相当成熟和清晰
  • 优点：支持精确的垃圾回收
  • 优点：大多数用户报告它很容易使用
  • 缺点：非常小的开发团队
  • 缺点：截至 2009 年初，仅支持三个硬件平台（x86、PPC、ARM）
  • 缺点：不附带垃圾收集器
  • 缺点：该项目没有未来

• C 作为目标语言

  • 优点：看起来很简单
  • 缺点：几乎不可能获得良好的性能
  • 缺点：在长期内将让你发疯；问问那些试图使用这种技术编译 Haskell、ML、Modula-3、Scheme 等语言的人们。这些人中有些人最终放弃了，并构建了自己的本地代码生成器。

总结：除了 C 以外的任何语言都是一个合理的选择。为了获得最佳的灵活性、质量和预期寿命的组合，我可能会推荐使用 LLVM。

完整披露声明：我与 C-- 项目有关联。

- Norman Ramsey

---

只是一个小提示：你不必使用LLVM的API，而是可以针对其类似汇编语言进行目标编程。 - Frank

Answer 2

优缺点：

• CLR：

  • 优势：CLR环境易于使用；许多绑定可用。
  • 劣势：受限于CLR（;-）；定位某些系统将会很困难或不可能（嵌入式、大型机等）。在非微软系统上的CLR实现可能不够成熟。

• LLVM：

  • 优势：独立于微软。
  • 劣势：为一些系统定位可能需要移植LLVM（？）；与DOT-net、Java等接口可能会麻烦（可能需要FFI）。

• C作为目标语言：

  • 优势：几乎所有目标平台都可以实现；易于进行代码生成。
  • 劣势：您将需要实现一些VM库，如运行时库（GC、动态加载、动态编译等）；有些事情在C中难以实现（continuations、backtracking、stack tracing、exceptions）；有些事情在C中难以高效且可移植地实现（GC、dynamic types、stack layout dependence）。

• Java ByteCode作为目标：

  • 优势：可能是最大的目标平台集合（甚至移动电话和嵌入式设备）；周围有许多现有工具；易于与现有库进行接口。
  • 劣势：一些事情很难实现或难以高效地实现（dynamic types、continuations、backtracking）。

从上述内容来看，我认为针对Java ByteCode可能是最适合您的选择。

编辑：实际上是回复评论，但300个字符不够。

JByteCode不可靠 - 我同意（作为Smalltalker，JBytecode对我来说太受限制了）。

在虚拟机方面，我认为JVM的性能范围比较宽，从纯慢字节码解释器到高端复杂的JITting VMs（IBM）都有。我猜CLR VM会赶上来，因为微软无论如何都会窃取和整合所有的创新，并且加速动态翻译的技术已经发布（例如阅读Self论文）。LLVM可能会进展得稍慢一些，但谁知道呢。对于C语言，您将免费受益于更好的编译器，但是像动态重编译等事情在以C为目标时很难实现。我的系统使用预编译和动态编译代码的混合方法（具有所有：一个缓慢的字节码解释器、JITter和预编译的静态C代码在一个内存空间中）。

- blabla999

---

Java字节码一直让我感到犹豫。可以说是由于不好的过去经验。它们中有没有任何关于内部虚拟机性能的优势（除了库调用之外）？ - user54650

C代码生成似乎很容易，直到你做了6到18个月后。然后突然间变得困难起来。 - Norman Ramsey

Answer 3

LLVM看起来很有前途。与本地后端相比，该团队声称在gcc上具有更好的运行时性能。从AST编译的能力非常有趣（请查看教程）。它可以在运行时进行编译和优化，这对于动态语言是必须的。它也可以作为纯解释器运行。

我考虑在涉及创建类似Tcl语言的项目中使用LLVM。Tcl非常动态，因此我不知道这意味着什么，但我相信我会比当前基于字节码的核心获得更好的性能。

- fbonnet