One minute to twelve: last chance to fix D2 ABI?

[Robert Jacques]

On Wed, 03 Mar 2010 05:28:46 -0500, Lionello Lunesu  
<lio at 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.