simple ABI change to enable implicit conversion of functions to delegates?

ag0aep6g via Digitalmars-d digitalmars-d at puremagic.com
Mon May 15 13:14:49 PDT 2017


On 05/15/2017 09:34 PM, Jonathan Marler wrote:
> Ah ok, you're proposing that the language guarantees that functions with
> the same "visible" parameters as delegates use the same ABI for those
> parameters.

Yup.

[...]
> The drawback I can see is that it restricts the ABI that functions can
> use.  Say that our x86 ABI passes all context pointers using the EAX
> register (no matter what the other parameters are).  That would imply
> that function's couldn't use the EAX register to accept arguments.  Note
> that this would apply to ALL functions, not just the ones that are going
> to be called through delegates, which is a small subset of ALL
> functions.  An interesting idea but IMO it seems like an odd restriction
> to put on all functions.

What's "our ABI" here? The one we come up with, or one that we have to 
follow for some reason?

If we have to follow an ABI where all context pointers or `this`s are 
passed in a specific register, then that's a problem, yes. As far as the 
spec goes, it says that D follows the C conventions of the system. As C 
doesn't have method/delegate functionality, I think we're free to put 
our hidden parameters wherever we want.

`extern(C++)` and such is different story. I'd just not allow implicit 
conversion for those functions.

If "our ABI" is the one we come up with, then using a fixed register for 
the context pointer is not what I'm going for. My approach is to assign 
the visible arguments first, then pass the context pointer in whatever 
spot is left.

Say, the function ABI uses EAX, EBX, and ECX for the first three 
arguments (in that order). For a function call `f(1, 2)` that means:

     EAX: 1
     EBX: 2
     ECX: not used

For a delegate call `dg(1, 2)` I'd also put 1 and 2 into EAX and EBX. 
Additionally, the context pointer would be passed in ECX.

Calls to normal functions are supposed to stay as they are. Only 
method/delegate calls should be affected.


More information about the Digitalmars-d mailing list