4 ms·
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
by uryga 6y ago
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 https://dr-knz.net/go-calling-convention-x86-64.html)
- microcolonel 6y agoWow, 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.
- defnotashton2 6y agoDoes it help goroutines and the scheduler?
- uryga 6y agoit'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 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
- jen20 6y agoThis is not a language problem, but a compiler problem also. gccgo uses registers like C.
- uryga 6y agotrue, thanks for pointing that out!
- jeffbee 6y agoHow 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?
- uryga 6y ago> 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#differences-with-gccgo https://dr-knz.net/go-calling-convention-x86-64.html#differe...
- jeffbee 6y agoI 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.
- millstone 6y agoIt'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...
- eru 6y agoI think Go's calling conventions also don't allow for tail call optimization?