Scott Moore wrote:
Frank Heckenbach wrote:
Scott Moore wrote:
The ABIs in existance for AMD64 are:
- The ABI as published by AMD.
- The ABI advanced by Microsoft for Windows.
Linux has adapted the AMD ABI. The Microsoft ABI does not match it. They went their own way (surprise).
Both ABIs are C oriented, if that matters.
The AMD ABI states that int is 32 bits, but this makes no difference to the ABI, since each register parameter occupies a full 64 bit register. On the stack, all parameters are specified as aligned to 64 bits, which means that assuming int as 64 bit would make no practical difference there, either.
The net difference of int vs. long is in structures, where int takes only 32 bits. I don't really consider that a calling convention matter, since you can declare record elements as subranges (or whatever).
I don't understand the last part. If a parameter is of record type, and the caller doesn't follow the ABI (e.g., has int 64 bits), it won't work. So it is a calling convention matter.
Whats passed is a pointer (to the record/struct). The layout of a record in memory can, and should be, directly specified. In C by specific types, in Pascal with subranges.
We're moving in circles. Again, Pascal subranges do not specify the memory layout.
Yes, in C by specific types, therefore types sizes must match, so a compiler with different sizes than the ABI will break in such cases. That's what I was saying. So we agree?
I believe the (practical) result is both existing ABIs are int length agnostic. If I missed something, my apologies.
Besides the previous issue, it's only on little-endian machines that 32 and 64 bit integers can (sometimes) be interchanged on the stack. Another problem is if the caller puts a 32 bit value on the stack and the callee expects a 64 bit one, the upper 32 bits are undefined.
On Intel, the standard way to achieve aligned stack pushes is to push the dword/qword register.
But not the only way. A compiler can (and I think gcc does sometimes) decrement the stack pointer (or keep it decremented from a previous call) and move values directly to the stack slots. Of course, one could force them to zero-extend (sign-extend?).
That's basically saying that all parameters promote to (at least) 64 bits. This will avoid many of the type size problems, but not all.
Frank