language-agnostic - 为什么编译器不翻译成更简单的语言？

Question

通常，编译器将其支持的语言转换为汇编语言。或最多只能使用一种类似于汇编的语言(字节码)，例如用于GCC的GIMPLE/GENERIC或Python/Java/.NET字节码。

将编译器翻译成一种已经实现了其语法大子集的简单语言，会不会更简单？

例如，与C具有100％兼容性的Objective-C编译器，只能为其扩展到C的语法添加语义，然后将其翻译为C。可以使用此Objective-C编译器将其代码转换为C，以便使用另一种不支持C++的编译器来编译生成的C代码(但可以进行更多优化，或者编译速度更快，也可以针对更多架构进行编译) )。或者一个人可以在只允许使用C的项目中使用生成的C代码。

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

将会受到什么样的处罚？生成的代码很难被人类理解吗？编译器将无法像现在这样进行最大程度的优化吗？还有什么？

Answer 1

实际上，通过使用Intermediate languages，许多语言都使用了它。最大的例子是Pascal，它具有Pascal-P系统:Pascal被编译成一种假想的汇编语言。移植pascal只会意味着为此汇编语言制作一个编译器:这个任务比移植整个pascal编译器要简单得多。编写完此编译器后，您只需要编译在此编写的(独立于机器的)pascal编译器。

bootstrap 在编程语言设计中也经常使用。许多语言的编译器都是用相同的语言编写的(Haskell在这里浮现在我的脑海)。通过这样做，为该语言编写新功能仅意味着将该想法转换为当前语言，然后将其放入编译器，然后重新编译。

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

但是在大多数情况下，编译器确实可以翻译成更简单的语言，但最基本的系统语言除外。