[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