I think so. It's nice to have more registers and all, but the consistency of an entirely stack-oriented calling convention is simply more elegant and ergonomic IMHO. The register passing overflowing into stack-oriented at some arbitrary limit is just hideously warty, and obnoxious if you're actually writing assembly with C ABI function calling.
Changing the signature of functions requires rearranging which registers are being populated, and if there's enough parameters some go in the stack, and if you've rearranged the order, now you're moving some from stack back to registers and visa versa. At least when everything was always going through the stack, you just rearranged their position in the stack. x86_64 will always be more annoying in this regard, it's not an ABI decision made with humans in mind at all. The assumption is (rightfully) that compilers are doing this work, and the perf win is significant.
Comments
I think so. It's nice to have more registers and all, but the consistency of an entirely stack-oriented calling convention is simply more elegant and ergonomic IMHO. The register passing overflowing into stack-oriented at some arbitrary limit is just hideously warty, and obnoxious if you're actually writing assembly with C ABI function calling.
Changing the signature of functions requires rearranging which registers are being populated, and if there's enough parameters some go in the stack, and if you've rearranged the order, now you're moving some from stack back to registers and visa versa. At least when everything was always going through the stack, you just rearranged their position in the stack. x86_64 will always be more annoying in this regard, it's not an ABI decision made with humans in mind at all. The assumption is (rightfully) that compilers are doing this work, and the perf win is significant.
Fair enough, you have a good point there