解释器实际上是在内存中预编译的吗？

Question

好的家伙我以为我会把旧的CS笔记和编译器理论看一下。我不得不说我不能为我的生活记住所有这些东西是如何工作的，但我在大学时代有一个很好的示例应用程序，这有助于我了解一些事情。

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

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

Answer 1

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

Answer 2

我已经编写或使用解释器直接解析输入中的令牌，直接作用于解析器构建的抽象语法树（AST），并将AST转换为专为高效执行而设计的表单。所以答案是，取决于。

• 如果你的目标机器有8K的RAM，直接解析翻译将是一个明智的选择（想想FORTH）。
• 如果您使用口译员来教授或了解编程语言的结构和语义，那么构建和解释AST是一个不错的选择。
• 如果您正在使用解释器来实现可移植性并希望快速执行，那么编译到基于寄存器的虚拟机是一个不错的选择。 （David Gregg和其他人已经表明，基于寄存器的VM（如Lua VM）的解释开销少于基于堆栈的VM（如Java VM）。）

Answer 3

解析器不编译。翻译程序时实际上涉及很多步骤（从像C ++这样的高级语言到机器代码）。如果它一次执行或多次通过输入后，它取决于设计。你能让你的问题更具体一些吗？与此同时，无论你多讨厌它，看看here - 特别是前端和后端部分。

Answer 4

大多数现代解释器将程序解析为中间代码，后者将被解释。有些人明确地存储了这个中间代码（例如Python的.pyc）。例如，有例外，shell脚本被直接解释，而不是解析为中间格式。

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