[KinoSearch] Towards a stable C API... via indirect dispatch

Marvin Humphrey marvin at rectangular.com
Tue Oct 30 10:50:55 PDT 2007




On Oct 29, 2007, at 12:32 PM, Marvin Humphrey wrote:

> On Oct 29, 2007, at 11:52 AM, Nathan Kurz wrote:
>
>> My preference would be for using whatever is simpler and clearer to
>> read, so long as it compiles without warning on our target systems  
>> and
>> is not unreasonably ineffecient.
>
> Using a explicit struct is definitely clearer than the other  
> stratagem, which basically amounts to creating a struct and then  
> pretending that it's an array some of the time.
>
> The extra add op is almost certainly insignificant.  Let's just  
> keep the vtables as structs.

As I've been coding this up, I've refined my position.

The method_OFFSET var should hold the distance, in *bytes*, from the  
top of the vtable struct.  To get the address of the proper function  
pointer, just add method_OFFSET and the address of the vtable together.

This is the assembler we should see when attempting to load the  
correct function pointer:

     movl    self, %edx          # load self into %edx
     movl    method_OFFSET, %eax # load method_OFFSET into %eax
     addl    (%edx), %eax        # add the address of self->_ to %eax

Here's an example method macro definition to produce that assembler:

   #define Kino_Term_Destroy(self) \
       ((kino_Obj_destroy_t)((char*)(self)->_) +  
Kino_Term_Destroy_OFFSET)((kino_Obj*)self)

Note that in order for that to compile, "self" must have a member  
named "_" -- so you can't just throw any old variable into a method  
macro.

The vtable member for each object remains a struct.

     struct kino_Obj {
         kino_VTable     *_;
         chy_u32_t        refcount;
     };

VTables are always treated as structs, except when they are treated  
as raw memory addresses within method macros.

Marvin Humphrey
Rectangular Research
http://www.rectangular.com/



_______________________________________________
KinoSearch mailing list
KinoSearch at rectangular.com
http://www.rectangular.com/mailman/listinfo/kinosearch




More information about the kinosearch mailing list