我正在编写一个 Scheme 解释器(试图与 R5RS 完全兼容),它让我震惊的是,编译成 VM 操作码会使其更快。(如果我错了,请纠正我。)我可以解释内存中的 Scheme 源代码,但我一直在理解代码生成。
我的问题是:从解析树生成操作码需要哪些模式,例如 JVM 或任何其他 VM(甚至是真实机器)?如果有的话,这样做的复杂性、优点或缺点是什么?
我正在编写一个 Scheme 解释器(试图与 R5RS 完全兼容),它让我震惊的是,编译成 VM 操作码会使其更快。(如果我错了,请纠正我。)我可以解释内存中的 Scheme 源代码,但我一直在理解代码生成。
我的问题是:从解析树生成操作码需要哪些模式,例如 JVM 或任何其他 VM(甚至是真实机器)?如果有的话,这样做的复杂性、优点或缺点是什么?
对于 Scheme 来说,JVM 有两个主要的复杂性。
首先,JVM 不支持显式尾调用注释,因此如果不使用昂贵的迷你解释器技巧,您将无法保证R5RS (3.5) 要求的正确尾递归。
第二个问题是持续支持。JVM 没有提供任何对实现延续有用的东西,所以你必须再次使用迷你解释器。即,每个 CPS 普通函数都应该返回一个下一个闭包,然后由一个无限的迷你解释器循环调用。
但是仍然有许多有趣的优化可能性。我建议看一下 Bigloo(有一个相对较快的 JVM 后端)和 Kawa。对于一般编译技术,请在 90 分钟内查看Scheme 。
而且,解释仍然是编译的可行替代方案(至少在 JVM 上,由于其严重的限制和普遍的低效率)。看看 SISC 是如何实现的,这是一种非常有趣和创新的方法。