object - interface compatibility

[BCS]

Pragma wrote:
> BCS wrote:
>> Actually I would like to see interface calling convention changed to 
>> use a fat pointer for interfaces. This would use a arbitrary context 
>> pointer welded to a pointer to a v-tbl. All sorts of cool things could 
>> be done with this.
>>
[...]
> 
> So then the interface method call turns into:
> 
> //inf.test(a, b, c);
> push c
> push b
> push a    // push args
> 
> mov obj -> r1    // load pointer to object
> mov vtbl -> r2    // load v-tbl (obj+vtbl = fat-pointer)
> push r1        // push "this"
> call r2[test]    // use v-tbl to call test
> 

More or less.

> So, this basically sacrifices stack space in favor of a few less opcodes 
> per interface-method call. :)
> 
> But doesn't this make cast() operations *longer* by one additional move 
> operation?  Are method calls really more numerous than casts?
> 

That is a problem, it doubles the size of an interface reference. I can 
see reasons why that would be bad. (BTW this doesn't attempt to solve 
the object-interface incompatibility.)

OTOH It may make objects smaller by one word for each interface they 
implement. I think that the v-tbl pointer for interfaces is part of the 
object, with the proposed system, it would be part of the objects v-tbl.

It all depends on what your looking for, this system is a bit bigger in 
one place, a bit smaller in another and provides a few new options for 
features.

> On the up-side, it would only make the ABI more consistent, since 
> delegates are pretty much doing the same thing when compared to their 
> function-pointer counterpart (as you already mentioned).  A higher 
> degree of consistency there, could buy us a higher degree of consistency 
> with D's constructs, cleaner code, and possibly more-bug-free compiler 
> implementations.
>