compiler-construction - 自举的缺点？

Question

我已经看到很多关于引导的链接，我想知道使用 C 编程而不是使用汇编语言为一种语言(例如 X)引导编译器的主要缺点是什么？我想知道使用 C 是否会将我所做的任何事情限制为像汇编语言创建这样的“C”(即 C 的编译器是如何做到的)。

例如，我在 Python 中编写的任何内容最终都会由 CPython 处理，使其最终在硬件中以类似 C 的方式编写——这可能不是最佳的？

当然，C 可能是非常好的语言，但对于其他一些通用语言来说可能并非如此。 bootstrap 最终不会有一些瓶颈，特定于我用于制作 bootstrap 编译器的语言的限制吗？就像机器代码生成就像 C 生成代码一样，而不是一些随机的方式。

使用 C 的主要原因是它可以很好地将我们的代码映射到机器语言，但不如汇编，对吧？所以 C 有一些性能问题，现在我使用 C 为另一种语言创建编译器，所以我必须传递这些性能问题，对吗？毕竟 C 并没有对程序集进行 1-1 映射 - 希望你能得到我的问题。

Answer 1

我们之前有一个非常相似的问题，要求一个 Python interpreter in assembly language 。所有这些也适用于编译器:这是一项令人难以置信的努力(以至于几乎不可能完成这种规模的任何事情)，它使维护成本爆炸式增长，如果它有帮助的话，它给你带来的 yield 很少 - 在至少有 2/3 的情况，它会积极有害，因为我们没有人能打败现代 C 编译器。

然后你的推理还有另一个问题:虽然我们确实希望我们的编译器快速完成，以使编写-编译-调试周期的中间部分不那么烦人和浪费时间，但编译器的性能不会影响性能编译后的程序 - 后者(特别是实际上可能的最佳运行时性能)通常更重要。为此，您需要许多非常复杂的算法进行非常巧妙的优化。如前所述，大型解释器在汇编语言中已经很难甚至不可能。进行所有这些优化更加困难。

哦，虽然我们在这里:引导实际上可以导致 更好的 性能。 PyPy 项目在 Python 的(子集)中实现了 Python。你说慢得可怕？ 错! 它几乎可以比 CPython 更快地运行所有程序，CPython 是用 C 语言编写的(它尽可能地映射到汇编语言)，并且经过多年的优化，由非常聪明的人进行了优化。通常，它只需要所需时间的一小部分。诚然，他们通过使用 Just In Time 编译器获胜，该编译器本质上非常适合优化动态语言。但即使是非 JIT 版本，一个普通的解释器，通常也比 CPython 慢不到 2 倍。请参阅 PyPy speed center 。