您好,登錄后才能下訂單哦!
這篇文章運用簡單易懂的例子給大家介紹如何在golang中實現自舉,代碼非常詳細,感興趣的小伙伴們可以參考借鑒,希望對大家能有所幫助。
golang實現自舉的方法:首先安裝【Go 1.4】或更高版本;然后使用現有的Go工具鏈創建【Go 1.5】工具鏈的一個基本版本;最后進一步用它構建【go_bootstrap】和其余的標準庫和標準組件。
golang實現自舉的方法:
自舉
(Bootstrapping) 是這樣的過程,“用要編譯的目標編程語言編寫其編譯器(或匯編器)”。一般而言,自舉有幾個優勢,比如:
用于測試被自舉的語言;
支持使用通常更為高級、提供更多高級抽象的語言來編寫編譯器;
編譯器也可以得益于語言層面的任何改進。
如前所述,Google在一年前就開始了從Go源碼樹中去除C代碼的努力,轉換計劃分為5個步驟:
第1階段——開發一個從C語言到Go語言的翻譯器,將現有的C編譯器翻譯成Go語言的。這一階段利用了一個事實:原來的編譯器沒有大量使用一些很難移植到Go語言的特性,比如宏、聯合和指針運算等。
第2階段——轉換編譯器的源碼樹,得到一個Go語言的編譯器,但是比較原始,而且是C風格的。
第3階段——將前面得到的編譯器轉換為符合Go語言習慣的程序,主要通過識別包,添加文檔和單元測試實現。
第4階段——優化編譯器,解決編譯器和CPU的內存使用問題,可能引入并行化。此外,嘗試在今天使用的不依賴架構的無序樹(Node*s)和依賴架構的有序列表(Prog*s)之間引入一個新的中間表示,目的是改進編譯器在消除冗余的nil檢查和邊界檢查等情況下的優化能力。
第5階段——用最新版的go/parser和go/types替換前端。
Russ提到,他們還考慮了一些替代方案,不過基于各種因素都排除了,在一年前的這份文檔中都有描述。
Go的自舉
編譯器的自舉通常會引發“先有雞還是先有蛋”的問題,必須提供一種方式來編譯我們要創建的語言。
Go的情況是,要構建Go 1.5,必須先安裝Go 1.4或更高版本,然后使用現有的Go工具鏈創建Go 1.5工具鏈的一個基本版本。一旦有了(Go 1.4)編譯的Go 1.5工具鏈,就可以再用它來構建自身了,可以進一步用它構建go_bootstrap和其余的標準庫和標準組件。這個過程加入了一個中間步驟——生成的工具鏈再被用于構建其自身,它可以應用于未來的任何Go版本。
為進一步了解Go實現自舉的計劃,InfoQ采訪了Russ。
實現自舉看上去是Go語言的一個很大的里程碑。在語言的演進過程中,為什么決定在這個階段做這個事情呢,可以詳細介紹一下嗎?
Go是一門不錯的通用語言,但在設計時考慮的適用場合是編寫大規模、高并發的服務端軟件,就像運行在Google的服務器上的那些。如果更早實現自舉,Go編譯器就是第一個大型的Go語言程序,這對語言設計存在不利影響,會讓我們遠離真正的目標。
沒有更早實現自舉,還有一些技術原因,比如可移植性,從源代碼編譯比自舉更容易,而且我們也能盡早有一個穩定的編譯器實現。
使用Go來構建Go,與使用C相比,你認為對哪些具體領域有較為明顯的改進?
Ken Thompson曾經對我說,用Go編寫程序感覺比用C更簡單。一個原因是,Go消除了好幾類常見的C bug,比如懸掛指針、內存泄漏、緩沖區溢出、深度遞歸時的棧溢出、誤用void*和意外的數值轉換等。
與任何標準的C工具鏈相比,標準的Go工具鏈對模塊化、單元測試和性能分析支持更好,不過讓我最興奮的是在修改內部API或重構時,應用自動化程序重寫(如gofix)的前景。
在“Go 1.3+ Compiler Overhaul”這篇文檔中,你描述了分5個步驟將現有的編譯器從C遷移到Go的過程。請問到目前為止,已經完成了哪些步驟了?其余步驟打算何時完成?
對Go項目而言,將語言的運行時從C轉換到Go更為重要,所以我們先做了這個。現在我們正回到編譯器。
從文檔角度看,我們目前處于第2階段。翻譯器已經完成,而且幫助我們轉換了運行時。我們正在將其應用于編譯器。我們希望完成Go 1.5編譯器的轉換。清理工作會在Go 1.5之后的項目中進行。
關于如何在golang中實現自舉就分享到這里了,希望以上內容可以對大家有一定的幫助,可以學到更多知識。如果覺得文章不錯,可以把它分享出去讓更多的人看到。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。