战魂小筑

讨论群:309800774 知乎关注:http://zhihu.com/people/sunicdavy 开源项目:https://github.com/davyxu

   :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理 ::
  252 随笔 :: 0 文章 :: 506 评论 :: 0 Trackbacks

概述

目前Go编译器是C写的,是时候换成Go啦。

背景

“gc"Go工具链来自Plan 9编译器的工具链。组装器、C编译器和链接器基本没变。Go的编译器(cmd/gc,cmd/5g,cmd/6g,cmd/8g)是配合工具链写的新的C程序。

项目起始时,用C而不是Go写编译器有很多好处。突出的比如,首先,那时候Go还不存在,没法儿写编译器。而且实际上,就算存在,也会经常有明显的不兼容的变化。用C不用Go可以避免初始和持续开发导致的问题。然而如今Go 1已经稳定,所以这些持续的问题减少了很多。

持续开发的问题已经消除,为了让Go实现的编译器比C更有吸引力,另一些工程问题出现:

  • 写正确的Go代码比写正确的C代码更容易。

  • 调试错误的Go代码比调试错误的C代码更容易。

  • 使用Go编译器需要对Go有一定理解。而用C编译器还需要一定理解C。

  • Go使并发执行比C更方便。

  • Go有更好的标准支持模块化,自动重写,单元测试和性能分析。

  • Go比C更有趣(fun)。

基于以上理由,我们相信是时候用Go写Go编译器啦。

计划设想

我们打算用自动化翻译工具来用Go重写现在C的编译器。这个翻译需要一些阶段,将从Go 1.3开始持续到未来的发行版。

第一阶段。开发和调试一个自动化翻译工具。这可以在日常开发时同步进行。而且,人们还可以在这个阶段为C编译器继续改进。这个工具工作量很大,不过我们有信心完成这个特殊使命的工具。有许多C的观念没法儿直接转换成Go;macros(宏),unions(联合,共用体,),bit fields(位域)可能最先考虑。比较幸运(不是巧合),这些功能功能用的少,都会被翻译掉。指针运算和数组也需要一些转换工作,尽管编译器里很少。编译器里主要是tree(树)和linked list(链表)。翻译工具会保留注释和C代码的结构,所以翻译后的代码和当前的编译器代码一样可阅读。

第二阶段。用翻译工具转换C代码到Go,并删除C源码。这时我们已经开始翻译,但是Go还是运行在C编译器上。非常乐观的,这可能发生在Go 1.3。不过更可能是Go 1.4。

第三阶段。使用一些工具,可能来自gofix和the Go oracle,拆分编译器到包,清理和文档化代码,添加适当的单元测试。这是编译器会是地道的Go程序。目前打算在Go 1.4实现。

第四a阶段。使用标准的分析和测试工具优化编译器的CPU和内存使用。可能要引入并行。如果真这样,Race Detector(Go的并行竞争检测工具,)会有很大帮助。这目标在Go 1.4,可能部分会延后到1.5。基本的优化分析会在第三阶段完成。

第四b阶段。(和四a几段同时进行)当编译器依照明显的界限分割成包之后,需要明确引入一个中介码,在结构无关的无序树(Node_s)和结构相关的有序链表(Prog_s)之间。这个中介码应该不依赖整体架构,但是包含准确的执行顺序信息,可以用于有顺序但是结构无关的操作的优化,比如清理多余的nil检测和出界检测。这些过程基于SSA(静态单赋值),你可以从Alan Donovan的 go.tools/ssa 包中了解更多。

第五阶段。替换go/parser和go/types到最新(全新)的版本。Robert Griesemer参考现在的经验,讨论了设计新的parser和types的可能。如果联系他们到编译器后端,相信对设计新的API有很大帮助。

自展(Bootstrapping)用Go语言实现的Go的编译器,从一开始就要考虑如何自展。我们考虑的规则就是Go1.3编译器必须由Go1.2编译,Go1.4的编译器必须由Go1.4编译,以此类推。

这时,我们就有了一个清晰的流程来生成当前的程序:编译Go1.2的工具链(由C编写),然后使用它编译Go1.3的工具链,以此类推。这里需要一个脚本来做这个事情,来保证只会消耗CPU的时间而非某个人的时间。这样的自展,每个机器只会做一次,Go1.x的工具链将会在本地保留,并在执行all.bash来编译Go1.(x+1)工具链的时候被再次使用。

显然,随着时间的推移这种自举方式是不充分的。在后面的多个版本被发布之前,为编译器写一个后端来生成C代码也许是一个更有意义的事情。这些C代码不要求效率或可读性,只要正确即可。这些C代码将会被签入,就像我们签入由yacc生成的y.tab.c文件一样。这样,自展过程就会变成:先用gcc编译C代码生成一个自展编译器,然后使用这个自展编译器来编译真正的编译器。类似于另一个自展过程,这个自展编译器将会在本地保留,并在每次执行all.bash的时候重复使用(不用重新编译)。

替代选择还有一些比较明显的替代方案,需要我们说明一下为什么放弃了这些选择。

从一开始写一个编译器。现在的编译器有一个非常重要的特征:他们能够正常工作(或者其至少能够满足所有用户的要求)。尽管Go语言比较简单,但是编译器中有很多细微的细节优化和改写,直接丢弃10或数年的在这上面的努力是比较愚蠢的。

对编译器进行人工翻译。我们已经以人工的方式翻译了一小部分C/C++代码到Go语言了。这个过程是枯燥而且易错的,且这些错误非常的细微及难以发现。相反,使用机械翻译会形成一些比较一致的错误,而这些错误是易于发现的;而且不会因为枯燥的过程开小差。Go编译器的代码明显的比我们翻译的代码多很多:超过60,000行C代码,机械翻译会使这个过程容易一些。就像Dick Sites在1974年说的一样:“相比写程序,我宁愿写一个程序来帮我写程序。“ 使用机械来翻译编译器也方便于在准备好切换之前,我们可以继续开发完善现有的C程序。

只翻译后端并链接到go/parser和go/types.从前端传给后端的数据结构所包含的信息中,go/parser和go/types所能提供的除了API就没其他的东西了。如果使用这些库来替代前端,需要写代码来转换go/parser和go/types所能提供数据结构到后端,这是一个非常宽泛且易出错的工作。我们相信使用这些库是有意义的,但更明智的是,等到将编译器代码调整的更像Go程序,分成确定边界的、包含说明文档和单元测试子包之后再使用。

放弃现有的编译器,使用gccgo(或者go/parser + go/types + LLVM, …)。现有的编译器是Go语言显得比较灵活的一个重要组成部分。如果尝试使用基于大量代码的GCC或LLVM来开发Go程序,感觉会有碍到Go语言的灵活性。另外,GCC是大量C代码(现在有部分C++)、LLVM是大量C++代码的程序。以上列举的、用于解释不使用现有编译框架代码的几个原因,也都适用于更多的类似的代码库。

C语言的长期使用

临近结束,这个计划还留下了由C写成的Plan9的工具链的一部分。在长期发展中,还是将所有的C从代码树排除掉比较好。本章节推测了一下这件事将会如何发生,但不保证其指定会发生或者按照这种套路发生。

运行时包(runtime)。 runtime包的大部分都是用C写成,基于一些同样的原因,Go编译器也是用C实现。但是,runtime包远比编译器的代码量要小,且它现在已经是用Go和C混合编写。将C代码转换为Go代码时,一次转化一部分貌似也是可行的。其中,主要部分有:调度器(scheduler),垃圾回收(the garbage collector),散列映射表(hash map)的实现,和channel的实现。(这里Go和C代码混合的很融洽,是因为这里使用的6c而不是gcc来编译的C代码。)

C编译器。 Plan 9的C编译器本身就是用C写成,如果我们要从Go包实现里面移除所有的C代码,那么我们将移除这些编译工具:“go tool 6c”等等,另外,.c的文件也将不被支持出现的Go包的目录里面。我们应该提前声明这样的计划,以便使用C的第三方包有时间去移除这类C代码的使用。(Cgo,由于使用了gcc来替代6c,所以它仍然可以作为一个途径来在Go包中使用C实现部分功能。)在Go1的兼容性文档中没有包含工具链修改的描述,也就是说去掉C编译器是被允许的。

汇编器。 Plan 9的汇编器也是用C实现的,但这个汇编器只不过是一系列解析树组成的简单解析器,这使得不论手动还是自动将它翻译成Go语言都比较简单。

连接器。 Plan 9的连接器也是由C写成。最近的一些工作,已经将大部分的连接器工作放到的编译器中,而且,也已经有个计划将剩余的部分重写成一个新的、更简单的Go程序。转移到编译器的部分连接器代码,现在需要随着编译器的原有代码一起进行翻译。

基于Libmach的工具: nm, pack, addr2line, 和objdump。 Nm现在已经使用Go语言重写。Pack和addr2line可以任何一天被重写。Objdump现在依赖于libmach的反汇编器,但这些转换为Go也是比较简单的,不论是使用机械还是人工翻译。所以基于这几点,libmach本身将来也可以被移除。

 

来源: http://www.oschina.net/translate/go-1-3-compiler-overhaul

英文来源:https://docs.google.com/document/d/1P3BLR31VA8cvLJLfMibSuTdwTuF7WWLux71CYD0eeD8/preview?sle=true&pli=1

posted on 2014-01-22 12:23 战魂小筑 阅读(890) 评论(0)  编辑 收藏 引用 所属分类: 网络 服务器技术工具使用及设计

只有注册用户登录后才能发表评论。
【推荐】超50万行VC++源码: 大型组态工控、电力仿真CAD与GIS源码库
网站导航: 博客园   IT新闻   BlogJava   知识库   博问   管理