Question about x86 delegate calling convention

[BCS]

Frits van Bommel wrote:
> Lionello Lunesu wrote:
> 
>> "Walter Bright" <newshound at digitalmars.com> wrote in message 
>> news:e82j04$28fs$1 at digitaldaemon.com...
>>
>>> It's just an artifact of the register allocator. The context pointer 
>>> is passed in EAX.
>>
>>
>> While on the subject, why can't a function pointer be (implicitly) 
>> converted to a delegate pointer? The context can just be ignored int 
>> that case so it'll probably be slightly less performant, but it's 
>> handy: a library could use delegates for all callbacks, without 
>> forcing the users to use either classes or nested functions. They can 
>> still use globals if they'd want.
> 
> 
> Ok, so Walter beat me to posting the obvious reason. This was my reply, 
> all typed up:
> 
> 
> The calling convention for extern(D) functions (the default) is to pass 
> one of the arguments (the last one) in EAX[1] if it fits, so it's not 
> ignored. It's used for something else.
> 
> I believe Walter once said it was a feature he wanted to eventually 
> implement though. I think he was even considering converting delegates 
> to function pointers, by having it call dynamically generated code.
> 
> If you don't mind using asm hacks, you could construct your delegates 
> using an asm stub like below as the code to call. (the function pointer 
> is stored as the context pointer)
> 
[a lot of cool code...]

Couldn't the compiler generate the needed stub(s) for you? With that 
functionality, a function to delegate cast could be allowed.