On Wed, 03 Mar 2010 05:28:46 -0500, Lionello Lunesu
<[email protected]> 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.
