Go 1.3+ Compiler transformation

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

Overview Now the Go compiler is written in C, it's time to switch to go. Background The "GC" go tool chain comes from the tool chain of the Plan 9 compiler. The assembler, C compiler, and linker are basically unchanged. The Go Compiler (CMD/GC,CMD/5G,CMD/6G,CMD/8G) is a new C program written in conjunction with the tool chain. There are many benefits to using C instead of go to write the compiler when the project starts. For example, first of all, go does not exist at that time, cannot write compiler. And in fact, even if there are, there will always be obvious incompatible changes. Using C without go can avoid problems caused by initial and continuous development. But now that go 1 is stable, these ongoing problems are reduced a lot.

Fu Xiao Hei Translated 10 months ago 0 Person Top top translation of good Oh!

The problem of continuous development has been eliminated, in order for the compiler to implement the go More attractive than C, other engineering problems arise: Writing the correct go code is easier than writing the correct C code. Debugging the wrong go code is easier than debugging the wrong C code. Using the Go compiler requires a certain understanding of go. The C compiler also requires a certain understanding of C. Go makes concurrent execution easier than C. The Go has better standards for modularity, automatic rewriting, unit testing, and performance analysis. Go is more interesting (fun) than C. Based on the above reasons, we believe it is time to write the go compiler with go.

Fu translated 10 months ago 0 Human top top   good translation!

program set Think We are going to rewrite the C compiler with go using the automated translation tool. This translation takes some stages and will continue from go 1.3 to future releases. first stage . Develop and debug an automated translation tool. This can be done synchronously during daily development. Also, people can continue to improve the C compiler at this stage. This tool is a lot of work, but we have the confidence to complete this special Mission tool. There are many concepts of C that cannot be converted directly to Go;macros (macro), unions (federated, pooled,), bit fields (bit field) may be considered first. Lucky (not coincidental), these features are used less, will be translated out. pointer arithmetic and arrays also require some conversion work, although few in the compiler. The compiler is primarily a tree and linked list (linked list). The translation tool preserves the structure of comments and C code, so the translated code is as readable as the current compiler code.

Fu translated 10 months ago 0 Human top top   good translation!

Second stage . Use translation tools to convert C code to go and delete C source. At this point we have started translating, but go is still running on the C compiler. Very optimistic, this could happen in go 1.3. But more likely, go 1.4. third stage . Using some tools, it may come from Gofix and the Go Oracle, splitting the compiler into packages, cleaning and documenting the code, and adding the appropriate unit tests. This is where the compiler is going to be an authentic go program. Currently intended to be implemented in Go 1.4. fourth a stage . Use standard analysis and testing tools to optimize the compiler's CPU and memory usage. You might want to introduce parallelism. If so, Race Detector (Go's Parallel competition detection tool) can be very helpful. This target is on Go 1.4, which may be partially postponed to 1.5. The basic optimization analysis will be completed in the third phase.

Fu translated 10 months ago 1 Human top top   good translation!

Fourth B-stage . (and four a several paragraphs at the same time) when the compiler is divided into packets according to the obvious bounds, it is necessary to explicitly introduce a mediation code between the structure-independent unordered tree (node*s) and the structure-related ordered list (prog*s). The mediation code should not rely on the overall architecture, but contains accurate execution order information that can be used for optimization of sequential but structurally unrelated operations, such as clearing redundant nil detection and out-of-bounds detection. These procedures are based on SSA (static single assignment) and you can learn more from Alan Donovan's Go.tools/ssa package. phase fifth . For

Fu translated 10 months ago 1 top top   Good translation!

self-exhibition (Bootstrapping The Go compiler, implemented in the go language, will consider how to self-display from the start. The rule that we consider is that the Go1.3 compiler must be compiled by Go1.2, Go1.4 compiler must be compiled by Go1.4, and so on. At this point, we have a clear process to build the current program: Compile the Go1.2 toolchain (written by C), then use it to compile the Go1.3 toolchain, and so on. A script is needed to do this to ensure that it consumes only the CPU time and not the time of a person. This self-exhibition, each machine will only do once, the go1.x toolchain will be kept locally and executed All.bash to compile the Go1. (x+1) tool chain is used again. Obviously, this kind of bootstrap is not sufficient over time. It might be a more meaningful thing to write a backend for the compiler to generate C code before multiple versions are released later. These c codes do not require efficiency or readability, as long as they are correct. These C code will be checked in, just as we checked in the Y.TAB.C file generated by YACC. In this way, the self-exhibition process will become: first build a self-generated compiler with GCC compiled C code, and then use this self-generated compiler to compile the real compiler. Similar to another self-rollout process, this self-contained compiler will be kept locally and reused every time All.bash is executed (without recompiling).

mouse drinking river translated 9 months ago 0 Human top top   good translation!

Alternate selection There are some more obvious alternatives, and we need to explain why we gave up these choices. The Writes a compiler from the beginning. Today's compilers have a very important feature: they are able to work (or at least meet the requirements of all users). Although the go language is relatively simple, but the compiler has a lot of subtle details to optimize and rewrite, directly discard 10 or several years of effort on this is rather foolish. The Manually translates the compiler. We have translated a small part of the C + + code into the Go language in a manual way. The process is tedious and error-prone, and these errors are very subtle and difficult to spot. Conversely, the use of mechanical translation will result in some more consistent errors, which are easy to spot, and do not wander through the dull process. The go compiler code is significantly more than the code we translate: More than 60,000 lines of C code, mechanical translation will make the process easier. As Dick sites in 1974: "I would rather write a program to help me write a program than write a program." "  The use of machinery to translate the compiler is also convenient for us to continue to develop and refine our existing C programs before we are ready to switch.

mouse drinking river translated 9 months ago 0 Human top top   good translation!

Translate only back end and link to Go/parser and go/t Ypes. The information contained in the data structure from the front-end to the backend, Go/parser and go/types can provide except the API, there is nothing else. If you use these libraries instead of the front end, it is a very broad and error-prone task to write code to convert Go/parser and go/types to provide the data structure to the backend. We believe it makes sense to use these libraries, but it is wiser to wait until the compiler code is more like a go program, divided into deterministic boundaries, containing the description document and the unit Test sub-package. Discards the existing compiler, using GCCGO (or Go/parser + go/types + LLVM,   ...). ）。 The existing compilers are an important part of the go language that seems more flexible. If you try to develop a go program using GCC or LLVM, which is based on a lot of code, it can hinder the flexibility of the go language. In addition, GCC is a large number of C code (now has some C + +), LLVM is a large number of C + + code programs. Several reasons for not using the existing compiled framework code, as enumerated above, are also applicable to more similar code libraries.

mouse drinking river translated 9 months ago 0 Human top top   good translation!

C language The long-term use of is near the end, and the plan also leaves part of Plan9 's Toolchain, written by C. In the long run, it's better to exclude all C from the code tree. This section speculates on how this will happen, but does not guarantee that the designation will occur or follow this pattern. The Run-time package (runtime). Most of the  runtime packages are written in C, and the go compiler is implemented in C for some of the same reasons. However, the runtime package is much smaller than the compiler's code, and it is now written in a mix of go and c. When you convert C code to go code, one part of the conversion seems to be feasible. Among them, the main parts are: Scheduler (scheduler), garbage collection (the garbage collector), hash mapping table (hash map) implementation, and channel implementation. (The Go and C code mix well here, because it uses the C code of 6c instead of GCC to compile.) ) C compiler.  plan 9 C compiler itself is written in C, if we want to remove all the C code from the Go package implementation, then we will remove these compilation tools: "Go tool 6c" and so on, in addition,. c files will not be supported in the directory of the Go package appears. We should declare such plans in advance so that third-party packages with C have time to remove the use of such C code. (Cgo, because GCC is used instead of 6c, it can still be used as a way to implement some of the functions in the go package using C. The Go1 compatibility document does not contain a description of the tool chain modification, which means that removing the C compiler is allowed.

mouse drinking river translated 9 months ago 0 Human top top   good translation!

assembler.  plan 9 is also implemented in C, but this assembler is simply a simple parser consisting of a series of parse trees, which makes it easier to translate it into the go language either manually or automatically. connector. the connector for Plan 9 is also written in C. Some recent work has put most of the connector work into the compiler, and there is already a plan to rewrite the remainder into a new, simpler go program. Some of the connector code that is transferred to the compiler now needs to be translated along with the compiler's original code. Libmach-based tools: NM, pack, Addr2line, and Objdump. nm is now rewritten using the go language. Pack and Addr2line can be rewritten any day. Objdump now relies on Libmach's disassembler, but these transitions to go are also relatively straightforward, whether using mechanical or human translation. So based on these points, Libmach itself can be removed in the future.

The river of the rat drink Translated 9 months ago 0 Person Top top translation of good Oh!

All translations in this article are for learning and communication purposes only, please be sure to indicate the translator, source, and link to this article.
Our translation work in accordance with the CC agreement, if our work has violated your rights and interests, please contact us promptly