Multiple return values...
Timon Gehr
timon.gehr at gmx.ch
Sun Mar 11 15:48:53 PDT 2012
On 03/11/2012 10:57 PM, Robert Jacques wrote:
> On Sun, 11 Mar 2012 15:38:21 -0500, Timon Gehr <timon.gehr at gmx.ch> wrote:
>
>> On 03/11/2012 09:30 PM, Robert Jacques wrote:
>>> Manu, why are you assuming that the struct is returned in any sort of
>>> fixed memory layout?
>>
>> Because that is what the ABI says.
>>
>> * 1, 2 and 4 byte structs are returned in EAX.
>> * 8 byte structs are returned in EDX,EAX, where EDX gets the most
>> significant half.
>> * For other struct sizes, the return value is stored through a hidden
>> pointer passed as an argument to the function.
>
> You made my point. Manu is arguing that structs small enough to be worth
> passing in registers must maintain some sort of fixed memory layout;
They do.
> i.e. they can't broken up across a desperate set of registers.
>
That was not his point. If you have:
struct S{
float a;
float b;
}
S foo();
Then EDX and EAX contain float data upon function return. That is not
something you want.
>>> You can _not_ take the memory address, etc of a
>>> register so maintaining the layout of a struct is a) impossible and b)
>>> not necessary, if you're returning it via registers. The compiler is
>>> free to use XMM registers for floats/doubles and GPRs for pointers/ints.
>>> And there's no need for the caller to place those struct register values
>>> on the stack if they're never used. Furthermore, even on the stack, the
>>> struct's memory layout is only ever valid immediately before (and
>>> forever after due to pointer escapes) a non-inlined function call or
>>> address taking. At a low level, MRV is a structured set of value, ergo
>>> it's a struct.
>>
>> Multiple function arguments are a structured set of values too.
>
> And the call structure for multiple arguments is virtually identical for
> structs and multiple arguments. In fact, I've used this duality on
> various cross-language calls, defining arguments in one language and a
> struct in the other.
Wtf. Good luck porting that code to an architecture with a different
calling convention.
More information about the Digitalmars-d
mailing list