HackerTube.dev

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

Gopher Academy · 115.8K views · 2016-08-18 · 23:57

Open on YouTube ↗

If playback is restricted in your region, try opening the original video. Use Mark watched to add it to your marked videos.

Overview

Rob Pike's GopherCon 2016 talk on the design of the Go assembler, explaining why Go uses a common assembly language translated to each architecture.

On Hacker News

HN points to it for background on how the Go toolchain targets many architectures and why its assembler is designed that way.

Recommended by 3 HN people across 3 months · HN mentions 2017–2025

Topics

Search by tags

What people said

fourseventy · 2017-09 · Recommendation

This is relevant [VIDEO] Its Rob Pike talking about the go assembler and he answers a few of your questions.

Read the original HN comment ↗
bkeroack · 2017-04 · Recommendation

Here's a good talk about the Go assembler backend: [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.

Read the original HN comment ↗
chubot · 2017-02 · Recommendation

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: [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

Read the original HN comment ↗

Sources

Video by Gopher Academy, played through YouTube.

Data and selection notes

HN summaries and labels may contain AI errors. HN dates refer to discussions, not video publication.

HN Library: HackerTube export (2026-10-31) and open-index/hacker-news. Upstream summaries and classifications may contain AI errors.

Views, duration and playback status refresh separately from the published catalog. When an update fails, existing data remains visible.

Selection checks
  • SaaS & AI candidates: Topic keywords do not match
  • Editor-approved picks: Editorial review is required

Rule matches identify candidates. They do not guarantee video quality or financial results.

About the library and its sources