compiler LLVM(zhuanzai)

 Mac OS X 10.6即所謂的Snow Leopard操做系統已正式發售。一如既往，Apple產品光鮮的外表下凝聚了太多艱辛的勞做。ArsTechnic的John Siracusa以其獨特的、專業的、全面的視角深刻翔實地體驗這款最新的操做系統。   

        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的焦點將集中於此。
        上期連載中已經提到，硬件領域的技術進步已經使得軟件和操做系統成爲了目前限制計算機性能的主要因素。或許您會有一些疑惑，究竟這些編譯器將如何幫助開 發者更好地利用現有的硬件資源呢？下期連載將爲您分析這個問題。