Tomas has done a lot of work on D ABI compatibility for LDC during the last weeks. He's come quite far: except for the passing of some parameters in EAX, things seem to work fine.

One point we couldn't understand though, is the reversal of parameters when calling some D functions: Parameters are usually passed right-to-left, except for nonvariadic D functions, where the order changes to left-to-right.

What is the reason for it?


If this was not so, and D functions would always pass parameters right-to-left, it'd be very easy to call a member or nested function given the type and address only: the context would just always go first in the parameter list (and hence be passed last, possibly in EAX). As it is, you have to put the context in as the last argument - except for variadics, where it can go first again.

As a somewhat related, but separate issue, this would open the door to real easy pointer-to-members. Given

class C {
  void foo(int i) { ... }
}

you could have

typeof(C.foo) == void function(C, int)

and

auto memberfn = &C.foo;
memberfn(new C, 42);

would work too.

On Tue, Oct 28, 2008 at 12:28 PM, Christian Kamm <kamm-incasoftware@removethis.de> wrote:
> Tomas has done a lot of work on D ABI compatibility for LDC during the last weeks. He's come quite far: except for the passing of some parameters in EAX, things seem to work fine.
>
> One point we couldn't understand though, is the reversal of parameters when calling some D functions: Parameters are usually passed right-to-left, except for nonvariadic D functions, where the order changes to left-to-right.
>
> What is the reason for it?
>
>
> If this was not so, and D functions would always pass parameters right-to-left, it'd be very easy to call a member or nested function given the type and address only: the context would just always go first in the parameter list (and hence be passed last, possibly in EAX). As it is, you have to put the context in as the last argument - except for variadics, where it can go first again.
>
> As a somewhat related, but separate issue, this would open the door to real easy pointer-to-members. Given
>
> class C {
>  void foo(int i) { ... }
> }
>
> you could have
>
> typeof(C.foo) == void function(C, int)
>
> and
>
> auto memberfn = &C.foo;
> memberfn(new C, 42);
>
> would work too.
>
>

All of these things would make me happy.  :)

Christian Kamm wrote:
> One point we couldn't understand though, is the reversal of parameters when
> calling some D functions: Parameters are usually passed right-to-left,
> except for nonvariadic D functions, where the order changes to
> left-to-right. 
> 
> What is the reason for it?

The reason is because I'd eventually like to specify the order of evaluation of function arguments as being left to right. So, for normal D functions, this makes for optimal code generation. The only time monkey business would have to happen would be to support the C calling convention or the variadic one.

Walter Bright wrote:
> Christian Kamm wrote:
>> One point we couldn't understand though, is the reversal of parameters when
>> calling some D functions: Parameters are usually passed right-to-left,
>> except for nonvariadic D functions, where the order changes to
>> left-to-right.
>> What is the reason for it?
> 
> The reason is because I'd eventually like to specify the order of evaluation of function arguments as being left to right. So, for normal D functions, this makes for optimal code generation. The only time monkey business would have to happen would be to support the C calling convention or the variadic one.

What do you think of the "proposal"?, I think it could be quite valuable and the current setup makes has some odd behaviour.

Take the TypeInfo_Struct.xopCmp for example. Here a member function pointer is assigned to a static function pointer, the result being that you have to call it with parameters reversed for things to work as you expect, but only when x86 ABI is in effect.

Walter Bright Wrote:

> Christian Kamm wrote:
> > One point we couldn't understand though, is the reversal of parameters when calling some D functions: Parameters are usually passed right-to-left, except for nonvariadic D functions, where the order changes to left-to-right.
> > 
> > What is the reason for it?
> 
> The reason is because I'd eventually like to specify the order of evaluation of function arguments as being left to right. So, for normal D functions, this makes for optimal code generation. The only time monkey business would have to happen would be to support the C calling convention or the variadic one.

It's sounding like right-to-left makes more sense than left-to-right.  As an English speaker, left-to-right seems more natural, but I see no reason to require it.  Beyond that, do we really want to require an evaluation order of arguments?  I'd much prefer for the compiler to work its optimization magic than have a set order anyway.

Jason House wrote:
> It's sounding like right-to-left makes more sense than left-to-right.
> As an English speaker, left-to-right seems more natural, but I see no
> reason to require it.  Beyond that, do we really want to require an
> evaluation order of arguments?  I'd much prefer for the compiler to
> work its optimization magic than have a set order anyway.

People intuitively expect expressions to be evaluated left-to-right, and that applies to function arguments, too.

Eliminating implementation defined behavior makes the source code much more portable. There is no way to reliably detect inadvertent order-of-evaluation dependencies.

> As a somewhat related, but separate issue, this would open the door to real
> easy pointer-to-members. Given
>
> class C {
>  void foo(int i) { ... }
> }
>
> you could have
>
> typeof(C.foo) == void function(C, int)
>
> and
>
> auto memberfn = &C.foo;
> memberfn(new C, 42);
>
> would work too.

Is it possible to solve this problem and also solve the problem mentioned in the thread "implicitly convert function pointers to delegates"? Or are these two mutually exclusive?

L. 

> Is it possible to solve this problem and also solve the problem mentioned in the thread "implicitly convert function pointers to delegates"? Or are these two mutually exclusive?

The two things are separate. Delegates are functions that have the context argument bound. This is about the passing order of arguments.

> Christian Kamm wrote:
>> One point we couldn't understand though, is the reversal of parameters when calling some D functions: Parameters are usually passed right-to-left, except for nonvariadic D functions, where the order changes to left-to-right.
>> 
>> What is the reason for it?

Walter Bright wrote:
> The reason is because I'd eventually like to specify the order of evaluation of function arguments as being left to right. So, for normal D functions, this makes for optimal code generation. The only time monkey business would have to happen would be to support the C calling convention or the variadic one.

What about generally passing left-to-right for D functions then?

If

foo(a1,...,an) was passed as
(this), a1, ..., an, (_arguments), (hidden)

with the first parameter in EAX if possible, we'd have the neatness
of "member function pointers have context as first arg" and the possibility
of specifying left-to-right evaluation order easily. We'd lose the ability
to pass hidden in EAX though.

Christian Kamm wrote:
> with the first parameter in EAX if possible, we'd have the neatness
> of "member function pointers have context as first arg" and the possibility
> of specifying left-to-right evaluation order easily. We'd lose the ability
> to pass hidden in EAX though.

EAX always gets the last argument evaluated, because evaluating an expression often naturally winds up in EAX.