3 ms·

You said "easier than C". How is linking to assembly code from Go any easier than linking to assembly code from C?

by azakai 14y ago

burntsushi 14y ago
Just go see how it's done. Look for example at how `math.Exp` is declared: http://golang.org/src/pkg/math/exp.go?s=368:395#L4 http://golang.org/src/pkg/math/exp.go?s=368:395#L4 You'll notice that 'exp' is defined below, using Go. However, 'Exp' is also defined in Assembly. For example, amd64: http://golang.org/src/pkg/math/exp_amd64.s http://golang.org/src/pkg/math/exp_amd64.s This is all compatible with the `go` tool. You just drop in your Assembly, run `go build`, and the appropriate Assembly version is chosen based on your target architecture (or the Go code is used as a fallback if no Assembly for the target architecture exists). I don't have much experience with inlining Assembly in C, but this is pretty damn easy.
- codygman 14y ago
  That is so awesome, I'm willing to bet they plan on inlining quite a few functions in the future too... which means drastic speedups.
- lmm 14y ago
  Easy? Sure. Easier than C? Nope. Sounds like it has the equivalent of a few make rules written for you (which is nice, make is a mess, but not really an advantage for go-the-language per se), but you could do exactly the same thing in C - and you can also inline assembly in your C source file.
  - burntsushi 14y ago
    > Sounds like it has the equivalent of a few make rules written for you No. It sounds like the `go` tool is aware of how to compile different pieces of code for different architectures. > but you could do exactly the same thing in C - and you can also inline assembly in your C source file. Why does this make C easier? Does C automatically choose the correct target architecture for every piece of Assembly you write?
    - lmm 14y ago
      >Why does this make C easier? It gives you more options. It makes it more practical to interleave C and assembly at a very granular level, whereas it sounds like you can only do it at the function level or coarser in go. >Does C automatically choose the correct target architecture for every piece of Assembly you write? No. I won't deny that go has a good build system, but I'm more interested in the language.
    - azakai 14y ago
      > Why does this make C easier? Inlining some assembly where you need it - interacting with C variables, etc. - is definitely the most convenient thing. Of course, if you don't want that, you can just put the assembly code in a separate function, also very easy to do with C.
- azakai 14y ago
  > I don't have much experience with inlining Assembly in C, but this is pretty damn easy. It's about the same as C. If you want to see really easy, take a look at how LuaJIT does it (DynASM).
strmpnk 14y ago
It allows multiple platforms to be implemented w/o a series of macros.

You said "easier than C". How is linking to assembly code from Go any easier than linking to assembly code from C?

by azakai 14y ago

You said "easier than C". How is linking to assembly code from Go any easier than linking to assembly code from C?

Just go see how it's done. Look for example at how `math.Exp` is declared: http://golang.org/src/pkg/math/exp.go?s=368:395#L4 http://golang.org/src/pkg/math/exp.go?s=368:395#L4 You'll notice that 'exp' is defined below, using Go. However, 'Exp' is also defined in Assembly. For example, amd64: http://golang.org/src/pkg/math/exp_amd64.s http://golang.org/src/pkg/math/exp_amd64.s This is all compatible with the `go` tool. You just drop in your Assembly, run `go build`, and the appropriate Assembly version is chosen based on your target architecture (or the Go code is used as a fallback if no Assembly for the target architecture exists). I don't have much experience with inlining Assembly in C, but this is pretty damn easy.

codygman 14y ago
That is so awesome, I'm willing to bet they plan on inlining quite a few functions in the future too... which means drastic speedups.
lmm 14y ago
Easy? Sure. Easier than C? Nope. Sounds like it has the equivalent of a few make rules written for you (which is nice, make is a mess, but not really an advantage for go-the-language per se), but you could do exactly the same thing in C - and you can also inline assembly in your C source file.
- burntsushi 14y ago
  > Sounds like it has the equivalent of a few make rules written for you No. It sounds like the `go` tool is aware of how to compile different pieces of code for different architectures. > but you could do exactly the same thing in C - and you can also inline assembly in your C source file. Why does this make C easier? Does C automatically choose the correct target architecture for every piece of Assembly you write?
  - lmm 14y ago
    >Why does this make C easier? It gives you more options. It makes it more practical to interleave C and assembly at a very granular level, whereas it sounds like you can only do it at the function level or coarser in go. >Does C automatically choose the correct target architecture for every piece of Assembly you write? No. I won't deny that go has a good build system, but I'm more interested in the language.
  - azakai 14y ago
    > Why does this make C easier? Inlining some assembly where you need it - interacting with C variables, etc. - is definitely the most convenient thing. Of course, if you don't want that, you can just put the assembly code in a separate function, also very easy to do with C.
azakai 14y ago
> I don't have much experience with inlining Assembly in C, but this is pretty damn easy. It's about the same as C. If you want to see really easy, take a look at how LuaJIT does it (DynASM).

strmpnk 14y ago

It allows multiple platforms to be implemented w/o a series of macros.