本小节将讨论编译器的翻译机制。实际上，先前讨论的词法、语法分析及生成符号表等工作无非都是为程序翻译提供决策支持的，翻译工作才是编译器的核心。读者应该对自然语言的翻译并不陌生，甚至不敢想象复杂的翻译工作可以由机器自动完成。自然语言翻译确实是一项复杂的工作，迄今为止，人们还无法实现一个精准的自然语言翻译系统。然而，程序设计语言与自然语言不同，机器翻译程序设计语言是完全可能的，并且已经有非常成功的实例。不过，笔者必须指出，编译器自动生成的目标代码的质量是无法达到或超越经过精雕细琢的手工代码的，即使是具有强大优化机制的GCC、Intel C++等也无法保证目标代码是最优的。当然，与一些计算机科学的经典问题类似，编译技术中的“代码最优化”也是难以衡量与评价的。

经过前面的讲解，编译器的翻译机制已经并不神秘了。编译器设计者就是通过在文法中插入相应的语义子程序，使之完成语法制导的翻译。在分析符号表处理时，笔者详细讲解了语法制导的理论与技术。不过，仅仅了解语法制导的翻译过程是远远不够的。这里，将从翻译方案入手，讨论翻译机制的实现。

翻译方案就是讨论源语言结构与IR之间的联系。例如，讨论case结构对应的IR序列、函数的IR等。翻译方案对编译行为、后端优化器设计及效能都有着很大的影响。目前，读者所熟悉的编译器都不是真正智能的（包括动态编译器）。编译过程中的每一步翻译都是有严格的算法定义的，编译器本身并不进行学习。当然，就编译器设计初衷而言，设计者也并不期望编译器独立思考与创新。在生成三地址代码的阶段，翻译方案就是设计算法的基础。下面看一个翻译方案的实例，见表5-4。

表5-4 for语句翻译方案实例

(www.daowen.com)

以上的实例是for语句的翻译方案，虽然两个方案结果都是正确的，但是无论是从代码的篇幅还是代码的效率而言，方案A明显优于方案B。翻译方案设计的主要工作就是得到相对较优的IR结构。这项工程对于熟悉三地址代码或者机器汇编的设计者来说，可能并不复杂。即便如此，翻译方案的设计同样是具有一定挑战性的。以case结构为例，众所周知，case语句（即C语言中的switch语句）是一种多分支结构。然而，由于大多数目标机指令系统都不支持多分支结构，因此，通常是将其翻译成多级嵌套的if-then-else结构。不过，针对图5-2所示的例程，不难发现，这个例程的特点是分支非常紧密。在这种情况下，继续使用if-then-else结构进行翻译就可能会显得比较臃肿。实际上，这种情况更适用于查表方案。这是一种经典的处理方式，有兴趣的读者可以参考汇编语言的教程。图5-2的例程是查表方案最简单的处理，实际上，查表方案也可以应用于一些分支非常多的情况。当然，这种情况下，编译器也需要为此付出一定的空间代价。这里，笔者的目的不在于讨论查表技术，而是想说明翻译方案选择的问题。

图5-2 case语句实例

针对不同的实际情况，存在不同的翻译方案，当然，有时它们是相对较优的。编译器如何选择翻译方案呢？例如，认定例程是分支紧密型的标准是什么？多少分支才认为是多分支情况？等等。通常，这些问题都需要编译器设计者经过一定的理论证明及实验总结后才能获得答案。因此，翻译方案的设计并不是一项容易的事，为了达到相对最优的翻译方案，需要付出的努力还是比较大的。