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