Go in Go
talks.golang.org
talks.golang.org
They're all C programmers!
Wasn't CFront written in C++?[1] (Of course, the initial version of C with classes was probably written in C.)
Which languages do you think guys at Microsoft, Apple and Google get to choose?
Those developed by their employers or others?
Why to you think all of them created languages to replace C on their daily work?
There are many reasons to use a specific programming languages besides "I like it".
For example I will never use C on personal projects, but will use it without any complaints if that is what my customers ask for.
In what possible sense can it be described as an assembler?
If there was, then it wouldn't be "portable"
I think the joke/humor/analogy is that C compilers are so good and C itself is so low level, that you don't actually gain much (if anything at all) by dropping down to ASM now (compared to 10-20 years ago).
Only when I’m writing very performance-sensitive code do I actually think “here’s a branch, there’s a load, yonder is a divide”. Most of the time it’s “eh, compiler’ll get it”.
For example, you wouldn't want to implement a garbage collector in a garbage collected language; C won't get in your way.
This is also why there are loads of C libraries out there: they can be used with bindings from essentially any other language, which is generally not true for libraries implemented in non-C languages (in particular, C++).
Remember that it also enforces the idea of types, scopes, blocks, functions, the heap and the data stack quite strictly. It might be a very low level language compared to something like Java, but in terms of being unassuming of architectural intent, I can't say that I agree that it is even in the same ballpark as any of the assembly languages I've used.
Also there's no fast way to check arithmetic overflow from portable C, which limits bignum performance.
Due to these limitations better portable assembly languages like C-- have been designed; these days LLVM bitcode is an option as well (which is not actually portable IIRC...).
"By design, C provides constructs that map efficiently to typical machine instructions"[1]
I believe this is what the op was getting at. This is why C is called a "mid level" language.
[1] http://en.wikipedia.org/wiki/C_%28programming_language%29
C is one of the few languages today that still gives you very precise control over how you use memory. That can be a powerful tool, especially given how important effective cache usage is on chips.
I'm not saying it would be necessary slower than a compiler written in C, if they wrote the more critical parts in assembler, but you would think compiling speed would be one of the outstanding discussion points, after a major rewrite.
http://talks.golang.org/2015/gogo.slide#15
While the next mentions that the got it back up -- but not by how much.
It wasn't exactly crystal clear from the docs/website, but apparently[1] "master" is go1.5 -- so with go1.4 on windows, one can:
# from a git bash, already have go1.4 installed
git clone https://github.com/golang/go.git go.git
cd go.git/src
git checkout master
export GOROOT_BOOTSTRAP=$GOROOT
time cmd "/c all.bat"
real 0m29.078s
user 0m0.015s
sys 0m0.030s
# with our fresh go1.5 (see more below):
real 0m33.034s
user 0m0.000s
sys 0m0.000s
Note that if you want to do this, in particular the second part, it gets a bit hairy, as "go.exe" needs to be in your path, and you need to change your gopath (easy).
On my system, I had everything in $HOME/opt (%HOME%\opt), so all i did was move opt\go to opt\go1.4, and copy go.git to \opt\go. One can confirm the right version is being run with 'go version' (and 'cmd "/c go version"' from bash).
[1] After a few useless hits, I found: https://godoc.org/golang.org/x/mobile/cmd/gomobile -- which mentions what's needed to actually test go 1.5. If they want testers, they should probably add something under "install from source" on golang.org about "And if you want to live on the edge, or say, test go in go, use "master")
Edit: Of course, faster speeds would be interesting to hear about, so great question.
Fast compilation is an explicit goal of Go, so they certainly think it matters.
https://groups.google.com/forum/#!msg/golang-dev/6obxRcm-rqc...
https://github.com/golang/go/tree/dev.ssa
No idea how long it will take to mature, but I hope there are some decent performance improvements once it is fully functional.
> Generate machine descriptions from PDFs (or maybe XML).
> Will have a purely machine-generated instruction definition:
> "Read in PDF, write out an assembler configuration".
> Already deployed for the disassemblers.
(my emphasis)
That coupled with a whole tool chain in a friendly language like go, makes be exited for how this might be used by other language designers. While "compile to go" might not be as attractive as "compile to c" -- it's not half-bad. More importantly it kind of smells like part of this tool chain should make it quite easy to generate machine code quite easily.
Nothing against llvm, rpython/pypy, graal etc - but the more the merrier!
All that said you can of course write your own bots, but Copmputer Go isn't as easy as one might think. In fact it's still considered a much harder problem than Computer Chess.
> [14:54:36] Topic is Go, the game (not the silly language) ! (the language see #go-nuts
> Code is cleaner, testable, profilable, easier to work on.
This is just great!
How do you write a GC in a GC'd language?
Can the GC be interrupted by itself if it takes too long or uses too much memory?
It seems like there are several things about the GC that would need to be special-cased, since the GC is implicitly invoked by the runtime.
For example, Pre-Scheme and RPython.
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.3.40...
edit: This is the link I meant - https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thomp...
c_i is the i'th version of the compiler.
c1 c2 // c1 compiles c2
c2 c3 // c2 compiles c3
Horrible.
Much like HackerNews website implementation, actually.
That slide-script is just broken.
Of course, that's the nature of bootstrapping! If someone managed to erase all the software from all the computers in the world, we'd have to go back and find an "Old world" Mac and use the on-die Forth compiler to write a C compiler so we could start compiling things again.
Otherwise, I'm guessing that for Go 1.6, they'll rely on you having a binary distribution of 1.5 (probably from your distribution, or their website), etc.
That's not true at all, (1) you write the backend for the target machine, (2) you recompile the compiler with the new backend included on a supported host, (3) then use the new compiler to compile itself for the target using the new backend, (4) you now have a compiler that runs on the target.
Same process is used to port C compilers (or any self-hosting compiler, really).
I get that you can write a program which compiles language X to machine code, e.g. how python interpreting Go to write the assembly necessary would be technically possible.
My question is, how is the compiler generated? If it's written in c, gcc -o compiler, but what is the piece I'm missing when it comes to Go compiles a Go compiler -- or is this still done as "here's the machine code, now compile the Go runtime"?
I suppose my question is a similie to "the chicken or the egg?".
The bootstrapping process can therefore take advantage of the fact that go1.4 will continue to build as it does today, and use that to get a working go installation to build go1.5+.
Instead, any Linux distribution etc. that wants to integrate the language into its build system has to start by importing a binary from somewhere else. In general this isn't a problem, because that binary is used only to compile the compiler from source (and then that compiler recompiles itself, usually), so any bugs in it are unlikely to affect the final product. However, the topic tends to come up of Ken Thompson's famous paper [2] describing a hypothetical scenario where a compiler binary is intentionally backdoored to insert a vulnerability when it's compiling some security-critical program, plus a copy of the same backdoor whenever it detects it's compiling itself. In that case, the backdoor could theoretically infect the final result of a bootstrap, despite it being compiled from pristine source; no attack of that nature has ever been detected in the wild, though.
[1] https://docs.google.com/document/d/1OaatvGhEAq7VseQ9kkavxKNA...
[2] https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thomp...
You've got no go1.4 there to boostrap you (new architecture), and you can't get the binary because you're trying to build the first one.
Build the new version of the compiler with the previous version of the compiler
Rebuild the new version of the compiler with the new compiler from the previous step, that was built with the old compiler
Rebuild the new compiler with the new compiler from the previous step, that was also built with the new compiler, and that's your official binary
The initial creation of the language requires somebody to write a compiler for it in assembly or in some other language that already has one, but once you get that first one built, all the rest could be in their own language.
Yes.
> whenever i see the "X is all but Y" phrase, it makes sense to me that X is not Y.
It's not "X is not Y", it's "X is all but Y", that is, X is very nearly not Y. "All but impossible" means it's possible, but only barely.
All but impossible, it's everything up to, but not including impossible.
Start by implementing in Assembly as little as possible for the programming language as an interpreter.
Meaning just one form of conditionals, just one looping construct, very few basic types, basic IO.
Then use the bare bones interpreter for the second stage, writing a real compiler that is able to process the same basic language and additional constructs.
Another alternative is to add some bytecode format that can then be used equally for interpretation or as input to native code generation.
Niklaus Wirth originally designed P-Code with the intent to make Pascal compilers easier to port. He wasn't thinking to use it as full OS VM, like the guys at UCSD did with they Pascal dialect.
Another trick is to design the bytecode in such a way that it can directly be translated to native code via a macro assembler. It won't generate fast code, but it will provide an easy path for a compiler instead.
Nowadays the Assembly step tends to be replaced by another language that can be found in most platforms, so many tend to choose C.
Not always because it is the best language to write compilers in, but rather because it is ubiquitous or there is some library the authors want to use, thus perpetuating the myth that all languages require C for those not so well versed in compiler design.
> Use the left and right arrow keys _or click the left and right edges of the page_ to navigate between slides.
I will note that go programs still seem to build orders of magnitude faster than C++ programs, even after this change.
Because the compiler is now written in Go, compiler optimization will affect how fast programs compile.
The compiler may speed up or slow down because it is doing more advanced code analysis, but is generating better assembly. I do not know if this will cancel itself out or not.
• Talk 1: Andrew Gerrand on Go
• Talk 2: Rob Pike on Go
• Talk 3: Aaron Schlesinger, Concurrency Conventions in Go
• Talk 4: Steve Francia, Common Mistakes in Go and When to Avoid ThemI'm having trouble running the compiler.
bpgcomp bpgcomp.bpg -o bpgcomp