Go assembler is such a strange inclusion - I guess the idea is it lets you do low-level routines without requiring CGO?
Sometimes you need assembly. There's nothing shocking here other than Go doing this well when it's a gap for most languages.
How to store Go pointers from assembly
11–20 of 22 posts
Re: How to store Go pointers from assembly
#12Go 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?
> 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.
Re: How to store Go pointers from assembly
#13This is a strange and dangerous thing to try to do from assembly. In particular, all these details about write barriers being hand-coded in the assembly are subject to change from release to release.
Better to structure your code so that you do the pointer manipulation (and allocation) in Go code instead, and leave assembly only for what is absolutely necessary for performance (usually things like bulk operations, special instructions, and so on).
Re: How to store Go pointers from assembly
#14This is a strange and dangerous thing to try to do from assembly. In particular, all these details about write barriers being hand-coded in the assembly are subject to change from release to release. Better to structure your code so that you do the pointer manipulation (and allocation) in Go code instead, and leave assembly only for what is absolutely necessary for performance (usually things like bulk operations, sp…
In this case, "atomic 128-bit store" is the special instruction, with the twist that half of those 128 bits contain a pointer.
Re: How to store Go pointers from assembly
#15Earlier quoted context omitted.
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?
> 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 generat…
[deleted]
Re: How to store Go pointers from assembly
#16Earlier quoted context omitted.
> 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 generat…
[deleted]
`-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.
Re: How to store Go pointers from assembly
#17Earlier quoted context omitted.
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?
> 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 generat…
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.
Re: How to store Go pointers from assembly
#18Go 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.
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.
Re: How to store Go pointers from assembly
#19Earlier quoted context omitted.
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?
> 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 generat…
The division between 'assembler' and 'generating machine code directly' can be pretty blurry depending on the interface. I imagine a compiler would basically interleave what the assembler would normally do with the code generation. I don't think this really yields deep insight, though, you're effectively doing the same thing either way.
Re: How to store Go pointers from assembly
#20Earlier quoted context omitted.
> 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 generat…
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…
Yes, very true! And more accurate than what I wrote. The point I meant to make was that assembly language in the text form that we would use is not part of the compilation process. But I oversimplified my description rather badly.
Interestingly, Go also has a -d=ssa/all switch that outputs not just an assembly representation of the final code, but also the results of each optimization pass.
Here is a discussion I had with ChatGPT about this:
https://chatgpt.com/share/6859aea5-df1c-8012-be70-f2361060fb...