參與編譯工作

① 編譯程序的工作過程一般可以劃分為哪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 那樣的語言，允許名字的說明出現在名字的使用之後，那麼在看到名字之前是不便為包含該名 字的表達式生成代碼的，這種語言的編譯程序至少分成兩遍才容易生成代碼。另外機器的情況，即編譯程 序工作的環境也影響編譯程序的遍數的劃分。遍數多一點，整個編譯程序的邏輯結構可能清晰些，但遍數 多即意味著增加讀寫中間文件的次數，勢必消耗較多時間，一般會比一遍的編譯要慢。