为什么编译器不使用更简单的语言进行翻译？

Question

通常编译器会将它们支持的语言转换为程序集。或者最多用于类似程序集的语言(字节码)，比如GCC的GIMPLE/Generic或Python/Java/.NET字节码。

如果编译器翻译成一种更简单的语言，它已经实现了语法的很大一部分，难道不是更简单吗？

例如，一个目标- C编译器，它100%与C兼容，可以只为它扩展到C的语法添加语义，并将它翻译成C。我可以看到这样做的许多优点；可以使用这个目标-C编译器将其代码转换为C，以便用不支持C++的不同编译器编译生成的C代码(但这可以优化更多，或者更快地编译，或者能够为更多的体系结构编译)。或者可以在只允许C的项目中使用生成的C代码。

我猜想/希望如果事情是这样的话，为当前语言编写扩展会容易得多(例如:添加C++关键字以简化常见模式的实现，或者仍然在C++中通过将内联成员函数移到头文件的末尾来删除“使用前声明”规则)。

会有怎样的惩罚呢？生成的代码很难为人类所理解？编译器不可能像现在这样优化那么多？还有什么？

Answer 1

实际上，通过使用中间语言，很多语言都使用它。这方面最大的例子是Pascal，它有Pascal系统:Pascal被编译成一种假设的汇编语言。移植pascal只意味着为这种汇编语言创建一个编译器:这个任务比移植整个pascal编译器要简单得多。在编写这个编译器之后，您只需要编译(与机器无关的) pascal编译器，这个编译器就是在这个编译器中编写的。

引导在编程语言设计中也经常使用。许多语言的编译器都是用同一种语言编写的(这里可以想到Haskell)。通过这样做，为语言编写一个新功能只意味着将该想法转换为当前语言，将其放入编译器，然后重新编译。

我不认为这种方法的问题实际上是生成代码的可读性(我不筛选通过编译器生成的汇编字节代码)，而是优化问题。高级编程语言中的许多思想(想到的是弱类型)很难自动转换为低级的系统语言，比如C。GCC之所以倾向于在代码生成之前进行优化是有原因的。

但在大多数情况下，编译器确实会将代码翻译成更简单的语言，除非是最基本的系统语言。

Answer 2

顺便提一句，作为一个反例，Tcl是一种众所周知非常-非常难(如果不是完全不可能)-翻译成C语言的语言。在过去的20年里，有几个项目尝试了这一点，甚至一个商业产品的承诺都没有实现。

在某种程度上，这是因为Tcl是一种非常动态的语言(就像任何具有eval函数的语言一样)。在某种程度上，这是因为知道什么是代码还是数据的唯一方法是运行程序。

Answer 3

由于Objective是C的一个严格的超集，而C++包含了非常多类似于C的内容，为了有效地解析C，在这种情况下，输出到机器代码和输出到更多的C代码在处理成本上并没有本质上的不同，用户的主要成本是编译现在需要的时间和第二个编译器所花费的时间一样长。

任何试图复制和粘贴类似于C的内容，并将其周围的其他内容翻译，都很容易出现问题。首先，C++不是一个严格的C超集，所以看起来像C的东西并不一定编译完全相同(特别是相对于C99)。即使他们这样做了，假设一个用户在他们的C中出错了，编译器也不倾向于以机器可读的格式提供错误信息，所以目标C到C层在收到例如“第99行的错误”之后很难给用户一个有意义的错误。

尽管如此，许多编译器套件，比如GCC，甚至更像即将发布的Clang + LLVM，都使用中间形式将知道一个体系结构的具体细节的位与知道特定语言的具体细节的位分离开来。然而，它更像是一种数据结构，而不是一种有意用书面语言表达的东西。

因此:编译器不会因为纯粹的实际原因而这样工作。