3 ms·

Go assembler is such a strange inclusion - I guess the idea is it lets you do low-level routines without requiring CGO?

by jasonthorsness 1y ago

nu11ptr 1y ago
That is my understanding. It lets you bypass CGo overhead, but I'd be lying if I said I fully understood it.
- MangoToupe 1y ago
  Yes, to a certain extent if you have knowledge about the code you're calling into, you can "cheat" and stay on the go stack rather than switching to the C one. This take pretty solid knowledge of both runtimes to manage.
pjmlp 1y ago
Not really, having an Assembler around has been quite common in compiled languages, before the rise of scripting languages in the 2000's. For all my complaints about Go's design, that is certainly one that I appreciate.
Thaxll 1y ago
It's heavily used where you need performance, for example crypto. https://go.dev/wiki/AssemblyPolicy https://go.dev/wiki/AssemblyPolicy https://github.com/golang/go/tree/master/src/crypto/internal/fips140 https://github.com/golang/go/tree/master/src/crypto/internal...
- nasretdinov 1y ago
  My understanding is that for crypto specifically it constant-time algorithms matter due to security implications, and those are only available when you use specific branchless assembly instructions, so it's not just performance
  - charcircuit 1y ago
    CPUs do not guarantee that branchless instructions always take the same amount of time.
    - Arnavion 1y ago
      CPUs guarantee what they guarantee, and if they guarantee that a certain instruction takes an operand-independent time then it does. For example a RISC-V CPU implementing the Zkt extension is required to implement a whole bunch of logical and arithmetic integer operations with operand-independent timing. This includes the two "branchless move" instructions from the Zicond extension, czero.eqz and czero.nez.
  - foobiekr 1y ago
    Just to pick nits, the important thing is basically no secret-dependent { branches, loop bounds checks, memory accesses }. This is a lot more complex than simple "constant time."
cyberax 1y ago
Remember that Go actually compiles the code to machine code directly, so it needs to have an assembler for its compiler. And if you have it, then why not make it available?
- Stratoscope 1y ago
  > Go actually compiles the code to machine code directly True. > so it needs to have an assembler for its compiler. No, it doesn't need an assembler for this. As you said correctly, it compiles to machine code directly. While it was once fairly common to use assembly as an intermediate step, very few or any modern compilers do that. They just compile directly to binary machine code. Go does have a -S flag to generate assembly language so you can review the generated code more easily. But that assembly code isn't part of the compilation pipeline, it's just optional output for human review.
  - deleted 1y ago
    [deleted]
    - wrs 1y ago
      `-S` is a disassembler, or an assembly generator. You definitely want that when developing a compiler. But an assembler that goes the other direction, that’s entirely optional.
  - kbolino 1y ago
    I think this is just half true. When dealing with purely high-level code (including C without inline assembly), the compiler doesn't need a discrete assembler. This much is true, and most modern compilers will not spit out assembly unless requested. However, there's usually still a stage of the compilation process where an assembly-like internal representation is used. Once the compiler has chosen which registers to use and where, and which instructions to use and in what order, etc., it's close to machine code but not fully there yet. At this point, jump targets will still be labels without concrete addresses, instructions will be still be referenced by mnemonic, etc. Serializing this internal representation as assembly will generally produce more readable code than disassembling the final binary. So it's not assembly exactly, but it's pretty close.
foobiekr 1y ago
Sometimes you need assembly. There's nothing shocking here other than Go doing this well when it's a gap for most languages.

Go assembler is such a strange inclusion - I guess the idea is it lets you do low-level routines without requiring CGO?

nu11ptr 1y ago

That is my understanding. It lets you bypass CGo overhead, but I'd be lying if I said I fully understood it.

MangoToupe 1y ago
Yes, to a certain extent if you have knowledge about the code you're calling into, you can "cheat" and stay on the go stack rather than switching to the C one. This take pretty solid knowledge of both runtimes to manage.

pjmlp 1y ago

Not really, having an Assembler around has been quite common in compiled languages, before the rise of scripting languages in the 2000's. For all my complaints about Go's design, that is certainly one that I appreciate.

Thaxll 1y ago

It's heavily used where you need performance, for example crypto. https://go.dev/wiki/AssemblyPolicy https://go.dev/wiki/AssemblyPolicy https://github.com/golang/go/tree/master/src/crypto/internal/fips140 https://github.com/golang/go/tree/master/src/crypto/internal...

nasretdinov 1y ago
My understanding is that for crypto specifically it constant-time algorithms matter due to security implications, and those are only available when you use specific branchless assembly instructions, so it's not just performance
- charcircuit 1y ago
  CPUs do not guarantee that branchless instructions always take the same amount of time.
  - Arnavion 1y ago
    CPUs guarantee what they guarantee, and if they guarantee that a certain instruction takes an operand-independent time then it does. For example a RISC-V CPU implementing the Zkt extension is required to implement a whole bunch of logical and arithmetic integer operations with operand-independent timing. This includes the two "branchless move" instructions from the Zicond extension, czero.eqz and czero.nez.
- foobiekr 1y ago
  Just to pick nits, the important thing is basically no secret-dependent { branches, loop bounds checks, memory accesses }. This is a lot more complex than simple "constant time."

cyberax 1y ago

Remember that Go actually compiles the code to machine code directly, so it needs to have an assembler for its compiler. And if you have it, then why not make it available?

Stratoscope 1y ago
> Go actually compiles the code to machine code directly True. > so it needs to have an assembler for its compiler. No, it doesn't need an assembler for this. As you said correctly, it compiles to machine code directly. While it was once fairly common to use assembly as an intermediate step, very few or any modern compilers do that. They just compile directly to binary machine code. Go does have a -S flag to generate assembly language so you can review the generated code more easily. But that assembly code isn't part of the compilation pipeline, it's just optional output for human review.
- deleted 1y ago
  [deleted]
  - wrs 1y ago
    `-S` is a disassembler, or an assembly generator. You definitely want that when developing a compiler. But an assembler that goes the other direction, that’s entirely optional.
- kbolino 1y ago
  I think this is just half true. When dealing with purely high-level code (including C without inline assembly), the compiler doesn't need a discrete assembler. This much is true, and most modern compilers will not spit out assembly unless requested. However, there's usually still a stage of the compilation process where an assembly-like internal representation is used. Once the compiler has chosen which registers to use and where, and which instructions to use and in what order, etc., it's close to machine code but not fully there yet. At this point, jump targets will still be labels without concrete addresses, instructions will be still be referenced by mnemonic, etc. Serializing this internal representation as assembly will generally produce more readable code than disassembling the final binary. So it's not assembly exactly, but it's pretty close.

foobiekr 1y ago

Sometimes you need assembly. There's nothing shocking here other than Go doing this well when it's a gap for most languages.