compiler LLVM(zhuanzai)
|字號 訂閱
Mac OS X 10.6即所謂的Snow Leopard操作系統已正式發售。一如既往，Apple產品光鮮的外表下凝聚了太多艱辛的勞作。ArsTechnic的John Siracusa以其獨特的、專業的、全面的視角深入翔實地體驗這款最新的操作系統。
Weiphone.com將對該綜述進行翻譯整理並獨家連載。歡迎關注。
早在幾年以前，Apple就在LLVM開源計劃上做出了重要的戰略性投資。我曾在一篇介紹Mac OS X Leopard的文章中簡要介紹了LLVM的一些基本情況，Leopard利用LLVM技術爲JIT編譯軟件的OpenGL功能提供了高效的執行支持。在 那篇綜述的最後，我這樣結尾：
隨着Snow Leopard的推出，這一切開始逐漸浮出水面：Clang和LLVM已成爲Apple現行的編譯策略。LLVM甚至還有一個全新的帥氣的標：
![compiler LLVM(zhuanzai) - Brown - 我的博客]()
目前，Apple爲Mac OS X總共提供了四種編譯器：GCC 4.0，GCC4.2，LLVM-GCC 4.2，以及Clang。這裏是一個圖表：
![compiler LLVM(zhuanzai) - Brown - 我的博客]()
所有這些編譯器在Mac OS X上均具有二進制兼容性(binary-compatible)，這就意味着您可以使用一種編譯器創建一個資源庫並與使用另一個編譯器創建的可執行文件相 鏈接。並且，理論上講，這些都是命令行編輯器並且都具有資源兼容性。然而，Clang目前暫不支持GCC的一些複雜功能，同時Clang只支持C、 Objective-C和一點點C++(而GCC支持的相對較多)。Apple承諾，Clang未來將會爲C++提供全方位支持，並且希望能夠在Snow Leopard的“服役期間”內解決GCC的不兼容問題。
Apple爲Clang帶來了兩條引人注目的特性，那就是：更短的編譯時間和更快的可執行文件。Apple用其自身的軟件如iCal，Address Book，Xcode，以及一些第三方軟件如Adium和Growl進行了測試，Clang編譯器比GCC4.2快了近乎3倍。而對於編譯的可執行文件運 行速度，由Clang生成的可執行文件則比GCC 4.2生成的可執行文件快5~25%。
同時，與其前任GCC相比，Clang提供了更爲友好的開發環境。我承認這和多核CPU等新技術的優勢並無很大關聯，但這確實開發者在使用Clang時 首先面對的。
對於新手來說，Clang具有可嵌入性，因此Xcode可以在IDE的一些交互功能中使用和最終的可執行文件相同的編譯器結構。在編譯過程 中，Clang創建並保留了大量詳細的元數據(metadata)，從而有利於調試和錯誤報告。例如，如果GCC返回如下錯誤：
![compiler LLVM(zhuanzai) - Brown - 我的博客]()
這時候很難說清問題究竟在哪，對於編程新手來說尤爲如此。好吧，牛人或許已經看出來問題在哪了(如果您在WWDC上看到了這個例子的話)，但是我相信大 家都會認爲Clang返回的錯誤報告更有用：
![compiler LLVM(zhuanzai) - Brown - 我的博客]()
可能個別菜鳥仍然不知所措，但是至少可以清晰地看到問題究竟出在哪裏了：與GCC含糊其辭的迴應相比，Clang明明白白告訴你，哥們兒我不認識 “NSString”這個類型…
而且，有時候即使錯誤信息很明確，具體細節卻未必如此，譬如GCC返回的這個錯誤提示：
![compiler LLVM(zhuanzai) - Brown - 我的博客]()
很明顯，“無效的運算符號+”，但是這條語句中有4個“+”，究竟哪一個有問題呢？多虧這些相近的元數據(metadata)，Clang可以明確地爲 您指出問題所在：
![compiler LLVM(zhuanzai) - Brown - 我的博客]()
更進一步擡槓。有時候錯誤一目瞭然，譬如這個GCC的例子，在報錯行以上的語句中丟失了一個分號“；”：
![compiler LLVM(zhuanzai) - Brown - 我的博客]()
而Clang則更進一步，指出了究竟哪裏丟失了這個分號：
![compiler LLVM(zhuanzai) - Brown - 我的博客]()
樓下同學說了，這些都是“小事兒”，完全是雞蛋裏頭挑骨頭沒事兒找事兒，然而對於程序員來說，Clang提供的這種更爲細緻和細心的提示是相當貼心的。 當然，還有一些細節對於程序員來說則意義重大了，譬如這個基於LLVM的靜態分析器(static analyzer)。下圖顯示了靜態分析器發現並指出了一處可能的bug：
![compiler LLVM(zhuanzai) - Brown - 我的博客]()
圖中高亮的部分明確地指出了任何一位程序員都有可能犯的bug。靜態分析器檢測到，這一系列嵌套條件中，“myName”變量在至少一條路徑裏中未被初 始化，從而使得在最後一行發送“mutableCopy”時存在潛在的危險。
我相信Apple一定在其所有應用程序和操作系統上運行過靜態分析器，以檢查一些潛在的bug。而對程序員來說，能夠在龐大的代碼庫中自動監測潛在的 bug，無疑是一件非常爽的事情，對於自己開發平臺的程序員來說更是如此。某種程度上來講，Mac OS X 10.6.0中存在的bug比先前的任何一個10.x.0系統的bug都要少，無疑這將歸功於LLVM。
通過Clang/LLVM的進一步推廣和完善，Apple終於能夠完全掌控其自己的開發平臺了。CodeWarrior的經驗顯然使Apple更加清晰 地認識到，依賴於第三方平臺開發工具是相當不明智的。儘管花費了許多年的時間，但我認爲即使最頑固的Metrowerks支持者也會認爲，Snow Leopard提供的Xcode確實是個相當不錯的IDE。
許多年以來Apple一直糾結於GCC計劃與Apple自身的編譯需求之間的脫節，現在Apple終於痛下決心另闢蹊徑。誠然，GCC 4.2仍然是Snow Leopard的默認編譯器，但是很顯然Apple已進入的過渡期。Clang自然是推薦的編譯器，並且在可預見的將來，Apple的焦點將集中於此。
上期連載中已經提到，硬件領域的技術進步已經使得軟件和操作系統成爲了目前限制計算機性能的主要因素。或許您會有一些疑惑，究竟這些編譯器將如何幫助開 發者更好地利用現有的硬件資源呢？下期連載將爲您分析這個問題。
Weiphone.com將對該綜述進行翻譯整理並獨家連載。歡迎關注。
引用譯註：爲了 幫助您更加順暢地理解本文的內容，這裏補充了文中一些相關概念的背景資料。
編譯器(compiler)： 是一種能夠將源代碼(通常由高級別的程序語言編寫而成)轉換爲低級別機器語言的程序。源碼轉換最重要的一個目的在於創建可執行文件。詳情請參考 wikipedia。
LLVM(Low Level Virtual Machine，低級虛擬機)：是構架編譯器(compiler)的框架系統，以C++編寫而成，用於優化以任意程序語言編寫的程序的編 譯時間(compile-time)、鏈接時間(link-time)、運行時間(run-time)以及空閒時間(idle-time)，對開發者保持 開放，併兼容已有腳本。LLVM計劃啓動於2000年，最初由University of Illinois at Urbana-Champaign的Chris Lattner主持開展。2006年Chris Lattner加盟Apple Inc.並致力於LLVM在Apple開發體系中的應用。Apple也是LLVM計劃的主要資助者。詳情請參考llvm.org以及wikipedia。
GCC(GNU Compiler Collection，縮寫爲GCC)：是GNU計劃推出的支持多種程序語 言的編譯器系統。GCC是GNU Toolchain的主要組件。同時作爲GNU操作系統的官方編譯器，GCC已被作爲很多現代操作系統的標準編譯器，如GNU/Linux，BSD以及 Mac OS X；同時也可用於很多嵌入式平臺，如Symbian，AMCC等；還可用於一些遊戲機平臺如Playstation和Sega Dreamcast等。詳情請參閱Wikipedia以及GCC.GNU.org。
IDE(Integrated development environment)：是一種能夠爲程序員和軟件開發提供廣泛支持的軟件程序。IDE通常由源碼編輯器、編 譯器、自動化構建工具以及調試器組成。詳情請參閱Wikipedia。
早在幾年以前，Apple就在LLVM開源計劃上做出了重要的戰略性投資。我曾在一篇介紹Mac OS X Leopard的文章中簡要介紹了LLVM的一些基本情況，Leopard利用LLVM技術爲JIT編譯軟件的OpenGL功能提供了高效的執行支持。在 那篇綜述的最後，我這樣結尾：
引 用對於LLVM，Apple擁有相當宏偉的計劃：逐步摒棄Mac OS X中現有的GCC編譯器集合(complier collection)，並採用全新的基於LLVM的編譯器系統。該計劃稱爲"Clang"，並且已有了一些可喜的進展。
隨着Snow Leopard的推出，這一切開始逐漸浮出水面：Clang和LLVM已成爲Apple現行的編譯策略。LLVM甚至還有一個全新的帥氣的標：
目前，Apple爲Mac OS X總共提供了四種編譯器：GCC 4.0，GCC4.2，LLVM-GCC 4.2，以及Clang。這裏是一個圖表：
所有這些編譯器在Mac OS X上均具有二進制兼容性(binary-compatible)，這就意味着您可以使用一種編譯器創建一個資源庫並與使用另一個編譯器創建的可執行文件相 鏈接。並且，理論上講，這些都是命令行編輯器並且都具有資源兼容性。然而，Clang目前暫不支持GCC的一些複雜功能，同時Clang只支持C、 Objective-C和一點點C++(而GCC支持的相對較多)。Apple承諾，Clang未來將會爲C++提供全方位支持，並且希望能夠在Snow Leopard的“服役期間”內解決GCC的不兼容問題。
Apple爲Clang帶來了兩條引人注目的特性，那就是：更短的編譯時間和更快的可執行文件。Apple用其自身的軟件如iCal，Address Book，Xcode，以及一些第三方軟件如Adium和Growl進行了測試，Clang編譯器比GCC4.2快了近乎3倍。而對於編譯的可執行文件運 行速度，由Clang生成的可執行文件則比GCC 4.2生成的可執行文件快5~25%。
同時，與其前任GCC相比，Clang提供了更爲友好的開發環境。我承認這和多核CPU等新技術的優勢並無很大關聯，但這確實開發者在使用Clang時 首先面對的。
對於新手來說，Clang具有可嵌入性，因此Xcode可以在IDE的一些交互功能中使用和最終的可執行文件相同的編譯器結構。在編譯過程 中，Clang創建並保留了大量詳細的元數據(metadata)，從而有利於調試和錯誤報告。例如，如果GCC返回如下錯誤：
這時候很難說清問題究竟在哪，對於編程新手來說尤爲如此。好吧，牛人或許已經看出來問題在哪了(如果您在WWDC上看到了這個例子的話)，但是我相信大 家都會認爲Clang返回的錯誤報告更有用：
可能個別菜鳥仍然不知所措，但是至少可以清晰地看到問題究竟出在哪裏了：與GCC含糊其辭的迴應相比，Clang明明白白告訴你，哥們兒我不認識 “NSString”這個類型…
而且，有時候即使錯誤信息很明確，具體細節卻未必如此，譬如GCC返回的這個錯誤提示：
很明顯，“無效的運算符號+”，但是這條語句中有4個“+”，究竟哪一個有問題呢？多虧這些相近的元數據(metadata)，Clang可以明確地爲 您指出問題所在：
更進一步擡槓。有時候錯誤一目瞭然，譬如這個GCC的例子，在報錯行以上的語句中丟失了一個分號“；”：
而Clang則更進一步，指出了究竟哪裏丟失了這個分號：
樓下同學說了，這些都是“小事兒”，完全是雞蛋裏頭挑骨頭沒事兒找事兒，然而對於程序員來說，Clang提供的這種更爲細緻和細心的提示是相當貼心的。 當然，還有一些細節對於程序員來說則意義重大了，譬如這個基於LLVM的靜態分析器(static analyzer)。下圖顯示了靜態分析器發現並指出了一處可能的bug：
圖中高亮的部分明確地指出了任何一位程序員都有可能犯的bug。靜態分析器檢測到，這一系列嵌套條件中，“myName”變量在至少一條路徑裏中未被初 始化，從而使得在最後一行發送“mutableCopy”時存在潛在的危險。
我相信Apple一定在其所有應用程序和操作系統上運行過靜態分析器，以檢查一些潛在的bug。而對程序員來說，能夠在龐大的代碼庫中自動監測潛在的 bug，無疑是一件非常爽的事情，對於自己開發平臺的程序員來說更是如此。某種程度上來講，Mac OS X 10.6.0中存在的bug比先前的任何一個10.x.0系統的bug都要少，無疑這將歸功於LLVM。
通過Clang/LLVM的進一步推廣和完善，Apple終於能夠完全掌控其自己的開發平臺了。CodeWarrior的經驗顯然使Apple更加清晰 地認識到，依賴於第三方平臺開發工具是相當不明智的。儘管花費了許多年的時間，但我認爲即使最頑固的Metrowerks支持者也會認爲，Snow Leopard提供的Xcode確實是個相當不錯的IDE。
許多年以來Apple一直糾結於GCC計劃與Apple自身的編譯需求之間的脫節，現在Apple終於痛下決心另闢蹊徑。誠然，GCC 4.2仍然是Snow Leopard的默認編譯器，但是很顯然Apple已進入的過渡期。Clang自然是推薦的編譯器，並且在可預見的將來，Apple的焦點將集中於此。
上期連載中已經提到，硬件領域的技術進步已經使得軟件和操作系統成爲了目前限制計算機性能的主要因素。或許您會有一些疑惑，究竟這些編譯器將如何幫助開 發者更好地利用現有的硬件資源呢？下期連載將爲您分析這個問題。