Is Go's assembly intended to be mostly platform-independent or platform-specific?
I clicked through to the AES example, and found that it "makes use of Go Assembly to leverage Intel's hardware support for AES, calling the AES-NI CPU instructions." So does that only work on Intel CPUs?
I'm confused about why Go has its own assembly syntax if you're going to be writing platform-specific code anyway. Or can you write Go assembly that works well on both x86 and ARM, say?
EDIT to put the question a different way: what are some use cases where you'd use Go assembly? In C, you'd typically drop down to platform-specific assembly for two reasons: 1) to muck about with the stack, for example in a threading library, or 2) to use platform-specific instructions, like NEON or SSE. (In that second case you can often get away with intrinsics rather than assembly, though.) Does Go assembly have the same uses, or different ones?
I'm partly with the dtrace guy, but it is nice to see somebody not propagating that gcc inline asm shite... so I'm prepared to forgive it a certain amount.
I'm not a Go fan, but I'm not ready to dismiss it as "trash" -- I mean, it works! And plenty of people like it.
But I can't quite figure out whether this Go assembly stuff is a real feature that makes sense and is well-designed, or if it's just a quirk of the implementation, stemming from its background in Plan 9.
The assembly section in the Go docs literally says "go read the Plan 9 docs first". That's kind of weird.
That has different .s files for different architectures, and a .go file with the platform-independent version, so the assembly clearly isn't platform-independent.
It seems a strange decision to disguise e.g. arm64 assembly behind an x86-like syntax, so I'm going to go with "quirk of the implementation."
As I understand it, Go's assembly is an artifact of its heritage--it was initially built by developers who were more familiar with the Plan 9 toolchain than they were with other toolchains.
This has been my consistent frustration with the development philosophy. I like to describe it as deciding to build a sweet new car to get from SF to LA and starting by paving the roads. Using 30 year old asphalt. Focus on what you bring to the table, and use LLVM or, god forgive me even GCC ;) as your foundation. Great writeup, thanks for sharing.
The particular slide linked above answers the question "what are the advantages of having their own assembler." Turns out, they'll be able to abstract away the differences across the different manufacturers' assemblers to where they can just feed in the PDFs to be able to support that platform.
Its not platform-independent. However they do use the legacy plan 9 code so some of the opcode and conventions are consistent across different platforms but they can't hide all the differences.
I clicked through to the AES example, and found that it "makes use of Go Assembly to leverage Intel's hardware support for AES, calling the AES-NI CPU instructions." So does that only work on Intel CPUs?
I'm confused about why Go has its own assembly syntax if you're going to be writing platform-specific code anyway. Or can you write Go assembly that works well on both x86 and ARM, say?
EDIT to put the question a different way: what are some use cases where you'd use Go assembly? In C, you'd typically drop down to platform-specific assembly for two reasons: 1) to muck about with the stack, for example in a threading library, or 2) to use platform-specific instructions, like NEON or SSE. (In that second case you can often get away with intrinsics rather than assembly, though.) Does Go assembly have the same uses, or different ones?