<p><a href="https://www.hakkalabs.co/articles/gopherfest-2015-rob-pike-move-c-go-toolchain">https://www.hakkalabs.co/articles/gopherfest-2015-rob-pike-move-c-go-toolchain</a></p>
<p>Can someone explain the point Rob makes at "25:05", something about portable code ?</p>
<hr/>**评论：**<br/><br/>sandokan1572: <pre><p>Typically, assembler is specific for each architecture. I think what RP is saying, is that they have their own custom assembler that can be compiled to machine code for different architectures.
See <a href="https://golang.org/doc/asm">https://golang.org/doc/asm</a> </p>
<blockquote>
<p>The most important thing to know about Go's assembler is that it is not a direct representation of the underlying machine. Some of the details map precisely to the machine, but some do not. This is because the compiler suite (see this description) needs no assembler pass in the usual pipeline. Instead, the compiler emits a kind of incompletely defined instruction set, in binary form, which the linker then completes. In particular, the linker does instruction selection, so when you see an instruction like MOV what the linker actually generates for that operation might not be a move instruction at all, perhaps a clear or load. Or it might correspond exactly to the machine instruction with that name. In general, machine-specific operations tend to appear as themselves, while more general concepts like memory move and subroutine call and return are more abstract. The details vary with architecture, and we apologize for the imprecision; the situation is not well-defined.</p>
</blockquote></pre>ericanderton: <pre><p>This sounds like a much more pragmatic take on the LLVM IR code. Perhaps it's not as optimal for code generation, but I'll bet it's easier to maintain.</p></pre>mdempsky: <pre><p>I believe Rob is talking about how different CPUs fundamentally have different instruction sets, so they're going to require you to write different instructions depending on your target CPU... but historically assemblers targeting different CPUs would also require different <em>syntax</em> even for the similar constructs.</p>
<p>For example, consider ARM and M68K:</p>
<pre><code>ldr r1, [r0, #4]! // ARM
move.l (a0)+, d0 // M68K
</code></pre>
<p>Those both have the same effect of roughly "x = *y++" (at least from my hazy memory and according to the webpages I copied them from :)). But why do they need to look so different? For something so basic as moving data from memory into a register, why not use a common mnemonic like "MOVE"? Why can't we keep consistent source/destination ordering across CPUs?</p>
<p>There's also a lot of variation across assembler tools of how to write and reference labels, compute addresses, declare function attributes, comments, etc. But the Plan 9 / Go assembler syntax is consistent across all target CPUs, only requiring different instructions for each.</p></pre>ericanderton: <pre><blockquote>
<p>Why can't we keep consistent source/destination ordering across CPUs?</p>
</blockquote>
<p>Hey, we only just got everything running with the same endianness. And we still have different word sizes all over the place. Progress takes forever with circuitry.</p>
<p>Also, in your example, another way to demonstrate this is that on some architectures, "x = *y++" takes <em>multiple</em> instructions to complete. That alone is reason enough to write pseudo-assembler and let some software figure out what you mean. </p>
<p>Hilariously, all this is why C was invented in the first place: a portable assembler.</p></pre>mdempsky: <pre><blockquote>
<p>Progress takes forever with circuitry.</p>
</blockquote>
<p>Circuitry shouldn't dictate assembler syntax. We can improve assembler syntax/tools without having to change CPUs.</p></pre>themihai: <pre><p>I guess asm is the "lowest" level you can go so that means it's portable? Languages come and go but seems asm is here to stay.</p></pre>hoffentlich: <pre><p>ASM is the lowest level but the least portable.</p></pre>schumacherfm: <pre><p>real programmers code in binary ;-)</p></pre>hoffentlich: <pre><p>Then there aren't any real programmers anymore.</p></pre>PassifloraCaerulea: <pre><p>It's more like "assembler"/"machine language" is a textual notation for the instructions of a particular CPU architecture. It is by definition not portable to other architectures. It <em>is</em> the lowest level in the sense that it maps more or less directly to the bit patterns fed to the silicon. Assembler will never go away as long as we want a textual representation of machine instructions.</p></pre>plafoucr: <pre><p>The guy typing on his keyboard during the talk, and near the mike is so annoying...</p></pre>
