A colleague passed this along to me. I've been doing a lot of work in the guts of the Go runtime as part of my work at Wallaroo Labs and while there isn't a ton here yet, what there is was helpful.
The links at the bottom were what I found particularly helpful.
Go's "pseudo-assembly" is not a plus. Everyone ends up learning both the architecture's assembly and the mapping to Go's pseudo-assembly which isn't actually portable because each architecture has architecture-specific features.
Perhaps such a thing makes sense when you are a target for languages but not when you are just a language. Instead make sure anything that you can express with your IR can be expressed with the language?
That is like saying functions are not a plus, because you need to learn the functions and the mapping to the code used to implement the functions.
The Go assembly language is no different from having macros, functions or anything else providing a higher level of abstraction to relieve the developer of thinking about every little nuance of the underlying language.
11 comments
[ 3.5 ms ] story [ 31.5 ms ] threadThe links at the bottom were what I found particularly helpful.
A low level IR requires less effort to implement a compiler backend.
In Go's case, it is what makes the reference compiler so easy to cross-compile.
The Go assembly language is no different from having macros, functions or anything else providing a higher level of abstraction to relieve the developer of thinking about every little nuance of the underlying language.
32<<32|10 might be a bit clearer, then...