3 ms·

x86's purely stack-oriented C ABI calling convention makes things far less tedious. In x86_64 sure it executes faster with the register passing, but what a mis

x86's purely stack-oriented C ABI calling convention makes things far less tedious. In x86_64 sure it executes faster with the register passing, but what a miserable thing to read/write as a human. Maybe this is just a case of having learned and written 32-bit x86 assembler for years in my youth, but I strongly prefer it to x86_64.

_8j50 5y ago
But would you still prefer X32 if you started with X64? My argument is that some would not find it tediuous if that was the first thing they learned. Similar to how a python programmer would share your sentiment about C because he learned python first. I learned C first so while I accept that it is more verbose and more work in general, I enjoy writing C more.
- pengaru 5y ago
  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.
  - _8j50 5y ago
    Fair enough, you have a good point there
inkyoto 5y ago
C stack-oriented ABI calling conventions also started with PDP-11, for which the first portable C compiler was written, and the convention then tagged along to nearly every other architecture as the pcc was progressively ported to other platforms. If a function return value could fit into %r0 on the PDP-11 (%ax/%eax/%rax on x86), it would be returned in there. %r1-%r4 would be used to pass function parameters in, if they could fit, and/or spill over into the stack. Heck, even UNIX system call conventions on x86 can be traced back to PDP-11, i.e. the syscall number is passed in %r0 (%eax) followed by a TRAP (INT on x86) instruction (can't remember which TRAP number, though).

_8j50 5y ago

But would you still prefer X32 if you started with X64? My argument is that some would not find it tediuous if that was the first thing they learned. Similar to how a python programmer would share your sentiment about C because he learned python first. I learned C first so while I accept that it is more verbose and more work in general, I enjoy writing C more.

pengaru 5y ago
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.
- _8j50 5y ago
  Fair enough, you have a good point there

inkyoto 5y ago

C stack-oriented ABI calling conventions also started with PDP-11, for which the first portable C compiler was written, and the convention then tagged along to nearly every other architecture as the pcc was progressively ported to other platforms. If a function return value could fit into %r0 on the PDP-11 (%ax/%eax/%rax on x86), it would be returned in there. %r1-%r4 would be used to pass function parameters in, if they could fit, and/or spill over into the stack. Heck, even UNIX system call conventions on x86 can be traced back to PDP-11, i.e. the syscall number is passed in %r0 (%eax) followed by a TRAP (INT on x86) instruction (can't remember which TRAP number, though).