On Wed, 03 Mar 2010 01:38:58 -0500, Robert Jacques wrote:

> On Wed, 03 Mar 2010 01:00:46 -0500, Steve Teale <steve.teale@britseyeview.com> wrote:
>>
>>> * Binding a delegate to a function pointer will always need a (dynamic) thunk, because the function will have been invoked without any context pointer and it's the thunk's responsibility to assign the correct context pointer.
>>
>> At present, D's way of handling delegates requires patching GCC for the GDC implementation. If an ABI change was made it would be nice if it fitted into the GCC trampoline model.
>>
>> Steve
> 
> Um, how exactly? I just read the wikipedia page on GCC trampoline and it a) targeted only at nested functions b) utilizes self-modifying code which is disabled on any sensible platform c) would require dynamic allocation and d) actually uses more memory than D's method. Some time ago there was a link to an excellent article (by Walter? Don?) on different ways to do this. I remember d's way coming out the best, but I've seemed to have lost the link.

I'm just quoting from something I noticed a couple of days ago. In David Friedman's make file for GDC there is:

# Enables correct implementation of delegates. This requires patching GCC. D_EXTRA_DEFINES += -DD_NO_TRAMPOLINES=1

Steve

On Wed, 03 Mar 2010 05:28:46 -0500, Lionello Lunesu <lio@lunesu.remove.com> wrote:
> On 3-3-2010 10:49, Robert Jacques wrote:
>> On Tue, 02 Mar 2010 21:02:51 -0500, Lionello Lunesu
[snip]
>> Except this also effects member functions, nested functions, etc.
>
> Well, yes. That doesn't make it any harder or less possible.

It greatly increases the scope of the change, which does increase the implementation difficulty.

[snip]
>> This breaks the synergy of returns in EAX and params in EAX.
>
> How exactly? I don't understand. What does the return value have to do
> with any of this?

The ABI has been designed so that there is a synergy between the return value of a function (EAX) and where the last parameter to the next function is (also EAX). This allows function chaining to occur without mucking with register moves, etc.

>> It would be fairly easy for D (or anyone else) to implicitly define a
>> simple adapter that stores the function pointer in the delegate's this
>> pointer. The adapter function pointer points to one of two common stub
>> functions which either calls the this pointer or pops a value off the
>> stack into EAX and then calls the this pointer.
>
> It is easy. Like I should, you could just enter a pair of {} and it
> would work. And to prevent context capturing (and heap allocation) you
> could use such an adapter function. But without changing the ABI, even
> in the best case you would have a wrapper function with an extra call
> operation, which simply should not be necessary.
>
> L.

At the cost of forcing every single member function call to do an additional stack push? DMD doesn't pass args in ECX and EDX for a reason. Adapting free functions to delegates is a rare enough operation that making everything else slower to save one function call isn't worth it.

On Wed, 03 Mar 2010 10:34:48 -0500, Steve Teale <steve.teale@britseyeview.com> wrote:

> On Wed, 03 Mar 2010 01:38:58 -0500, Robert Jacques wrote:
>
>> On Wed, 03 Mar 2010 01:00:46 -0500, Steve Teale
>> <steve.teale@britseyeview.com> wrote:
>>>
>>>> * Binding a delegate to a function pointer will always need a
>>>> (dynamic) thunk, because the function will have been invoked without
>>>> any context pointer and it's the thunk's responsibility to assign the
>>>> correct context pointer.
>>>
>>> At present, D's way of handling delegates requires patching GCC for the
>>> GDC implementation. If an ABI change was made it would be nice if it
>>> fitted into the GCC trampoline model.
>>>
>>> Steve
>>
>> Um, how exactly? I just read the wikipedia page on GCC trampoline and it
>> a) targeted only at nested functions b) utilizes self-modifying code
>> which is disabled on any sensible platform c) would require dynamic
>> allocation and d) actually uses more memory than D's method. Some time
>> ago there was a link to an excellent article (by Walter? Don?) on
>> different ways to do this. I remember d's way coming out the best, but
>> I've seemed to have lost the link.
>
> I'm just quoting from something I noticed a couple of days ago. In David
> Friedman's make file for GDC there is:
>
> # Enables correct implementation of delegates. This requires patching GCC.
> D_EXTRA_DEFINES += -DD_NO_TRAMPOLINES=1
>
> Steve

I think that's because GCC's internal nested function AST construct would normally use trampolines, but D defines them as delegates (IIRC). As this hack is around GCC's AST handling and not D's ABI, it would be required regardless. BTW nested function support is a language extension specific to GCC.

On 3-3-2010 23:51, Robert Jacques wrote:
> At the cost of forcing every single member function call to do an additional stack push? DMD doesn't pass args in ECX and EDX for a reason. Adapting free functions to delegates is a rare enough operation that making everything else slower to save one function call isn't worth it.

That's a great point. I hadn't thought about it. Thanks.

L.

On Thu, 04 Mar 2010 05:00:46 -0500, Lionello Lunesu <lio@lunesu.remove.com> wrote:

> On 3-3-2010 23:51, Robert Jacques wrote:
>> At the cost of forcing every single member function call to do an
>> additional stack push? DMD doesn't pass args in ECX and EDX for a
>> reason. Adapting free functions to delegates is a rare enough operation
>> that making everything else slower to save one function call isn't worth
>> it.
>
> That's a great point. I hadn't thought about it. Thanks.
>
> L.

No problem. I'd never have thought about it and think it through without you raising your point. The really odd thing is that 2-word structs are returned in register, but not sent in registers. Maybe this will change in x86.