使用 JIT 编写解释器的 RPython 之外的选项？答案

【问题标题】：Options beyond RPython for writing interpreters w/ JITs?使用 JIT 编写解释器的 RPython 之外的选项？
【发布时间】：2012-08-21 00:22:18
【问题描述】：

我真的对 PyPy 项目很感兴趣，但它的第一个（但不太为人所知）的目的如下：

一套用于为解释语言实现解释器的工具
使用此工具链的 Python 实现

在下面的博文http://morepypy.blogspot.com/2011/04/tutorial-writing-interpreter-with-pypy.html 和http://morepypy.blogspot.com/2011/04/tutorial-part-2-adding-jit.html 中，有一个详细的教程，介绍了如何使用 RPython 实现一个brainfork 解释器，并添加一个JIT。

但是我在其他地方读到过，RPython 使用起来可能很麻烦——为动态类型创建的语法突然限制为推断的静态类型会导致难以理解的编译错误。

所以我的问题是，有没有其他项目可以让你像上面的教程那样编写一个大脑软糖解释器/JIT？还是说 PyPy 是简洁的唯一选择？

（旁白）：如果存在的话，一般来说，RPython 的意义何在？是否只是为了表明可以使 Python 的子集成为类型安全的，并且 Python 在该子集中实现？在现有的解释器创建工具中做“PyPy”会更有意义吗？

【问题讨论】：

标签： pypy brainfuck rpython

【解决方案1】：

但是我在其他地方读到过，RPython 使用起来可能很麻烦——为动态类型创建的语法突然限制为推断的静态类型会导致难以理解的编译错误。

它与语法无关（Python 语法与类型唯一有关的是它没有类型注释的位置，并且可以 - 并且在 3.0 中 - 改变了），以及更多关于：

好的错误消息是严重困难的，并且它们的代码几乎不可避免地会随着编译器的其余部分发生变化而发生变化。因此，当您处理高度复杂的代码，编译由少数专家（通常是编写翻译器的人）而不是普通大众编写的代码时，这需要付出很多努力，并且是第一个要走的弯路。翻译器的操作方式与通常的编译器完全不同这一事实也无济于事。
一切都是推断出来的，这意味着对类型的唯一洞察（对于您作为读者而言）来自理解和心理应用翻译者推断类型的过程。这与通常的编译器技术完全不同，而且并非微不足道。

所以我的问题是，有没有其他项目可以让你像上面的教程那样编写一个大脑软糖解释器/JIT？还是说 PyPy 是简洁的唯一选择？

我不知道有任何其他项目尝试从解释器创建 JIT 编译器。当 PyPy 人这样做时，我很有信心这个想法是新的，所以像这样的其他东西（如果存在的话）比 RPython 更成熟的可能性很小。有许多项目可以帮助各个方面。还有一些可以同时解决许多或“所有”这些方面的问题，例如 Parrot。但 AFAIK 没有一个能像 PyPy 那样引人入胜。

Parrot 是一个用于动态语言的 VM，并具有多个后端（我刚刚了解到，自 v1.7 以来没有 JIT，但该架构允许透明地重新引入一个），并且显然为语言实现者开发了一套丰富的工具。 CLR 和 JVM 为静态面向对象语言提供类似的服务，但我不知道有哪些工具像 Parrot 那样复杂。

但是，它不是您编写解释器，而是定义 am IR（实际上是几个解释器），您的工作是将语言编译为该 IR（并以 VM 可以理解的术语定义内置功能）。在这方面，它与编写解释器的 RPython 方法不同。此外，与其他虚拟机一样，如果您的语言的某些方面严重映射到 IR，您将被搞砸。需要与 VM 服务完全不同的东西吗？玩得开心模仿它（并遭受糟糕的表现）。需要特定语言的优化（对任意 IR 无效，并且不能提前完成）？告别那些性能改进。除了玩具语言，我不知道 Parrot 上有完整的语言实现。而且由于他们不会经常吹嘘自己的表现，我担心他们目前在这方面很弱。

LLVM（其他人提到）以及许多其他代码生成器/后端只是其中一种成分。您必须编写一个成熟的静态编译器，将您的语言降低到机器代码的抽象级别，而不是解释器。这可能是可行的，但肯定是完全不同的。

如果存在，一般来说 RPython 有什么意义？

“编写 JIT 编译器很难，让我们~~去购物~~编写解释器。”好吧，它可能一开始是“我们想用 Python 做 Python，但它太慢了，我们不想从头开始制作一种编程语言”。但是现在，RPython 本身就是一种非常有趣的编程语言，因为它是世界上第一个将 JIT 编译器作为一流（不是真正意义上的一流函数，但足够接近）语言结构的编程语言.

在现有的解释器创建工具中做“PyPy”会更有意义吗？

只是为了成为元，进行研究并证明它有效，我赞成当前的方法。在 JIT 生成器工作之前，您可以在任何具有静态编译、C-ish 性能潜力和宏（或添加他们所谓的“翻译方面”的另一种方式）的语言中拥有相同的功能——尽管这些很少见.但是为整个 Python 语言编写一个性能良好（JIT 与否）的编译器一再证明对人类来说太难了。我想说写一个解释器，然后在一个单独的 JIT 编译器代码库中再次努力让它正确，并且仍然优化任何东西，这不会更有意义。

【讨论】：

太棒了，很好的答案！所以，我在想的是，如果“RPython”是 ML 语法（或任何其他已经静态类型化的语言），那会让在它之上实现 Python（或 BF）解释器/JIT 变得更容易吗？还是 RPython 有什么特别之处？
或者说，既然 C++ 已经存在，那么在 C++ 中创建一个 JitDriver 类并做同样的事情不是更容易吗？或者它不是那样工作的，即，如果你这样做，你是否必须从头开始编写 C++ 编译器/“翻译器”？（为什么？）
@lobsterism 是的，您基本上必须为要替换 RPython 的语言编写编译器。 RPython 翻译器可以将 JIT 添加到 RPython 程序的唯一原因是因为它控制从 Python 字节码到控制流图到类型推断到降低到 C 级抽象再到插入“翻译方面”（包括像无堆栈和沙盒）。阅读 JIT 的工作原理，它本质上是一个 用于 RPython 代码的 JIT 编译器，具有允许有效处理类似解释器的程序的附加功能。
@lobsterism 就是说，继承类型系统和某些 R语言的类型注释的语法可能有一些价值。但是即使忽略社交方面，使用 Python 作为基础语言也有一个重要的理由：您可以在前端重用 PyPy 的 Python 解析器和字节码编译器，以及用于控制流图生成的解释器（通过“流对象空间”），因此您可以专注于类型推断、转换和后端。
@lobsterism：是的。翻译框架本身（“RPython 编译器”）是用普通 Python 编写的，而不是 RPython。所以如果不用 RPython 重写就无法编译，我的理解是翻译框架是一个非常复杂的软件，用 RPython 编写起来要困难得多。