4 ms·

Sure but golang has its own special assembly flavor rather than using standard gcc flavor inline assembly. Probably because it's a soup to nuts compiler but sti

by nimish 2y ago

Sure but golang has its own special assembly flavor rather than using standard gcc flavor inline assembly. Probably because it's a soup to nuts compiler but still.

tptacek 2y ago
The point of this article is that Go-specific assembler generators (Avo in particular) are better than standard assembly for this purpose.
- nimish 2y ago
  That doesn't preclude syntactic compatibility, does it?
citizenpaul 2y ago
>soup to nuts compiler Any chance you can explain that to rubes like me?
- tptacek 2y ago
  Go isn't built on an existing compiler framework like LLVM. It does its own code generation, has its own assembler.
  - nwokon 2y ago
    There is an accident of history here. Go was developed with the plan 9 C compiler suite as a starting point. Most notably those compilers did not generate assembler -- they emitted object code directly. This is described here: https://9p.io/sys/doc/compiler.html https://9p.io/sys/doc/compiler.html. The assembler facilitated transforming hand-written assembly to object code. And here the plan 9 folks chose a new syntax, probably because it was simpler to start afresh over using the existing "AT&T" or "Intel" syntax.
    - nimish 2y ago
      Typical plan 9, change for the sake of change. Second system effect writ large.
Veserv 2y ago
This is not at all comparable to inline assembly which interleaves two different languages into the same source file. The presented examples are just a straight distinct assembly language associated with the golang ecosystem used in their own dedicated source files called via a FFI. This is comparable to just writing a pure assembly file and linking it into your program which is actually a much more reasonable thing to do than the insanity of inline assembly. The problems being highlighted are just cases of people who do not understand ABIs and ABI compatibility. This is extremely common when crossing a language boundary due to abstraction mismatches and is made worse, not better, by doing even more magic behind the scenes to implicitly paper over the mismatches.

by nimish 2y ago

Sure but golang has its own special assembly flavor rather than using standard gcc flavor inline assembly. Probably because it's a soup to nuts compiler but still.

tptacek 2y ago

The point of this article is that Go-specific assembler generators (Avo in particular) are better than standard assembly for this purpose.

nimish 2y ago
That doesn't preclude syntactic compatibility, does it?

citizenpaul 2y ago

>soup to nuts compiler Any chance you can explain that to rubes like me?

tptacek 2y ago
Go isn't built on an existing compiler framework like LLVM. It does its own code generation, has its own assembler.
- nwokon 2y ago
  There is an accident of history here. Go was developed with the plan 9 C compiler suite as a starting point. Most notably those compilers did not generate assembler -- they emitted object code directly. This is described here: https://9p.io/sys/doc/compiler.html https://9p.io/sys/doc/compiler.html. The assembler facilitated transforming hand-written assembly to object code. And here the plan 9 folks chose a new syntax, probably because it was simpler to start afresh over using the existing "AT&T" or "Intel" syntax.
  - nimish 2y ago
    Typical plan 9, change for the sake of change. Second system effect writ large.

Veserv 2y ago

This is not at all comparable to inline assembly which interleaves two different languages into the same source file. The presented examples are just a straight distinct assembly language associated with the golang ecosystem used in their own dedicated source files called via a FFI. This is comparable to just writing a pure assembly file and linking it into your program which is actually a much more reasonable thing to do than the insanity of inline assembly. The problems being highlighted are just cases of people who do not understand ABIs and ABI compatibility. This is extremely common when crossing a language boundary due to abstraction mismatches and is made worse, not better, by doing even more magic behind the scenes to implicitly paper over the mismatches.