So you need 1.4 to build 1.5....can you then rebuild 1.5 from 1.5? Would it be different? Would it make a difference if you then rebuilt 1.5 using 1.5 built using 1.5 rather than 1.5 built using 1.4?
> So you need 1.4 to build 1.5....can you then rebuild 1.5 from 1.5?
If the language is forward-compatible, yes. It could be different if new optimisations have been added, or the code generator has changed.
> Would it make a difference if you then rebuilt 1.5 using 1.5 built using 1.5 rather than 1.5 built using 1.4?
It should not, the 1.5 compiler should be stable and yield the same result whether it was built using a 1.4 compiler or a 1.5 compiler.
That's actually a common technique to look for regressions and validate the bootstrapped compiler. For instance to compile rustc you download a "stage 0" compiler at Vx which compiles a "stage 1" compiler using Vy > Vx source. That stage 1 compiler is then used to compile the stage 2 compiler from the same source. Stage 1 and stage 2 may not be identical since stage 0 and stage 1 may have different optimisations &al, so the stage 2 compiler is used to compile rust a third time, and that compilation is checked against the original stage 2 (and should be a fixpoint).
That's actually a step in bootstrapping the system. Generally, to bootstrap a language a new language involves building a minimal bootstrap compiler/runtime that is just enough to be able to rebuild the full system:
1. build bootstrap system with existing tools
2. compile full system with bootstrap
3. compile full system again with new compiler
Or something like that.
Edit/Note: The OP linked document is a pretty good explaination of the whole process as well as the implications ...
If both compilers are correct, which compiler you compiled the program
(compiler in this case) with shouldn't matter for the correctness of the
code; but the generated code would be different. There should be no
difference in the code generated by instances of the same compiler version,
although the code of the compiler programs itself would be different
(i.e. different performance, time of exec...) if they were compiled with
different compiler versions.
Edit: That's all assuming same version of the language being compiled.
That's why they say the go1.x compilers may need to stay restricted to
go 1.4 for their code.
P.S. See Linux From Scratch or osdev.org for more about this
I'm curious, as the document doesn't mention it, what is the benefit of bootstrapping? Is it primarily to allow future development to happen in the bootstrapped language, instead of the lower-level language (C in this case)? Or is there some other benefit I'm missing?
Bootstrapping has the benefit that the whole compiler toolchain can enjoy the usage of the language.
Additionally it is a way to expose the language designers to possible issues in the language, as they will spend more time using it instead of other implementation language, which helps improving its design and tools.
Personally I tend to favour bootstraping, even if it is a little inconvenient when porting to new architectures.
Microsoft found themselves unable to improve the C# language using a compiler written in a lower level language like C/C++ so they've rewritten it in C# to allow further language development and to support more sophisticated language features.
It also has the benefit of the team implementing the language actually dogfooding it, causing natural evolutionary improvements.
I suspect Google is doing this with go for the same reasons.
Ugh...this is going to make new ports such a pain. I can understand why they're doing it, but this is going to make my life a lot more difficult.
If 1.4 is going to become the bootstrap toolset, that also suggests that 1.4 will essentially become "long-term supported", meaning that if new ports require fixes to the bootstrap toolset (even in the cross-compilation) scenario, hopefully they'll accept those changes upstream.
Also, there is no dependency on 1.4 being "long-term supported". I think you have the dependency requirement backward.
For the foreseeable future, it must be possible to build the compiler with Go 1.4. That means the compiler must stick to Go 1.4 libraries and constructs (or use build tags for conditional compilation). It says nothing about which version of Go you have to use to build the compiler. If we're working on Go 1.9 and you want to use Go 1.7 as the bootstrap base, that's fine: Go 1.7 will build and run everything that Go 1.4 does. You just can't introduce any Go 1.7-specific code into the compiler.
I don't know if you've noticed, but there are very few language changes in each release. We're focused on improvements to performance and reliability more than new features. So I don't anticipate it being a hardship that the compiler is limited to Go 1.4. (And that's still much nicer than C.)
What new ports are you working on? (I'm just curious.)
Go is already very good at cross-compiling. That can be used to do a new port (as a trivial example, the fact that the compiler doesn't run on NaCl didn't hurt the NaCl port at all). There is a section in the doc explicitly about this. We are doing new ports too (like power64), and I don't anticipate the bootstrapping change slowing them down appreciably.
I'm not sure I understand why this makes ports harder.
Shouldn't it be possible to port to a new system simply by porting Go 1.4 to that system? Once that base version is ported, a script can build 1.4, then build 1.5 and any succeeding base versions until the current version is reached.
Of course, system-specific features would have to be added for each go release beyond 1.4, but that would have to be done anyway.
Can't you just write code generation for platform Y while on platform X? I guess you would have to do a bit of copying files around while debugging, but that shouldn't be the main issue when porting a system like this..
I'm more surprised that the Go 1.4 compiler is written in C. Writing a compiler in C sounds very unpleasant compared to a language like OCaml. Does anyone know why they made this choice for the initial design?
The Go compiler in 2007 was written in C because it was an adaptation of the Plan 9 C compiler. That was done because it was the expedient choice at the time, especially while the language was still being designed and would change quite a lot. Nowadays the language is stable, and we have existing Go compilers, so we can reasonably bootstrap a Go compiler written in Go.
[+] [-] robbrown451|11 years ago|reply
[+] [-] masklinn|11 years ago|reply
If the language is forward-compatible, yes. It could be different if new optimisations have been added, or the code generator has changed.
> Would it make a difference if you then rebuilt 1.5 using 1.5 built using 1.5 rather than 1.5 built using 1.4?
It should not, the 1.5 compiler should be stable and yield the same result whether it was built using a 1.4 compiler or a 1.5 compiler.
That's actually a common technique to look for regressions and validate the bootstrapped compiler. For instance to compile rustc you download a "stage 0" compiler at Vx which compiles a "stage 1" compiler using Vy > Vx source. That stage 1 compiler is then used to compile the stage 2 compiler from the same source. Stage 1 and stage 2 may not be identical since stage 0 and stage 1 may have different optimisations &al, so the stage 2 compiler is used to compile rust a third time, and that compilation is checked against the original stage 2 (and should be a fixpoint).
[+] [-] emeraldd|11 years ago|reply
1. build bootstrap system with existing tools 2. compile full system with bootstrap 3. compile full system again with new compiler
Or something like that.
Edit/Note: The OP linked document is a pretty good explaination of the whole process as well as the implications ...
[+] [-] nsajko|11 years ago|reply
Edit: That's all assuming same version of the language being compiled. That's why they say the go1.x compilers may need to stay restricted to go 1.4 for their code.
P.S. See Linux From Scratch or osdev.org for more about this
[+] [-] jsherer|11 years ago|reply
[+] [-] enneff|11 years ago|reply
It's a process we started more than a year ago: http://golang.org/s/go13compiler
[+] [-] pjmlp|11 years ago|reply
Additionally it is a way to expose the language designers to possible issues in the language, as they will spend more time using it instead of other implementation language, which helps improving its design and tools.
Personally I tend to favour bootstraping, even if it is a little inconvenient when porting to new architectures.
[+] [-] josteink|11 years ago|reply
It also has the benefit of the team implementing the language actually dogfooding it, causing natural evolutionary improvements.
I suspect Google is doing this with go for the same reasons.
[+] [-] binarycrusader|11 years ago|reply
If 1.4 is going to become the bootstrap toolset, that also suggests that 1.4 will essentially become "long-term supported", meaning that if new ports require fixes to the bootstrap toolset (even in the cross-compilation) scenario, hopefully they'll accept those changes upstream.
[+] [-] rsc|11 years ago|reply
For the foreseeable future, it must be possible to build the compiler with Go 1.4. That means the compiler must stick to Go 1.4 libraries and constructs (or use build tags for conditional compilation). It says nothing about which version of Go you have to use to build the compiler. If we're working on Go 1.9 and you want to use Go 1.7 as the bootstrap base, that's fine: Go 1.7 will build and run everything that Go 1.4 does. You just can't introduce any Go 1.7-specific code into the compiler.
I don't know if you've noticed, but there are very few language changes in each release. We're focused on improvements to performance and reliability more than new features. So I don't anticipate it being a hardship that the compiler is limited to Go 1.4. (And that's still much nicer than C.)
[+] [-] rsc|11 years ago|reply
Go is already very good at cross-compiling. That can be used to do a new port (as a trivial example, the fact that the compiler doesn't run on NaCl didn't hurt the NaCl port at all). There is a section in the doc explicitly about this. We are doing new ports too (like power64), and I don't anticipate the bootstrapping change slowing them down appreciably.
[+] [-] abtinf|11 years ago|reply
Shouldn't it be possible to port to a new system simply by porting Go 1.4 to that system? Once that base version is ported, a script can build 1.4, then build 1.5 and any succeeding base versions until the current version is reached.
Of course, system-specific features would have to be added for each go release beyond 1.4, but that would have to be done anyway.
What am I missing?
[+] [-] codyps|11 years ago|reply
Does go not support being cross compiled/cross compiling?
[+] [-] thomasahle|11 years ago|reply
[+] [-] cheepin|11 years ago|reply
[+] [-] enneff|11 years ago|reply
[+] [-] dsymonds|11 years ago|reply
[+] [-] microtonal|11 years ago|reply
[1] http://gcc.gnu.org/git/?p=gcc.git;a=commit;h=2b15d2ba7eb3a25...
[+] [-] andrewchambers|11 years ago|reply
[+] [-] choffee|11 years ago|reply
[+] [-] enneff|11 years ago|reply
[+] [-] microtonal|11 years ago|reply
[+] [-] ansible|11 years ago|reply
[+] [-] jesuslecharlle|11 years ago|reply
[deleted]
[+] [-] doognukem|11 years ago|reply
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] f2f|11 years ago|reply
(before the downvotes start raining, my joke is referring to the Go compatibility promise, not the lack of whizbang blinkenlights)
[+] [-] wowoc|11 years ago|reply
[+] [-] barryallen22|11 years ago|reply
[+] [-] mkohlmyr|11 years ago|reply