Hacker News Reader

Comment by Bnshsysjab | Hacker News Reader

> like the performance-hostile calling convention, are harder to fix.

Can you elaborate on what you mean by this? I’m new to go and want to understand the performance implications.

not gp, but it looks like go's calling convention requires pushing all function args and return values to the stack [1]. thats always going to be less efficient than most C calling conventions, where (iirc) you put what you can in registers and only use the stack if registers aren't enough

EDIT: and all registers are caller-saved. so when calling a function, all register contents will be saved on the stack (and restored later) even if the function doesn't touch certain registers

[1](https://dr-knz.net/go-calling-convention-x86-64.html)

Wow, maybe they have some valid reason for that, but from where I'm standing it just seems like an extremely lazy and thoughtless design choice that belongs in a prototype and nowhere else.

Does it help goroutines and the scheduler?

it's not lazy, it's simple! ;)

i don't think its intended as a stable target and will probably change at some point. the top google hit was a 3rd party site, and this issue is still open [#16922 doc: document assembly calling convention](https://github.com/golang/go/issues/16922)

btw the source i linked in my original comment links to a proposal to allow passing args in registers

This is not a language problem, but a compiler problem also. gccgo uses registers like C.

true, thanks for pointing that out!

How can that be true? Every assembly function in Go moves its arguments from memory relative to the stack pointer. If the arguments were in registers instead it would break every assembly function. Does gccgo not support asm?

> In contrast to 6g (the original Go compiler) gccgo tries to mimic the native calling convention.

https://dr-knz.net/go-calling-convention-x86-64.html#differe...

I just tried it and it won't build my existing Go packages that include x86 assembly files. So I conclude that it does indeed break compatibility with asm, which certainly is one way to change the calling convention.

It's more than a compiler problem: Go modules contain assembly routines which assume the Go calling conventions, so changing the convention is now quite breaking.

There's a lesson in there about success, or something...

I think Go's calling conventions also don't allow for tail call optimization?

Reply on news.ycombinator.com