Google announces plans to implement the go 1.5 bootstrap

This is a creation in Article, where the information may have evolved or changed.

Google recently unveiled a plan to implement go 1.5 bootstrap (Bootstrap). The author of the relevant documentation is Russ Cox, the Go core developer, who has been plowing the go language for nearly 6 years. According to Russ, Google has been brewing for "How to remove all C programs from the Go Source tree" for a year.

Bootstrap (Bootstrapping) is the process of "writing its compiler (or assembler) in the programming language of the target being compiled." Generally speaking, the bootstrap has several advantages, such as:

• Used to test the language of the bootstrap;
• Supports writing compilers using languages that are usually more advanced and provide more advanced abstractions;
• Compilers can also benefit from any improvements at the language level.

As mentioned earlier, Google began a year ago to remove the C code from the go source tree efforts, the conversion plan is divided into 5 steps:

• Phase 1th- developing a translator from the C language to the Go language , translating the existing C compiler into the go language. This phase takes advantage of the fact that the original compiler does not use a lot of features that are difficult to migrate to the go language, such as macros, unions, and pointer operations.
• The 2nd stage- conversion of the compiler's source tree , get a go language compiler, but relatively primitive, and is C-style.
• Phase 3rd- converts the previously obtained compilers into programs that conform to the go language habit , primarily by identifying packages, adding documents and unit Test implementations.
• Phase 4th- Optimizing the compiler to resolve memory usage issues with the compiler and CPU, possibly introducing parallelization. In addition, an attempt was introduced to introduce a new intermediate representation between the schema-independent unordered tree (node*s) and the schema-dependent sequence table (prog*s), which is used today, to improve the compiler's ability to optimize for the elimination of redundant nil checks and boundary checks.
• 5th phase- Replace the front end with the latest version of Go/parser and Go/types.

Russ mentioned that they also considered alternatives, but were excluded from all factors, as described in the document a year ago.

Go self-lifting

The compiler's bootstrap usually raises the question of "chicken first or egg first" and must provide a way to compile the language we want to create.

In the case of go, to build go 1.5, you must first install Go 1.4 or later, and then use the existing go toolchain to create a basic version of the Go 1.5 tool chain. Once you have the Go 1.5 toolchain (go 1.4) compiled, you can use it to build yourself and use it to build go_bootstrap and the rest of the standard libraries and standard components. This process adds an intermediate step-the generated toolchain is then used to build itself, which can be applied to any future go version.

To learn more about the Go Implementation bootstrap program, Infoq interviewed Russ.

Implementing bootstrap appears to be a big milestone in the go language. In the course of the evolution of language, why did you decide to do this at this stage, can you explain it in detail?

go is a good general-purpose language, but the design-time consideration is to write large-scale, high-concurrency server software, just like those running on Google's servers. If you implement bootstrap earlier, the Go compiler is the first large Go Language program, which has a detrimental effect on language design, leaving us out of our true goals.

No, there are some technical reasons, such as portability, that compiling from source code is easier than bootstrap, and we can have a stable compiler implementation as early as possible.

use go to build go, compared to using C, What specific areas do you think are the most obvious improvements?

ken Thompson once told me that using go to write a program feels more simple than c. One reason is that go eliminates several common C bugs, such as hanging pointers, memory leaks, buffer overflows, stack overflows at depth recursion, misuse of void*, and accidental numeric conversions.

The standard go Toolchain is better for modularity, unit testing, and performance analysis than any standard C toolchain, but what excites me most is that when modifying the internal API or refactoring, The prospect of applying an Automation program rewrite (such as Gofix).

for the Go project, it's more important to convert the language runtime from C to go, so we did this first. Now we are going back to the compiler.

from a document point of view, we are currently in the 2nd phase. The translator has completed and helped us convert the runtime. We are applying it to the compiler. We want to complete the conversion of the go 1.5 compiler. The cleanup will be done in the project after go 1.5.

View English text: Google Aims at Bootstrapping Go 1.5