GopherCon 2016: The Design of the Go Assembler - Rob Pike

This is relevant ▶ this video Its Rob Pike talking about the go assembler and he answers a few of your questions.

in “Go Assembly by Example” · View on HN

Here's a good talk about the Go assembler backend: ▶ this video Spoiler: they're nearly to the point (maybe now they've achieved it fully) of autogenerating a new language backend from ISA documentation PDFs! Bring that up next time someone complains about Go not using LLVM.

in “A Foray into Go Assembly Programming” · View on HN

Have you looked at the Go toolchain at all? I don't know much about it, but they implemented their back ends in a manner that is much smaller than LLVM and GCC. And it sounds like the architecture of the compiler is significantly different. I watched this talk and it was pretty interesting: ▶ this video [link] If I am understanding right, the claim is that they have a single assembly language for ALL GO architectures, based on something Ken Thompson wrote in the 90's for some National Instruments (?) chip. He actually says that all assembly language looks the same now. I was sort of surprised by that claim. I would like to hear a critique of this from other compiler writers. Does the fact that Go uses a single assembly language make the code slower? I imagine taking advantage of target-specific knowledge is useful, but I don't know how much. LLVM has this pretty elaborate TableGen system to express target-specific knowledge. He also makes the claim that they will be able auto-generate a new backend from the PDF description of the architecture. And he says somewhere that they reduce a lot of the work to simple "text processing" (symbol manipulation) and didn't require opening up any processor manuals. I can see how arithmetic and bitshifting is the same among all architectures. But I would think that even loads and stores have differences, at least if you want to use the processor efficiently. But he says everything kinda looks the same. Also, another thought is that compiling to W

in “Show HN: How to write a tiny compiler” · View on HN

I'm reminded of a 2016 [talk][1] where Rob Pike describes the common-denominator assembly language that the Go compiler generates. Then that assembly is translated into machine-specific code via table lookups. See the 11 minute mark. [1]: ▶ this video

in “Show HN: Torque – A lightweight meta-assembler for any processor” · View on HN

> Overall, pretty weird stuff. I am not sure why the Go team went down this route. Maybe it simplifies the compiler by having this bespoke assembly format? Rob Pike spoke on the design of Go's assembler at a talk in 2016 [1][2]. I think it basically came down to the observation that most assembly language is roughly the same, so why not build a common assembly language that "lets you talk to the machine at the lowest level and yet not have to learn a new syntax." It also enables them to automatically generate a working assembler given an instruction manual PDF for a new architecture as input. [1]: ▶ this video [2]: [link]

in “Show HN: Go Plan9 Memo” · View on HN

Generally the inline assembly is hand-written and must follow the platform rules, see "Architecture-specific details" in [link] The few tools that generate that asm, such as [link] , would also have follow the rules. You're not meant to take C source, crank it through GCC, and slurp that in as inline asm in Go. Background: ▶ this video

in “Runtime code generation and execution in Go” · View on HN