呵成,基本成了程序入门和开发环境测试的默认的标准。
#include <stdio.h>
int main()
{
printf("Hello World\n");
return 0;
}
在Linux下,当我们使用GCC来编译Hello World程序时,只须使用最简单的命令(假设源代码
文件名为hello.c):
$gcc hello.c
$./a.out
Hello World
事实上,上述过程可以分解为4个步骤,分别是 预处理(Prepressing)、 编译(Compilation)、 汇
编(Assembly)和链接(Linking),如图2-1所示。
预编译过程主要处理那些源代码文件中的以“#”开始的预编译指令。比
如“#include ”、“#define”等,主要处理规则如下:
? 将所有的“#define”删除,并且展开所有的宏定义。
? 处理所有条件预编译指令,比如“#if ”、“#ifdef ”、“#elif ”、“#else ”、“#endif”。
? 处理“#include”预编译指令,将被包含的文件插入到该预编译指令的位置。注意,这个过程是
递归进行的,也就是说被包含的文件可能还包含其他文件。
? 删除所有的注释“//”和“/* */”。
? 添加行号和文件名标识,比如#2“hello.c”2,以便于编译时编译器产生调试用的行号信息及
用于编译时产生编译错误或警告时能够显示行号。
? 保留所有的#pragma编译器指令,因为编译器须要使用它们。
经过预编译后的.i文件不包含任何宏定义,因为所有的宏已经被展开,并且包含的文件也已经
被插入到.i文件中。所以当我们无法判断宏定义是否正确或头文件包含是否正确时,可以查看
预编译后的文件来确定问题。
2.1.2 编译
编译过程就是把预处理完的文件进行一系列词法分析、语法分析、语义分析及优化后生产相
应的汇编代码文件,这个过程往往是我们所说的整个程序构建的核心部分,也是最复杂的部
分之一
2.1.3 汇编
汇编器是将汇编代码转变成机器可以执行的指令,每一个汇编语句几乎都对应一条机器指
令。所以汇编器的汇编过程相对于编译器来讲比较简单,它没有复杂的语法,也没有语义,也
不需要做指令优化,只是根据汇编指令和机器指令的对照表一一翻译就可以了,“汇编”这个名
字也来源于此。
2.2.1 词法分析
首先源代码程序被输入到扫描器(Scanner),扫描器的任务很简单,它只是简单地进行词法分
析,运用一种类似于有限状态机(Finite State Machine)的算法可以很轻松地将源代码的字符
序列分割成一系列的记号(Token)。比如上面的那行程序,总共包含了28个非空字符,经过扫
描以后,产生了16个记号,
和特殊符号(如加号、等号)。在识别记号的同时,扫描器也完成了其他工作。比如将标识符存
放到符号表,将数字、字符串常量存放到文字表等,以备后面的步骤使用。
有一个叫做lex的程序可以实现词法扫描,它会按照用户之前描述好的词法规则将输入的字符
串分割成一个个记号。因为这样一个程序的存在,编译器的开发者就无须为每个编译器开发
一个独立的词法扫描器,而是根据需要改变词法规则就可以了。另外对于一些有预处理的语言,
比如C语言,它的宏替换和文件包含等工作一般不归入编译器的范围而交给一个独立的预处理
2.2.2 语法分析
接下来语法分析器(Grammar Parser)将对由扫描器产生的记号进行语法分析,从而产生语法
树(Syntax Tree)。整个分析过程采用了上下文无关语法(Context-free Grammar)的分析手
段,如果你对上下文无关语法及下推自动机很熟悉,那么应该很好理解。否则,可以参考一些
计算理论的资料,一般都会有很详细的介绍。此处不再赘述。简单地讲,由语法分析器生成的
语法树就是以表达式(Expression)为节点的树。我们知道,C语言的一个语句是一个表达式,
而复杂的语句是很多表达式的组合。上面例子中的语句就是一个由赋值表达式、加法表达式、
乘法表达式、数组表达式、括号表达式组成的复杂语句。它在经过语法分析器以后形成如图2-
3所示的语法树。
从图2-3中我们可以看到,整个语句被看作是一个赋值表达式;赋值表达式的左边是一个数组
表达式,它的右边是一个乘法表达式;数组表达式又由两个符号表达式组成,等等。符号和数
字是最小的表达式,它们不是由其他的表达式来组成的,所以它们通常作为整个语法树的叶
节点。在语法分析的同时,很多运算符号的优先级和含义也被确定下来了。比如乘法表达式的
优先级比加法高,而圆括号表达式的优先级比乘法高,等等。另外有些符号具有多重含义,比
如星号*在C语言中可以表示乘法表达式,也可以表示对指针取内容的表达式,所以语法分析
阶段必须对这些内容进行区分。如果出现了表达式不合法,比如各种括号不匹配、表达式中缺
少操作符等,编译器就会报告语法分析阶段的错误。
正如前面词法分析有lex一样,语法分析也有一个现成的工具叫做yacc(Yet Another Compiler
Compiler)。它也像lex一样,可以根据用户给定的语法规则对输入的记号序列进行解析,从而
构建出一棵语法树。对于不同的编程语言,编译器的开发者只须改变语法规则,而无须为每个
编译器编写一个语法分析器,所以它又被称为“编译器编译器(Compiler Compiler)”。
2.2.3 语义分析
接下来进行的是语义分析,由语义分析器(Semantic Analyzer)来完成。语法分析仅仅是完成
了对表达式的语法层面的分析,但是它并不了解这个语句是否真正有意义。比如C语言里面两
个指针做乘法运算是没有意义的,但是这个语句在语法上是合法的;比如同样一个指针和一个
浮点数做乘法运算是否合法等。编译器所能分析的语义是静态语义(Static Semantic),所谓静
态语义是指在编译期可以确定的语义,与之对应的动态语义(Dynamic Semantic)就是只有在
运行期才能确定的语义。
静态语义通常包括声明和类型的匹配,类型的转换。比如当一个浮点型的表达式赋值给一个
整型的表达式时,其中隐含了一个浮点型到整型转换的过程,语义分析过程中需要完成这个
步骤。比如将一个浮点型赋值给一个指针的时候,语义分析程序会发现这个类型不匹配,编译
器将会报错。动态语义一般指在运行期出现的语义相关的问题,比如将0作为除数是一个运行
期语义错误。
经过语义分析阶段以后,整个语法树的表达式都被标识了类型,如果有些类型需要做隐式转
换,语义分析程序会在语法树中插入相应的转换节点。上面描述的语法树在经过语义分析阶
段以后成为如图2-4所示的形式。
可以看到,每个表达式(包括符号和数字)都被标识了类型。我们的例子中几乎所有的表达式
都是整型的,所以无须做转换,整个分析过程很顺利。语义分析器还对符号表里的符号类型也
做了更新。
现代的编译器有着很多层次的优化,往往在源代码级别会有一个优化过程。我们这里所描述
的源码级优化器(Source Code Optimizer)在不同编译器中可能会有不同的定义或有一些其
他的差异。源代码级优化器会在源代码级别进行优化,在上例中,细心的读者可能已经发现,
(2 + 6)这个表达式可以被优化掉,因为它的值在编译期就可以被确定。类似的还有很多其他
复杂的优化过程,我们在这里就不详细描述了。经过优化的语法树如图2-5所示。
我们看到(2 + 6)这个表达式被优化成8。其实直接在语法树上作优化比较困难,所以源代码优
化器往往将整个语法树转换成中间代码(Intermediate Code),它是语法树的顺序表示,其实
它已经非常接近目标代码了。但是它一般跟目标机器和运行时环境是无关的,比如它不包含
数据的尺寸、变量地址和寄存器的名字等。中间代码有很多种类型,在不同的编译器中有着不
同的形式,比较常见的有:三地址码(Three-address Code)和P-代码(P-Code)。我们就拿最
常见的三地址码来作为例子,最基本的三地址码是这样的:
x = y op z
这个三地址码表示将变量y和z进行op操作以后,赋值给x。这里op操作可以是算数运算,比如
加减乘除等,也可以是其他任何可以应用到y和z的操作。三地址码也得名于此,因为一个三地
址码语句里面有三个变量地址。我们上面的例子中的语法树可以被翻译成三地址码后是这样
的:
t1 = 2 + 6
t2 = index + 4
t3 = t2 * t1
array[index] = t3
我们可以看到,为了使所有的操作都符合三地址码形式,这里利用了几个临时变量:t1、t2和
t3。在三地址码的基础上进行优化时,优化程序会将2+6的结果计算出来,得到t1 = 8。然后将
后面代码中的t1替换成数字8。还可以省去一个临时变量t3,因为t2可以重复利用。经过优化以
后的代码如下:
t2 = index + 4
t2 = t2 * 8
array[index] = t2
中间代码使得编译器可以被分为前端和后端。编译器前端负责产生机器无关的中间代码,编
译器后端将中间代码转换成目标机器代码。这样对于一些可以跨平台的编译器而言,它们可
以针对不同的平台使用同一个前端和针对不同机器平台的数个后端。
目标代码优化
最后目标代码优化器对上述的目标代码进行优化,比如选择合适的寻址方式、使用位移来代
替乘法运算、删除多余的指令等。上面的例子中,乘法由一条相对复杂的基址比例变址寻址
(Base Index Scale Addressing)的lea指令完成,随后由一条mov指令完成最后的赋值操作,
这条mov指令的寻址方式与lea是一样的。
链接
现代的编译和链接过程也并非想象中的那么复杂,它还是一个比较容易理解的概念。比如我
们在程序模块main.c中使用另外一个模块func.c中的函数foo()。我们在main.c模块中每一处调
用foo的时候都必须确切知道foo这个函数的地址,但是由于每个模块都是单独编译的,在编译
器编译main.c的时候它并不知道foo函数的地址,所以它暂时把这些调用foo的指令的目标地
址搁置,等待最后链接的时候由链接器去将这些指令的目标地址修正。如果没有链接器,须要
我们手工把每个调用foo的指令进行修正,则填入正确的foo函数地址。当func.c模块被重新编
译,foo函数的地址有可能改变时,那么我们在main.c中所有使用到foo的地址的指令将要全部
重新调整。这些繁琐的工作将成为程序员的噩梦。使用链接器,你可以直接引用其他模块的函
数和全局变量而无须知道它们的地址,因为链接器在链接的时候,会根据你所引用的符号
foo,自动去相应的func.c模块查找foo的地址,然后将main.c模块中所有引用到foo的指令重新
修正,让它们的目标地址为真正的foo函数的地址。这就是静态链接的最基本的过程和作用。
在链接过程中,对其他定义在目标文件中的函数调用的指令须要被重新调整,对使用其他定
义在其他目标文件的变量来说,也存在同样的问题。让我们结合具体的CPU指令来了解这个
过程。假设我们有个全局变量叫做var,它在目标文件A里面。我们在目标文件B里面要访问这
个全局变量,比如我们在目标文件B里面有这么一条指令:
movl $0x2a, var
这条指令就是给这个var变量赋值0x2a,相当于C语言里面的语句var = 42。然后我们编译目标
文件B,得到这条指令机器码,如图2-9所示。