为什么每个程序员都应该学习代码编译器知识

所有优秀的计算机科学学院都提供了编译器课程，但是相对比较少的学校把它作为本科课程的必修部分。这篇文章回答了这个问题：为什么需要学习编译器知识？即使你从没打算过编写编译器。

我写这篇文章的其中一个原因是，尽管我在读本科时很喜欢编译器课程，但是我几乎看不到它的实际作用。大多数资料看起来要么简单易懂，要么很深奥（事实上，我找到的大部分编译器资料都是很枯燥的。）无论怎样，我用了几年时间总结了为什么这类课程会如此有用的实际原因。原因如下。

分析器和解析器无处不在

严谨的程序员不得不去了解分析器和解析器，因为我们不会总是只写一些小程序。每次你写一个可扩展的程序或处理一种新类型的输入文件，你都需要了解它们（分析器和解析器）。格林斯潘第十定律：

“任何C或Fortran程序复杂到一定程度之后，都会包含一个临时的、只有一半功能的、不完全符合规格的、充满bug的、运行速度很慢的Common Lisp实现。”

我们花费如此多的时间在这些事情上，我们可以使用一次性的小技巧来做这些事情的每一个，或者我们利用60年的理论和实际知识去解决问题，并把它做对。重要的是：你应该什么时候借用已存在的代码或者使用已存在的工具？理论知识在什么时候可以提供帮助？哪些语言设计原则可以运用在我们日常使用的小语言？

你能更好地编写正确的代码

编译器应该把输入的语言正确地翻译成合法的程序。为了达到这个目标，编译器开发者必须了解整个输入语言，包括一些普通程序员没见过的罕见问题。这个理解过程是通往程序语言本质的重要一步，它和我们平时写代码时所看到的不一样。举个例子，我在学习了顺序点（sequence points），未定义行为（undefined behaviors），和常用的算术转换的细节后，完全改变了我对C语言的理解。C编译器编写者已经掌握这些概念了，但大多数初级和中级程序员都不知道这些概念。毫不夸张地说，一旦你知道语言的本质，你会以不同地方式和更准确地思考这个语言。这适用于任何的语言，特别是像C和C++这些语义不清晰的语言。

你可以编写更快的代码

通过了解编译器，你可以很清晰地知道哪些优化是编译器可以优化的，和哪些是编译器不能进行优化的，无论他们看起来是多么的合理和简单。你将会学到哪类代码通常会建造最佳代码块，为什么会这样和这些代码做了什么。你会知道为什么一些代码可以拥有更好的性能，比如使用一半寄存器组缓存滤波系数一半寄存器组缓存样本的FIR滤波器，它和使用普通优化器实现的不一样。你和你喜欢的编译器是一个能创建快速代码的团队，你可以使用它高效地工作，或者使用提前优化等无意义的技巧来修改它。

其次，编译器后端是与目标架构密切关联的，当然，现代的架构都尽量提供汇编程序员友好的平台，而且离着不远了。通过理解编译器后端和它为什么是这样产生代码的，你会对计算机架构的操作有更好的理解。

总结

编译器（理论上）有三部分：

• 语言相关的前端（分析，类型检测）
• 与语言和目标无关中端（优化））
• 目标相关的后端（生成机器代码）

在这篇文章里，我已经试图说服你们，理解编译器的每一部分都是有价值的–即使你将来不会实现或者修改它们。