c - 将语言编译为 C 是个好主意吗？

Question

在整个网络上，我都觉得为编译器编写 C 后端不再是一个好主意。 GHC 的 C 后端不再被积极开发(这是我不受支持的感觉)。编译器以 C-- 或 LLVM 为目标。

通常，我会认为 GCC 是一个很好的老式成熟编译器，在优化代码方面表现出色，因此编译为 C 将利用 GCC 的成熟度来生成更好更快的代码。这不是真的吗？

我意识到这个问题在很大程度上取决于所编译语言的性质以及其他因素，例如获得更易于维护的代码。我正在寻找一个更通用的答案(w.r.t. 编译语言)，它只关注性能(无视代码质量，..等)。如果答案包括解释为什么 GHC 正在远离 C 以及为什么 LLVM 作为后端(see this)或任何其他我不知道的编译器执行相同操作的示例，我也会非常高兴。

Answer 1

让我列出我在编译为 C 时遇到的两个最大问题。如果这是您的语言的问题，则取决于您拥有什么样的功能。

• 垃圾收集 当您进行垃圾收集时，您可能不得不在程序中几乎任何一点中断常规执行，此时您需要访问指向堆。如果你编译成 C 你不知道那些指针可能在哪里。 C 负责局部变量、参数等。指针可能在堆栈上(或者可能在 SPARC 上的其他寄存器窗口中)，但没有真正访问堆栈。即使你扫描堆栈，哪些值是指针？ LLVM 实际上解决了这个问题(虽然我不知道效果如何，因为我从未将 LLVM 与 GC 一起使用过)。

• 尾调用 许多语言假定尾调用有效(即它们不会增加堆栈)； Scheme 规定它，Haskell 假定它。 C 不是这种情况。在某些情况下，您可以说服某些 C 编译器进行尾调用。但是你希望尾调用是可靠的，例如，当尾调用一个未知函数时。有一些笨拙的解决方法，例如蹦床，但没有什么能令人满意。