编译器编译工作执行顺序

1. 编译为什么要分阶段

编译过程分为分析和综合两个部分，并进一步划分为词法分析、语法分析、 语义分析、 代码优化、存储分配和代码生成等六个相继的逻辑步骤。

这六个步骤只表示编译程序各部分之间的逻辑联系，而不是时间关系。编译过程既可以按照这六个逻辑步骤顺序地执行，也可以按照平行互锁方式去执行。在确定编译程序的具体结构时，常常分若干遍实现。对于源程序或中间语言程序，从头到尾扫视一次并实现所规定的工作称作一遍。

编译程序

也称为编译器，是指把用高级程序设计语言书写的源程序，翻译成等价的机器语言格式目标程序的翻译程序。编译程序属于采用生成性实现途径实现的翻译程序。它以高级程序设计语言书写的源程序作为输入，而以汇编语言或机器语言表示的目标程序作为输出。编译出的目标程序通常还要经历运行阶段，以便在运行程序的支持下运行，加工初始数据，算出所需的计算结果。

2. C语言程序的运行顺序

1、这个涉及到函数的调用约定
运行结果跟编译器有一定的关系，不同的编译器参数的入栈的顺序不同
一般的编译器是从右到左
如fun(a,b)这个函数调用，是先计算参数b，入栈，再计算参数a，入栈
2、printf("%d
%d",
a++,++a);
//先计算++a，先自增，a的值变为2，将2入栈
再来计算a++，将a的值2入栈，再使a自增，a的值变为3
printf("
%d\n",a);
//a的值已经变为3了
3、printf(%d
%d",
++a.a++);//先计算a++，将a的值1入栈，再使a自增，a的值变为2，再来计算++a，先自增，a的值为3，将3入栈，输出3
1
printf("
%d\n",a);
//输出3
4、三种调用约定：
__stdcall调用约定。两者实质上是一致的，即函数的参数自右向左通过栈传递，被调用的函数在返回前清理传送参数的内存栈，但不同的是函数名的修饰部分（关于函数名的修饰部分在后面将详细说明）。
C调用约定（即用__cdecl关键字说明）和__stdcall调用约定有所不同，虽然参数传送方面是一样的，但对于传送参数的内存栈却是由调用者来维护的（也正因为如此，实现可变参数的函数只能使用该调用约定），另外，在函数名修饰约定方面也有所不同。
__fastcall调用约定是“人”如其名，它的主要特点就是快，因为它是通过寄存器来传送参数的（实际上，它用CX和EDX传送前两个双字或更小的参数，剩下的参数仍旧自右向左压栈传送，被调用的函数在返回前清理传送参数的内存栈），在函数名修饰约定方面，它和前两者均不同。

3. 编译程序的工作过程一般可以划分为哪5个基本阶段，还自始至终伴随进行哪两项工作

1、编译程序把一个源程序翻译成目标程序的工作过程分为五个阶段：词法分析；语法分析；中间代码生成；代码优化；目标代码生成。

2、编译程序的工作过程一般自始至终伴随进行信息表管理和出错处理两项工作。

主要是进行词法分析和语法分析，又称为源程序分析，分析过程中发现有语法错误，给出提示信息。

(3)编译器编译工作执行顺序扩展阅读：

解释程序是一种语言处理程序，在词法、语法和语义分析方面与编译程序的工作原理基本相同，但在运行用户程序时，它直接执行源程序或源程序的内部形式(中间代码)。因此，解释程序并不产生目标程序，这是它和编译程序的主要区别。解释程序的工作过程如下：

1、由总控程序完成初始化工作。

2、依次从源程序中取出一条语句进行语法检查，如有错，输出错误信息；如果通过了语法检查，则根据语句翻泽成相应的指令并执行它。

3、检查源程序是否已经全部解释执行完毕，如果未完成则继续解释并执行下一条语句，直到全部语句都处理完毕。

4. C语言程序的执行过程是什么

顺序执行，从main函数开始，顺序执行。
遇到调用的其它函数就先运行函数，然后继续执行主函数下面的语句。
当整个程序编写好后，编译器先编译，再连接各种库函数，然后执行程序。

5. 【C语言】优先级，结合方向和执行顺序

K&R的书中一再强调"C is not a big language",当时看书的时候无法理解这句话的意思。现在我的理解是C标准本身的限制比较小，留给程序员的空间较大。这样一来C中的而有些问题标准就没有给出限定，就会产生一些让人迷惑的地方。今天我遇到了一个这样的问题，解决这些问题有的时候看起来是“钻牛角尖”，好吧，我就是一个爱钻牛角尖的人。这里需要解决的问题是执行顺序的问题，先给出几个问题。

执行完这两个语句后i和j的值各是什么？（看着是不是很熟悉，上次笔试考C中是不是有这个呢）

执行完上述语句后，i和数组arry中的值是多少？

输出结果是什么？（来自于C Puzzle Book Operators 1.6 ）
先把这几个问题放在这里，先思考下，下面将会解决他们。

C语言经典着作 “The C Programming Language” 中对于side effects的定义：

这里述说的side effect可以理解为一种“副作用”，这种作用是改变一个变量的值。
“C In Nutshell” 中关于side effects的定义：

相对于K&R中的定义这里使用了对于环境的改变，这应该更加准确。总结：side effects 就是程序中的实体产生的改变，这里所说的实体通常指变量。
赋值，自增，自减表达式会产生side effects,函数调用表达式也有可能产生side effects。

序列点（sequence points）是一种逻辑意义的点，它的意义在于，逻辑点前的副作用（side effects）都在这时生效。C标准中定义的序列点总共有三类，第一类是完全表达式（full expression）；第二类是||,&&,?:和；第三类是函数调用，在所有的参数确定后、函数真正调用之前。

标准中规定了在前一个序列点前的副作用都会在前一个序列点后完成，但是标准没有规定两个序列点之间的副作用生效的顺序，不同的C语言实现的顺序可能不同。请注意这一点，这是所有问题产生的根本原因。如果两个序列点之间有超过两个的副作用作用在同一个实体上，这样不同的编译器产生的结果就不同，这种情况在标准中称为unspecified 。所以在实际应用中应该避免这种情况的出现，我把这一个原则称为为SS1。

是不是遵守了SS1原则就不会产生unspecified了呢？非也。可以设想这样一种情况：每一个实体（A）在两个序列点之间被两次使用，只有一次对这个实体本身产生副作用，另外一次被间接的用来产生副作用作用于另外一个实体（B）。在前面设想的这种情况下虽然符合SS1原则，但是我们会发现被间接用来产生副作用时，对于实体（B）产生的副作用肯定会跟实体(A)有关，但是这个实体(A)在这个序列点区间中有被副作用作用，那么我们就无法确定这个实体（A）的值了，从而实体（B）也就无法确定了。这里可以归纳为：在两个序列点之间，如果出现对一个实体的多次引用，并且只有一次会对该实体产生副作用（SS1），那么所有的这些引用都必须用来产生这个副作用 ，我把这一个原则称为SS2。只有同时遵守了SS1和SS2，写出的表达式才不是unspecified类型的。

可以清晰的看到标准中使用了两句话来概括这种问题，这正好对应于SS1，SS2原则。

下面给出更为具体的方法：
1）在一个表达式中最多只改变一个实体。
2）如果一个实体在一个表达式被改变，并且出现次数大于一次，请保证所有实体的出现都是为了产生这个“改变”。
例如： i = i+1;
3）如果不能遵守1），那么请保证改变的是不同的实体。
例如：c = *p++;
4）如果1)和2）都不能遵守，那么请使用序列点将表达式分开。
例如 : (c = getchar()) != EOF && c != ‘\n’;

C语言中组成程序的基本单位是表达式（expression），表达式是指用操作符（operator）和操作数（operand）连接起来的式子。C标准给出了最基本的操作符，通过这些操作符可以组成简单表达式，同样也可以通过复合产生复杂表达式。当一个表达式中出现多个操作符，多个操作数的时候，操作符合操作数是如何组合起来的呢？优先级和结合方向就是用来解决这个问题的，可以这么说，优先级和结合方向给出了一个表达式的含义，这只是说明了各个操作符和操作数是怎么聚合起来的。

仅仅依靠优先级和结合方向是无法确定一个复合表达式中对各个子表达式的求值顺序。标准中对于这点的规定是：
两个相邻的操作符的执行顺序由它们的优先级决定。如果它们优先级相同，它们的执行顺序由它们的结合性决定。除此之外，编译器可以自由决定任何顺序对表达式进行求值，只要它不违反逗号，&&，||和？：操作符所施加的限制。

1）j = i++ + i++ + i++;
这个表达式违反了SS1，不同的编译器产生的结果可能不同。
2）arry[i] = i++;
这个表达式违反了SS2，不同的编译器产生的结果可能不同。
3）x = y = z = 1;
++x || ++y && ++z; PRINT(x, y, z);
&&的优先级比|| 的优先级高，所以：
++x || ++y && ++z 等效于++x || (++y && ++z)
这里就很容易犯错，会认为先执行++y && ++z 在执行++x || ( … ),这种观点是错误的，c中只对 逗号，、逻辑与 &&、
逻辑或 || 和 条件表达式规定了执行顺序，对于逻辑表达式方向是从左向右执行的。本例子中，先执行 ++x = 2，逻辑
或表达式被短路，++y && ++z没有执行，最后x = 2， y = 1， z = 1;

通过本课题的学习加深了对于c的理解，理解SS1，SS2原则。在实际应用中应该遵守“一条语句只做一件事的原则”。

6. C语言文件的编译与执行的四个阶段并分别描述

开发C程序有四个步骤：编辑、编译、连接和运行。

任何一个体系结构处理器上都可以使用C语言程序，只要该体系结构处理器有相应的C语言编译器和库，那么C源代码就可以编译并连接到目标二进制文件上运行。

1、预处理：导入源程序并保存（C文件）。

2、编译：将源程序转换为目标文件（Obj文件）。

3、链接：将目标文件生成为可执行文件（EXE文件）。

4、运行：执行，获取运行结果的EXE文件。

(6)编译器编译工作执行顺序扩展阅读：

将C语言代码分为程序的几个阶段：

1、首先，源代码文件测试。以及相关的头文件，比如stdio。H、由预处理器CPP预处理为．I文件。预编译的。文件不包含任何宏定义，因为所有宏都已展开，并且包含的文件已插入。我归档。

2、编译过程是对预处理文件进行词法分析、语法分析、语义分析和优化，生成相应的汇编代码文件。这个过程往往是整个程序的核心部分，也是最复杂的部分之一。

3、汇编程序不直接输出可执行文件，而是输出目标文件。汇编程序可以调用LD来生成可以运行的可执行程序。也就是说，您需要链接大量的文件才能获得“a.out”，即最终的可执行文件。

4、在链接过程中，需要重新调整其他目标文件中定义的函数调用指令，而其他目标文件中定义的变量也存在同样的问题。

7. c++编译器以何种顺序编译文件的，先cpp文件，还是.h文件

1. 编译阶段 (头文件 .h)
d工程中在头文件中对导出内容(function, class, type, object, variable)进行定义.

2. 链接阶段 (库文件 .lib)
d工程在link阶段会生成.lib
用户link时需要 这个.lib 解决link时的代码定位.
3. 运行阶段
.exe

8. 编译器生成的汇编语句执行顺序为什么与C代码顺序不同

不影响语义的前提下编译器可以任意重排代码顺序；
在乱序执行（Out-of-Order）的CPU里，机器码的执行也可以不按照你在“汇编”层面上看到的顺序执行，只要不影响语义。
所以说这些中间步骤的顺序，作为底层细节平时不需要那么在意——它们多半跟原始源码的顺序是不一样的。

现代优化编译器优化的思路之一是“基于依赖的优化”（dependence-based optimization）。题主引用的CSAPP的例子：

int arith(int x, int y, int z) {
int t1 = x + y;
int t2 = z * 48;
int t3 = t1 & 0xFFFF;
int t4 = t2 * t3;
return t4;
}

所有涉及运算的值都是局部标量变量（local scalar variable），这是最便于编译器做分析的情况，所有依赖都可以显式分析。
由于整个函数没有分支，这里也不需要讨论控制依赖（control dependence），只要讨论数据依赖（data dependence）就好。
把数据依赖图画出来是个DAG（这里正好是棵树，特例了）：

x y z 48
\ / \ /
t1 0xFFFF t2
\ / /
t3 /
\ /
t4

优化必须要满足的约束是：每个节点求值之前，其子节点（依赖的数据源）必须要先求了值。
显然，t1和t2之间没有依赖关系，它们的相对求值顺序怎样重排都没关系。

有本我很喜欢的书，里面讲的是各种基于依赖的优化：Optimizing Compilers for Modern Architectures - A Dependence-based Approach

以上是理论部分。

================================================================

下面来看例子。

我们可以用一个实际编译器来看看CSAPP的例子编译出来的结果：

.text
# -- Begin arith
.p2align 4,,15
.globl arith
.type arith, @function
arith:
.p2align 4,,7
/*.L0:*/ /* Block BB[54:2] preds: none, freq: 1.000 */
movl 8(%esp), %edx /* ia32_Load T[139:10] -:1:22 */
addl 4(%esp), %edx /* ia32_Add Iu[141:12] -:2:14 */
movzwl %dx, %edx /* ia32_Conv_I2I Iu[142:13] -:4:15 */
imull 12(%esp), %edx /* ia32_IMul Iu[143:14] -:5:15 */
leal (%edx,%edx,2), %eax /* ia32_Lea Iu[144:15] -:5:15 */
shll $0x4, %eax /* ia32_Shl Iu[146:17] -:5:15 */
ret /* ia32_Return X[152:23] -:6:3 */
.size arith, .-arith
# -- End arith

这里用的是libFirm。可见它跟CSAPP书里所说的汇编的顺序又有所不同。这也是完全合理的。
这个编译结果的顺序是：

edx = y;
edx += x;
edx = zeroextend dx; // edx = edx & 0xFFFF
edx *= z;
eax = edx * 3;
eax <<= 4; // eax = eax * 16

也是完全符合依赖关系的约束的一种顺序。
之所以用libFirm举例是因为它的中间表示（Intermediate Representation）是一种程序依赖图（Program Dependence Graph），可以很方便的看出控制与数据依赖。把CSAPP那里例子对应的libFirm IR画出来，是这个样子的：
（这张图跟我前面画的数据依赖图正好是左右翻转的，不过意思一样。（这张图跟我前面画的数据依赖图正好是左右翻转的，不过意思一样。
Arg 0、1、2分别代表x、y、z。白色方块是普通数据节点，黄色方块是常量节点，蓝色方块是内存相关节点，红色方块是控制流节点，粉红色方块是特殊的开始/结束节点。）

某版LLVM生成的代码：

; MoleID = '/tmp/webcompile/_16355_0.bc'
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-ellcc-linux"

; Function Attrs: nounwind readnone
define i32 @arith(i32 %x, i32 %y, i32 %z) #0 {
entry:
%add = add nsw i32 %y, %x
%mul = mul nsw i32 %z, 48
%and = and i32 %add, 65535
%mul1 = mul nsw i32 %mul, %and
ret i32 %mul1
}

attributes #0 = { nounwind readnone "less-precise-fpmad"="false" "no-frame-pointer-elim"="false" "no-infs-fp-math"="false" "no-nans-fp-math"="false" "stack-protector-buffer-size"="8" "unsafe-fp-math"="false" "use-soft-float"="false" }

!llvm.ident = !{!0}

!0 = !{!"ecc 0.1.10 based on clang version 3.7.0 (trunk) (based on LLVM 3.7.0svn)"}

最终生成的x86汇编：

.text
.file "/tmp/webcompile/_15964_0.c"
.globl arith
.align 16, 0x90
.type arith,@function
arith: # @arith
# BB#0: # %entry
movl 8(%esp), %eax
addl 4(%esp), %eax
movzwl %ax, %eax
imull 12(%esp), %eax
shll $4, %eax
leal (%eax,%eax,2), %eax
retl
.Ltmp0:
.size arith, .Ltmp0-arith

.ident "ecc 0.1.10 based on clang version 3.7.0 (trunk) (based on LLVM 3.7.0svn)"
.section ".note.GNU-stack","",@progbits

GCC 4.9.2 x86-64：

arith(int, int, int):
leal (%rdx,%rdx,2), %eax
addl %edi, %esi
movzwl %si, %esi
sall $4, %eax
imull %esi, %eax
ret

Zing VM Server Compiler x86-64：

# edi: x
# esi: y
# edx: z
movl %edx, %eax
shll $0x4, %eax
leal (%rsi, %rdi, 1), %ecx
shll $0x5, %edx
addl %edx, $eax
movzwl %ecx, %edx
imull %edx, %eax

9. 简述java程序的编辑编译和运行过程

第一步(编译): 创建完源文件之后，程序会先被编译为.class文件。Java编译一个类时，如果这个类所依赖的类还没有被编译，编译器就会先编译这个被依赖的类，然后引用，否则直接引用，这个有点象make。

如果java编译器在指定目录下找不到该类所其依赖的类的.class文件或者.java源文件的话，编译器话报“cant find symbol”的错误。

第二步（运行）：java类运行的过程大概可分为两个过程：1、类的加载 2、类的执行。需要说明的是：JVM主要在程序第一次主动使用类的时候，才会去加载该类。也就是说，JVM并不是在一开始就把一个程序就所有的类都加载到内存中，而是到不得不用的时候才把它加载进来，而且只加载一次。

特别说明：java类中所有public和protected的实例方法都采用动态绑定机制，所有私有方法、静态方法、构造器及初始化方法<clinit>都是采用静态绑定机制。而使用动态绑定机制的时候会用到方法表，静态绑定时并不会用到。

(9)编译器编译工作执行顺序扩展阅读：

Java整个编译以及运行的过程相当繁琐，本文通过一个简单的程序来简单的说明整个流程。

Java代码编译:是由Java源码编译器来完成;

Java字节码的执行:是由JVM执行引擎来完成

Java程序从源文件创建到程序运行要经过两大步骤：

1、源文件由编译器编译成字节码（ByteCode）

2、字节码由java虚拟机解释运行。因为java程序既要编译同时也要经过JVM的解释运行，所以说Java被称为半解释语言（ "semi-interpreted" language）。

10. 编译器的工作分为哪几个阶段

编译器就是一个普通程序，没什么大不了的
什么是编译器？

编译器是一个将高级语言翻译为低级语言的程序。

首先我们一定要意识到编译器就是一个普通程序，没什么大不了的。

在没有弄明白编译器如何工作之前你可以简单的把编译器当做一个黑盒子，其作用就是输入一个文本文件输出一个二进制文件。

基本上编译器经过了以下几个阶段，等等，这句话教科书上也有，但是我相信很多同学其实并没有真正理解这几个步骤到底在说些什么，为了让你彻底理解这几个步骤，我们用一个简单的例子来讲解。

假定我们有一段程序：

while (y < z) {
int x = a + b;
y += x;
}
那么编译器是怎样把这一段程序人类认识的程序转换为CPU认识的二进制机器指令呢？

提取出每一个单词：词法分析
首先编译器要把源代码中的每个“单词”提取出来，在编译技术中“单词”被称为token。其实不只是每个单词被称为一个token，除去单词之外的比如左括号、右括号、赋值操作符等都被称为token。

从源代码中提取出token的过程就被称为词法分析，Lexical Analysis。

经过一遍词法分析，编译器得到了以下token：

T_While while
T_LeftParen （
T_Identifier y
T_Less <
T_Identifier z
T_RightParen )
T_OpenBrace {
T_Int int
T_Identifier x
T_Assign =
T_Identifier a
T_Plus +
T_Identifier b
T_Semicolon ;
T_Identifier y
T_PlusAssign +=
T_Identifier x
T_Semicolon ;
T_CloseBrace }
就这样一个磁盘中保存的字符串源代码文件就转换为了一个个的token。

这些token想表达什么意思：语法分析
有了这些token之后编译器就可以根据语言定义的语法恢复其原本的结构，怎么恢复呢？

原来，编译器在扫描出各个token后根据规则将其用树的形式表示出来，这颗树就被称为语法树。

语法树是不是合理的：语义分析
有了语法树后我们还要检查这棵树是不是合法的，比如我们不能把一个整数和一个字符串相加、比较符左右两边的数据类型要相同，等等。

这一步通过后就证明了程序合法，不会有编译错误。