我在中间代码章节做类编译器设计。通过在网上做一些研究，我发现了这句话：
当源程序可以包含复合指令时，递归解释是必要的。
我在谷歌上找不到什么复合指令。
问问题
144 次
4 回答
2
在这种情况下（请参阅链接），作者正在与他所谓的迭代解释器进行对比，迭代解释器只是读取每条指令并遵守它，然后继续执行下一条指令，并且必须分析一系列找到按什么顺序执行它们的说明。
但是，对我来说，这种材料的质量似乎值得怀疑。
于 2009-10-10T16:45:55.587 回答
1
# High level languages support the use of complex expressions.
# Example:
x + y * z / (w + 1)
解析器使用递归技术来分析复杂的表达式并构造语法树。
于 2009-10-10T16:41:46.093 回答
1
那一章有点啰嗦。
口译员：
以一种语言表示的程序，它执行以另一种语言表示的程序。
对于解释器用相同语言编写的情况，请参阅自我解释器和元循环解释器。
解释器编译源程序并立即执行它。
不，那将是一个及时的编译器；解释器可以使用 JIT 技术，但也可以用于减小已编译可执行文件的大小。真正的解释器不是 JIT 编译器。
解释比执行编译的机器代码慢。
通常，尽管有时使用完整源代码的解释器可以进行比 JIT 编译器更好的优化。
当源程序可以逐行执行时，可以进行迭代解释。
如果不是，也有可能，除非他们使用“迭代解释”来表示“一次读取一行源代码并处理它”，但后来他们有“一个 [迭代] 解释器 [...] 重复一个序列获取，分析和执行。[...]在迭代循环中重复。“，所以不 - 一旦你解析并完成一些处理，你可以用任何输入很好地做到这一点。
命令语言的解释器可以是迭代的。
没错，但在这方面命令语言并没有什么特别之处。任何语言都可以使用迭代或递归方法来解释。
当源程序可以包含复合指令时，递归解释是必要的。
您可以将任何递归过程映射到具有显式堆栈的迭代过程，因此递归实现绝不是绝对必要的。
我假设这与术语是复合的表达式的含义相同，主要是因为这是唯一有意义的方式。
如果您有一名口译员可以看到：
z = a + 5
然后对于表达式a + 5，它可以查找的值a是什么并且它知道常量5，然后它可以计算a + 5并将结果存储在 中z。
如果表达式是：
z = a + ( b * c )
然后它可以查找的值a是什么，但要计算b * c它要么必须递归调用自身，要么压入z = a + pop()堆栈并计算push(b*c)。
为了使用迭代解释器解释复合术语的表达式，您可以使用临时变量将源转换为线性形式，因此：
z = a + ( b * c )
变成：
temp = b * c
z = a + d
因此，所有具有复合项的表达式都可以简化为非复合项。通常这种转换是在代码到达解释器的主循环之前完成的，从而使主循环更简单、更快。
高级语言的解释器必须是递归的。
假的，见上。
查询语言的解释器必须是递归的。
假的，见上。
递归解释比迭代解释慢。
一般来说是正确的，但我相信如果你寻找它们，会有一些例外。
于 2009-10-10T18:06:51.257 回答
-1
这里给你一个参考：
于 2009-10-10T16:22:23.277 回答