3

好吧，伙计们，我想我会带上我的旧 CS 笔记并多看一下编译器理论。我不得不说我无法记住所有这些东西是如何工作的，但我确实有一个很好的大学时代的示例应用程序，可以帮助我理解一些事情。

此示例应用程序采用组合语言并将其编译为中间汇编代码，如语言。然后有一个简单的 VM 实现，它采用这种中间语言并执行语句。

我无法理解的是，如果我这是一个直截了当的解释器而不是编译器，它是否仍会在内存中构建这些中间命令以在最后执行。还是解释器实际上一次“执行”代码块的隐藏部分？

4

4 回答 4

4

这取决于语言。大多数现代解释语言（Perl、Python 和 Ruby，仅举几例）将源代码预编译成某种中间形式，以便在最后执行（引用）。

于 2009-03-06T20:53:19.163 回答
3

我编写或使用过解释器，这些解释器直接作用于解析输入中的标记，直接作用于解析器构建的抽象语法树 (AST)，并将 AST 转换为为高效执行而设计的形式。所以答案是，这取决于。

  • 如果您的目标机器有 8K 的 RAM，那么直接解析解释器将是一个明智的选择（想想 FORTH）。
  • 如果您正在使用解释器来教授或学习编程语言的结构和语义，那么构建和解释 AST 是一个不错的选择。
  • 如果您使用解释器来实现可移植性并且想要快速执行，那么编译到基于寄存器的虚拟机是一个不错的选择。（David Gregg 和其他人已经表明，在Lua VM 这样的基于寄存器的 VM 中，解释开销比在 Java VM 这样的基于堆栈的 VM 中要少。）
于 2009-03-06T22:29:12.567 回答
1

解析器不编译。翻译程序时实际上涉及很多步骤（从 C++ 等高级语言到机器代码）。它取决于设计是一次性执行还是在多次通过输入后执行。你能把你的问题说得更具体一点吗？同时，不管你多么讨厌它，看看这里——特别是前端和后端部分。

于 2009-03-06T20:54:10.207 回答
1

大多数现代解释器将程序解析为中间代码，然后再进行解释。有些显式存储此中间代码（例如 Python 的.pyc）。也有例外，例如，shell 脚本被直接解释，而不是被解析为中间格式。

一些更高级的“解释器”实际上并不解释，而是进行 JIT（即时）编译（例如 Java 或 .NET）。

于 2009-03-06T21:24:14.550 回答