① 编译程序的工作过程一般可以划分为哪5个基本阶段,还自始至终伴随进行哪两项工作
1、编译程序把一个源程序翻译成目标程序的工作过程分为五个阶段:词法分析;语法分析;中间代码生成;代码优化;目标代码生成。
2、编译程序的工作过程一般自始至终伴随进行信息表管理和出错处理两项工作。
主要是进行词法分析和语法分析,又称为源程序分析,分析过程中发现有语法错误,给出提示信息。
(1)参与编译工作扩展阅读:
解释程序是一种语言处理程序,在词法、语法和语义分析方面与编译程序的工作原理基本相同,但在运行用户程序时,它直接执行源程序或源程序的内部形式(中间代码)。因此,解释程序并不产生目标程序,这是它和编译程序的主要区别。解释程序的工作过程如下:
1、由总控程序完成初始化工作。
2、依次从源程序中取出一条语句进行语法检查,如有错,输出错误信息;如果通过了语法检查,则根据语句翻泽成相应的指令并执行它。
3、检查源程序是否已经全部解释执行完毕,如果未完成则继续解释并执行下一条语句,直到全部语句都处理完毕。
② 请问达到怎样的水平才能进微软这类公司从事搞编译器这类工作
我读研究生的时候才对编译开始有兴趣,当我毕业时我不知道我对什么感兴趣。结果,当时的成绩很好,他们也跟上了形势,然后给了我一些时间思考。
后来我也在想,我其实更大的兴趣是什么呢?其实是C++和挑战,做编译器也许是方便我更好的研究它,也有很大的挑战性,也许有一天我会因为发现更大的挑战而不做编译器了。
有什么书和方法,有很好的答案,我不会说。写下这些内容有点荒唐。
③ 柴方国的个人经历
柴方国,男,汉族,1963年7月出生,1985年1月加入中国共产党,硕士学历,中共中央编译局副局长 ,译审,中国共产党第十八次全国代表大会代表。2010年被评为全国先进工作者。 主要从事马克思主义经典着作文本研究和《马克思恩格斯全集》中文第二版、《马克思恩格斯文集》编译工作。
先后负责或参与完成《马克思恩格斯全集》中文第2版多个卷次的编译工作。柴方国同志负责编译了第5卷《德意志意识形态》专卷,依据德文、英文多个版本基本完成全卷译文修订;参与译校和审定了第14、15、48、49卷等多个卷次,审定了哲学、经济学部分文章和书信,修订了多个卷次的前言。其中有的卷次已出版,其他卷次已完成付排准备工作。
积极参加《马克思恩格斯文集》十卷本的编辑和译文审核修订工作。编译《马恩文集》十卷本,是中央马克思主义理论研究和建设工程的重点项目。柴方国同志作为课题组主要成员、编委会成员,和课题组全体同志一道,按照中央的要求,以高度负责的精神和严格科学的态度参与了文集各卷的篇目选编、题注编写、重要译例审定和各卷说明的撰写。另外,柴方国同志还负责编译和审定了第10卷(书信专卷)全卷的正文和资料,参与审核和修订了其他卷次中《1844年经济学哲学手稿》、《家庭、私有制和国家的起源》、《自然辩证法》等重要哲学着作的译文。《马恩文集》已在去年12月出版,得到中央领导和中央理论工程咨询委员会专家的充分肯定和高度评价。
尽力培养马克思主义经典着作编译人才。《马恩全集》中文第2版的编译任务十分繁重,而编译人员严重短缺。作为中央编译局马列着作编译部领导班子成员,柴方国同志多年来一直把加强编译队伍建设作为工作重点和首要任务,在抓好思想政治工作、提高管理水平的同时,努力为加快培养年轻业务骨干出主意想办法,积极推动人才培养机制的改革和完善,并通过校改译稿、相互切磋、共同研讨等方式,引导年轻同志在实践中尽快熟悉并胜任编译工作。多年来,柴方国同志校改年轻同志译稿近百万字,对于推动人才培养和队伍建设产生了十分积极的影响。
编译马克思主义经典着作是一项严肃的科学工作。在编译过程中,柴方国同志努力贯彻科学精神,采取科学态度,认真钻研马克思主义基本理论,努力掌握多种学科的知识;选择最权威可靠的外文版本作为依据,充分吸收国内外最新研究成果,对原着字斟句酌,从语言、理论和历史事实等方面进行深入的考证研究,力求吃透原文内涵并用中文确切地表达出来,尽力使译文达到忠实准确而又明白通畅的要求。《德意志意识形态》卷是唯物史观的奠基之作,内容丰富,文字艰深,原文残缺散失之处很多,译校和编辑难度很大,是《马恩全集》中文版编译工作的重点和难点。为了做好译校工作,柴方国同志不仅反复研读《德意志意识形态》的八九个中外文版本和马克思恩格斯的其他早期着作,而且仔细研究马克思恩格斯论战对手的着作和观点,以求彻底弄清原着的背景、语境、逻辑结构和理论要义。针对该卷的编辑问题,柴方国同志系统研究了《德意志意识形态》的写作史和版本史,在认真比较各种版本优劣的基础上,提出中文新版编排方案。新版编排方案得到国际《马恩全集》历史考证版编委会专家的赞同,《〈德意志意识形态〉写作过程和两种编排方式比较》被评为中央编译局优秀课题结项报告。
经典着作编译要求细致严格,考验每一位编译者的耐心和毅力。为提高编译质量,确保译本充分反映经典作家的原意,柴方国同志在文献考证、资料编纂和校样审读等方面下了很大功夫,仔细核查,反复推敲,认真对待每一个细节。马克思恩格斯生活的时代已经过去一百多年,加上语言文化上的隔阂,他们的着作所涉及的许多内容现在查考起来相当困难,琐细繁复,费心耗时。在编译和研究工作中,柴方国同志为了确认某篇文献或某个确切时间,往往像大海捞针一样查阅多种外文辞书,核对大量相关资料。遇到原文版本有疏漏的地方,柴方国同志便利用多种外文版本加以参证,或通过网络与外国同行进行讨论,尽量把工作做得扎实可靠。《马恩文集》编译工作启动以后,为落实中央领导关于“确保译本的准确性和权威性”的指示,柴方国同志长期加班加点,节假日也难得休息,工作最紧张的时候,一连几个月没有休过周末。2009年夏天,《马恩文集》工作进入关键阶段,母亲生病住院时也没有顾得上回去看望,嘱咐弟弟妹妹照顾好母亲,自己留下来坚持工作。几年来,柴方国同志先后校改《马恩文集》有关卷次的译稿多达十几遍,大到重要理论表述问题,小到字词和标点符号的使用,都作了认真负责的修订,尽最大努力使《马恩文集》成为经典着作编译的精品。
④ c/c 语言编译程序的首要工作是
答案是A
C/C++程序编译过程包括下面4个阶段:
1.预处理,
2.编译,
3.汇编,
4.链接。
下面我们就来详细分析下这几个阶段。
1.预处理
预处理相当于根据预处理指令组装新的C/C++程序。经过预处理,
会产生一个没有宏定义,没有条件编译指令,没有特殊符号的输出文件,
这个文件的含义同原本的文件无异,只是内容上有所不同。
读取C/C++源程序,对其中的伪指令(以#开头的指令)进行处理
①将所有的“#define”删除,并且展开所有的宏定义
②处理所有的条件编译指令,如:“#if”、“#ifdef”、“#elif”、“#else”、“endif”等。
这些伪指令的引入使得程序员可以通过定义不同的宏来决定编译程序对哪些代码进行处理。
预编译程序将根据有关的文件,将那些不必要的代码过滤掉。
③处理“#include”预编译指令,将被包含的文件插入到该预编译指令的位置。
(注意:这个过程可能是递归进行的,也就是说被包含的文件可能还包含其他文件)
删除所有的注释
添加行号和文件名标识。
以便于编译时编译器产生调试用的行号信息及用于编译时产生的编译错误或警告时能够显示行号
保留所有的#pragma编译器指令
2.编译
将预处理完的文件进行一系列词法分析、语法分析、语义分析及优化后,产生相应的汇编代码文件。
3.汇编
将编译完的汇编代码文件翻译成机器指令,并生成可重定位目标程序的.o文件,该文件为二进制文件,字节编码是机器指令。
汇编器是将汇编代码转变成机器可以执行的指令,每一个汇编语句几乎都对应一条机器指令。
所以汇编器的汇编过程相对于编译器来讲比较简单,它没有复杂的语法,也没有语义,也不需要做指令优化,
只是根据汇编指令和机器指令的对照表一一翻译即可。
4.链接
通过链接器将一个个目标文件(或许还会有库文件)链接在一起生成一个完整的可执行程序。
由汇编程序生成的目标文件并不能立即就被执行,其中可能还有许多没有解决的问题。
例如,某个源文件中的函数可能引用了另一个源文件中定义的某个符号(如变量或者函数调用等);
在程序中可能调用了某个库文件中的函数,等等。所有的这些问题,都需要经链接程序的处理方能得以解决。
链接程序的主要工作就是将有关的目标文件彼此相连接,也就是将在一个文件中引用的符号同该符号在另外
一个文件中的定义连接起来,使得所有的这些目标文件成为一个能够被操作系统装入执行的统一整体。
至此,大致经过这几个步骤,一个完整的可执行程序产生了。
⑤ android系统编译能用分布式编译吗
项目越来越大,每次需要重新编译整个项目都是一件很浪费时间的事情。Research了一下,找到以下可以帮助提高速度的方法,总结一下。
1. 使用tmpfs来代替部分IO读写
2.ccache,可以将ccache的缓存文件设置在tmpfs上,但是这样的话,每次开机后,ccache的缓存文件会丢失
3.distcc,多机器编译
4.将屏幕输出打印到内存文件或者/dev/null中,避免终端设备(慢速设备)拖慢速度。
tmpfs
有人说在Windows下用了RAMDisk把一个项目编译时间从4.5小时减少到了5分钟,也许这个数字是有点夸张了,不过粗想想,把文件放到内存上做编译应该是比在磁盘上快多了吧,尤其如果编译器需要生成很多临时文件的话。
这个做法的实现成本最低,在Linux中,直接mount一个tmpfs就可以了。而且对所编译的工程没有任何要求,也不用改动编译环境。
mount -t tmpfs tmpfs ~/build -o size=1G
用2.6.32.2的Linux Kernel来测试一下编译速度:
用物理磁盘:40分16秒
用tmpfs:39分56秒
呃……没什么变化。看来编译慢很大程度上瓶颈并不在IO上面。但对于一个实际项目来说,编译过程中可能还会有打包等IO密集的操作,所以只要可能,用tmpfs是有益无害的。当然对于大项目来说,你需要有足够的内存才能负担得起这个tmpfs的开销。
make -j
既然IO不是瓶颈,那CPU就应该是一个影响编译速度的重要因素了。
用make -j带一个参数,可以把项目在进行并行编译,比如在一台双核的机器上,完全可以用make -j4,让make最多允许4个编译命令同时执行,这样可以更有效的利用CPU资源。
还是用Kernel来测试:
用make: 40分16秒
用make -j4:23分16秒
用make -j8:22分59秒
由此看来,在多核CPU上,适当的进行并行编译还是可以明显提高编译速度的。但并行的任务不宜太多,一般是以CPU的核心数目的两倍为宜。
不过这个方案不是完全没有cost的,如果项目的Makefile不规范,没有正确的设置好依赖关系,并行编译的结果就是编译不能正常进行。如果依赖关系设置过于保守,则可能本身编译的可并行度就下降了,也不能取得最佳的效果。
ccache
ccache工作原理:
ccache也是一个编译器驱动器。第一趟编译时ccache缓存了GCC的“-E”输出、编译选项以及.o文件到$HOME/.ccache。第二次编译时尽量利用缓存,必要时更新缓存。所以即使"make clean; make"也能从中获得好处。ccache是经过仔细编写的,确保了与直接使用GCC获得完全相同的输出。
ccache用于把编译的中间结果进行缓存,以便在再次编译的时候可以节省时间。这对于玩Kernel来说实在是再好不过了,因为经常需要修改一些Kernel的代码,然后再重新编译,而这两次编译大部分东西可能都没有发生变化。对于平时开发项目来说,也是一样。为什么不是直接用make所支持的增量编译呢?还是因为现实中,因为Makefile的不规范,很可能这种“聪明”的方案根本不能正常工作,只有每次make clean再make才行。
安装完ccache后,可以在/usr/local/bin下建立gcc,g++,c++,cc的symbolic link,链到/usr/bin/ccache上。总之确认系统在调用gcc等命令时会调用到ccache就可以了(通常情况下/usr/local /bin会在PATH中排在/usr/bin前面)。
安装的另外一种方法:
vi ~/.bash_profile
把/usr/lib/ccache/bin路径加到PATH下
PATH=/usr/lib/ccache/bin:$PATH:$HOME/bin
这样每次启动g++的时候都会启动/usr/lib/ccache/bin/g++,而不会启动/usr/bin/g++
效果跟使用命令行ccache g++效果一样
这样每次用户登录时,使用g++编译器时会自动启动ccache
继续测试:
用ccache的第一次编译(make -j4):23分38秒
用ccache的第二次编译(make -j4):8分48秒
用ccache的第三次编译(修改若干配置,make -j4):23分48秒
看来修改配置(我改了CPU类型...)对ccache的影响是很大的,因为基本头文件发生变化后,就导致所有缓存数据都无效了,必须重头来做。但如果只是修改一些.c文件的代码,ccache的效果还是相当明显的。而且使用ccache对项目没有特别的依赖,布署成本很低,这在日常工作中很实用。
可以用ccache -s来查看cache的使用和命中情况:
cache directory /home/lifanxi/.ccachecache hit 7165cache miss 14283called for link 71not a C/C++ file 120no input file 3045files in cache 28566cache size 81.7 Mbytesmax cache size 976.6 Mbytes
可以看到,显然只有第二编次译时cache命中了,cache miss是第一次和第三次编译带来的。两次cache占用了81.7M的磁盘,还是完全可以接受的。
distcc
一台机器的能力有限,可以联合多台电脑一起来编译。这在公司的日常开发中也是可行的,因为可能每个开发人员都有自己的开发编译环境,它们的编译器版本一般是一致的,公司的网络也通常具有较好的性能。这时就是distcc大显身手的时候了。
使用distcc,并不像想象中那样要求每台电脑都具有完全一致的环境,它只要求源代码可以用make -j并行编译,并且参与分布式编译的电脑系统中具有相同的编译器。因为它的原理只是把预处理好的源文件分发到多台计算机上,预处理、编译后的目标文件的链接和其它除编译以外的工作仍然是在发起编译的主控电脑上完成,所以只要求发起编译的那台机器具备一套完整的编译环境就可以了。
distcc安装后,可以启动一下它的服务:
/usr/bin/distccd --daemon --allow 10.64.0.0/16
默认的3632端口允许来自同一个网络的distcc连接。
然后设置一下DISTCC_HOSTS环境变量,设置可以参与编译的机器列表。通常localhost也参与编译,但如果可以参与编译的机器很多,则可以把localhost从这个列表中去掉,这样本机就完全只是进行预处理、分发和链接了,编译都在别的机器上完成。因为机器很多时,localhost的处理负担很重,所以它就不再“兼职”编译了。
export DISTCC_HOSTS="localhost 10.64.25.1 10.64.25.2 10.64.25.3"
然后与ccache类似把g++,gcc等常用的命令链接到/usr/bin/distcc上就可以了。
在make的时候,也必须用-j参数,一般是参数可以用所有参用编译的计算机CPU内核总数的两倍做为并行的任务数。
同样测试一下:
一台双核计算机,make -j4:23分16秒
两台双核计算机,make -j4:16分40秒
两台双核计算机,make -j8:15分49秒
跟最开始用一台双核时的23分钟相比,还是快了不少的。如果有更多的计算机加入,也可以得到更好的效果。
在编译过程中可以用distccmon-text来查看编译任务的分配情况。distcc也可以与ccache同时使用,通过设置一个环境变量就可以做到,非常方便。
总结一下:
tmpfs: 解决IO瓶颈,充分利用本机内存资源
make -j: 充分利用本机计算资源
distcc: 利用多台计算机资源
ccache: 减少重复编译相同代码的时间
这些工具的好处都在于布署的成本相对较低,综合利用这些工具,就可以轻轻松松的节省相当可观的时间。上面介绍的都是这些工具最基本的用法,更多的用法可以参考它们各自的man page。
5.还有提速方法是把屏幕输出重定向到内存文件或/dev/null,因对终端设备(慢速设备)的阻塞写操作也会拖慢速度。推荐内存文件,这样发生错误时,能够查看。
⑥ c++:有的书说.h文件不参与编译,有的书又说参与编译,到底怎么回事呀
.h文件不能单独进行编译,它只能包含在.c/.cpp文件中,或者与其组建一个工程,然后编译.c/.cpp文件。用包含的形式编译的时候,是把.h文件作为.c/.cpp文件的一部分来进行编译。
⑦ 从预处理、编译、汇编到链接,编译系统都作了哪些工作使用哪些工具生成了哪些文件
这个问题可烦可简,可深可浅。
对于编译执行语言而言:
我所知的笼统过程有
(1)源代码==》目标代码==》可执行程序
(资源==》目标代码)
(2)源代码==》中间代码==》目标代码==》可执行程序
第(1)种一般的为低级汇编采用的模式,第一个主要步骤统称为Assembly(汇编),由“汇编程序”(或称汇编编译器)完成,其包含预处理操作,生成的主要文件是目标文件,当然在生成目的文件前还有许多辅助文件,一般会被“汇编程序”临时生成,用完即删除,不指定控制选项的话最终用户是看不到这些文件的,有哪些中间临时文件,用处是什么可以查看“汇编编译器”的帮助选项得到。第二个主要步骤就是link(链接),其将目标代码文件,链接库里的目标代码块整合为可执行代码,中间也临时生成一些中间文件,如映射文件等,同样可通过链接器的选项查看。
当然,在一些高级汇编里还会有资源编译器,其将各种资源转为(编译为)目标文件(作为链接器的输入)
第(2)种一般是高级语言采用的模式,但有些比较高级的直接跳过中间代码由源代码生成目标代码,其就跟(1)类似,只是此时第一个主要步骤不叫“汇编”而称compile(编译),低级汇编的步骤一“汇编”也可称”编译“。如果有中间代码生成,这中间代码就是汇编代码,此后续处理就同(1)了,此时的中间代码其实也就是临时文件中的一种。
概述:源代码到目标代码的过程通常称为编译,而目标代码到可执行程序的过程称问链接。
或将两个过程统称为代码的编译(全称应为编译连接),这涉及具体的语境,事实上编译器如VC的cl.exe若没有指定/c(只生产目标代码选项),其就是编译连接的统一过程(cl会调用相应的链接器),若指定,则只有编译过程(只生成目标代码而不链接称可执行程序)
上述编译执行类语言开发平台所开发生成的程序一般称为”非托管类程序“
而对于托管类程序(如.NET平台语言C#,VB.NET,JVM平台的java等)
其虽然也有编译过程,但其直接将源代码转为中间代码而不是目标代码(此时不是汇编代码更不是机器码,而是可被.NET或JVM引擎解释执行的代码)
可参看编译原理等相关教材,阿门。。。
⑧ 编译过程分为哪几个阶段各阶段的遵循的原则、识别机构、使用的文法编译原理
编译原理中的遍概念
编译阶段也常常划分为两大步骤,分析步骤和综合步骤 分析步骤和综合步骤 分析步骤是指对源程序的分析 -线性分析(词法分析或扫描) -层次分析(语法分析) -语义分析 综合步骤是指后端的工作,为目标程序的生成而进行的综合
你分析过吗?若按照这种组合方式实现编译程序,可以设想,某一编译程序的前端加上相应不同的后 端则可以为不同的机器构成同一个源语言的编译程序。也可以设想,不同语言编译的前端生成同一种中间 语言,再使用一个共同的后端,则可为同一机器生成几个语言的编译程序。
一个编译过程可由一遍、两遍或多遍完成。所谓"遍",也称作"趟",是对源程序或其等价的中间语言程 序从头到尾扫视并完成规定任务的过程。每一遍扫视可完成上述一个阶段或多个阶段的工作。例如一遍可 以只完成词法分析工作;一遍完成词法分析和语法分析工作;甚至一遍完成整个编译工作。对于多遍的编 译程序,第一遍的输入是用户书写的源程序,最后一遍的输出是目标语言程序,其余是上一遍的输出为下 一遍的输入。
在实际的编译系统的设计中,编译的几个阶段的工作究竟应该怎样组合,即编译程序究竟分成几遍, 参考的因素主要是源语言和机器(目标机)的特征。比如源语言的结构直接影响编译的遍的划分;像 PL/1 或 ALGOL 68 那样的语言,允许名字的说明出现在名字的使用之后,那么在看到名字之前是不便为包含该名 字的表达式生成代码的,这种语言的编译程序至少分成两遍才容易生成代码。另外机器的情况,即编译程 序工作的环境也影响编译程序的遍数的划分。遍数多一点,整个编译程序的逻辑结构可能清晰些,但遍数 多即意味着增加读写中间文件的次数,势必消耗较多时间,一般会比一遍的编译要慢。