Question

我正在中间代码的章节中进行类编译器设计。通过在线进行一些研究，我发现了这句话：

当源程序可以包含复合指令时，递归解释是必要的。

我无法在google上找到复合指令。

Answer 1

在这种情况下（参见the link），作者正在与他称之为迭代解释器的对比，迭代解释器只读取每条指令并服从它，然后转到下一条指令，并且必须对一系列指令进行分析，以找出执行它们的顺序。

但是，对我而言，这种材料的质量似乎值得怀疑。

Answer 2

# High level languages support the use of complex expressions.
# Example:

x + y * z / (w + 1)

Parsers使用递归技术来分析复杂表达式并构造语法树。

Answer 3

那chapter有点啰嗦。

解释器：

用一种语言表达的程序，用另一种语言表达程序。

有关使用相同语言编写解释器的情况，请参阅self interpreter和meta-circular interpreter。

解释器编译源程序并立即执行。

不，那将是just in time compiler; JIT技术可以由解释器使用，但也可用于减少已编译可执行文件的大小。真正的解释器不是JIT编译器。

解释比执行编译的机器代码慢。

通常情况下，虽然有时候完整源代码的解释器可以比JIT编译器更好地进行优化。

当源程序可以逐行执行时，迭代解释是可能的。

如果不是这样，也可能，除非他们使用“迭代解释”来表示“一次读取一行源代码并处理它”，但后来他们有了 “[迭代]解释器[...]重复读取，分析和执行的序列。[...]在迭代循环中重复。”，所以不 - 你可以很好地完成任何输入，一旦你解析了它并做了一些处理。

命令语言的解释器可以是迭代的。

是的，但在这方面command languages并没有什么特别之处。任何语言都可以使用迭代或递归方法进行解释。

当源程序可以包含复合指令时，递归解释是必要的。

您可以将任何递归过程映射到具有显式堆栈的迭代过程，因此递归实现绝不是严格必需。

我认为这意味着与术语复合的表达式相同，主要是因为这是唯一合理的方式。

如果您有口译员，可以看到：

z = a + 5

然后对于表达式a + 5，它可以查找a的值是什么，它知道常量5，然后它可以计算a + 5并存储结果在z。

如果表达式是：

z = a + ( b * c )

然后它可以查找a的值是什么，但是要计算b * c，它必须递归调用自身，或者将z = a + pop()推送到堆栈并计算{{1} }}。

为了使用迭代解释器解释复合术语的表达式，您可以使用临时解码器将源转换为线性形式，因此：

push(b*c)

变为：

z = a + ( b * c )

所有带复合项的表达式都可以简化为非复合词。通常这种转换是在代码到达解释器的主循环之前完成的，这使得主循环更简单，更快。

高级语言的解释器必须是递归的。

错，见上文。

查询语言的解释器必须是递归的。

错，见上文。

递归解释比迭代解释慢。

一般都是，但我确信如果你找到它们会有一些例外。

Answer 4

以下是您的参考资料：