How to store Go pointers from assembly
1–10 of 22 posts
Re: How to store Go pointers from assembly
#2Go assembler is such a strange inclusion - I guess the idea is it lets you do low-level routines without requiring CGO?
Re: How to store Go pointers from assembly
#3Go assembler is such a strange inclusion - I guess the idea is it lets you do low-level routines without requiring CGO?
That is my understanding. It lets you bypass CGo overhead, but I'd be lying if I said I fully understood it.
Re: How to store Go pointers from assembly
#4Go assembler is such a strange inclusion - I guess the idea is it lets you do low-level routines without requiring CGO?
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.
Re: How to store Go pointers from assembly
#5Go assembler is such a strange inclusion - I guess the idea is it lets you do low-level routines without requiring CGO?
It's heavily used where you need performance, for example crypto.
https://go.dev/wiki/AssemblyPolicy
https://github.com/golang/go/tree/master/src/crypto/internal...
Re: How to store Go pointers from assembly
#6Go assembler is such a strange inclusion - I guess the idea is it lets you do low-level routines without requiring CGO?
It's heavily used where you need performance, for example crypto. https://go.dev/wiki/AssemblyPolicy https://github.com/golang/go/tree/master/src/crypto/internal...
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
Re: How to store Go pointers from assembly
#7Go assembler is such a strange inclusion - I guess the idea is it lets you do low-level routines without requiring CGO?
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?
Re: How to store Go pointers from assembly
#8Earlier quoted context omitted.
It's heavily used where you need performance, for example crypto. https://go.dev/wiki/AssemblyPolicy https://github.com/golang/go/tree/master/src/crypto/internal...
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
CPUs do not guarantee that branchless instructions always take the same amount of time.
Re: How to store Go pointers from assembly
#9Earlier quoted context omitted.
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
CPUs do not guarantee that branchless instructions always take the same amount of time.
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.
Re: How to store Go pointers from assembly
#10Earlier quoted context omitted.
It's heavily used where you need performance, for example crypto. https://go.dev/wiki/AssemblyPolicy https://github.com/golang/go/tree/master/src/crypto/internal...
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
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."