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

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

Interestingly, one of the pages you link ( [link] ) links a paper (grep "1986: Kelsey dissertation on rewrite-based compilation ") that shows the implementation of a compiler with multiple frontends (BASIC, Scheme, Pascal) using only source-to-source) transformation. I find this interesting because in a certain way, this reminds me of how the go assembler works ( [this video] ). For those who haven't seen the talk: basically the go compiler works on the assumption that pretty much all computer, in a way, move memory from one address to another, generate and handle interrupts, have call/return instructions and so on. Thus, the go compiler emits (IIRC) some sort of "intermediate assembler" (somehow similar to llvm's intermediate representation, but simpler) and then proceeds to "translate" such assembler to various platform native assembler. I clearly remember Rob Pike (in the talk) saying "so the task of supporting a new platform becomes a task in text processing" (okay, maybe it was worded a bit better). This might be a bit tangential, but it is interesting how some "new" ideas aren't that new after all. But I guess this is due to Rob Pike's deep experience and history with computers.

> I kind of miss cgi-bin. If we're ever to get back to a place where random "power users" can knock up a quick server to meet some computing need they have, easy deployment has to be a big part of that. Can we make it as easy to deploy as to post on Instagram? I'd be happy with a future that takes some cues from literate programming, where if you want to deploy some application, the way you do it is to upload a copy of the software manual/specification. This should be sufficient to "teach" the server how the application should behave. It's tempting to say "Ah, sounds like super advanced ChatGPT-ops or something approaching real AGI", but what I have in mind is something decidedly less magical. It's more akin to the sort of thing that Rob Pike brought up in his "The Design of the Go Assembler" talk ("you have a machine readable description[...] why not read it with a machine?"). < [this video] >