At 12:30 PM 10/18/2001 +0100, Simon Cozens wrote:
>On Mon, Oct 08, 2001 at 06:36:32PM -0400, Dan Sugalski wrote:
> >     P1->vtable_funcs[VTABLE_ADD + P2->num_type](P1, P2, P0);
>
>Uhm, since num_type and vtable_funcs are part of the vtable
>structure, that would be more like
>      P1->vtable->vtable_funcs[VTABLE_ADD + P2->vtable->num_type](P1, P2, P0);
>
>After preprocessing, this looks like the wonderful:
>
> 
>interpreter->pmc_reg->registers[cur_opcode[2]]->vtable->vtable_funcs[VTABLE_ADD 
>+ 
>interpreter->pmc_reg->registers[cur_opcode[3]]->vtable->num_type](interpreter->pmc_reg->registers[cur_opcode[2]],interpreter->pmc_reg->registers[cur_opcode[3]],interpreter->pmc_reg->registers[cur_opcode[1]]);
>
>That's quite a shitload of dereferences in order to call a function
>(call a function, mark you, not actually do anything!) to add two
>things together.

Gack, that is nasty. Okay, let's see how this runs. (Or limps, as the case 
may be) A lot of that (like the interpreter->pmc_reg->registers bit) will 
get optimized to a single temporary by the compiler so it might not hurt 
much at all. There are a few tricks possible, like moving the register file 
into the interpreter structure or the num/int/string types into the main 
PMC struct, that we can pull to get rid of some of those dereferences. 
Which ones are worth it compared to the costs they incur will depend on 
whether shifting the costs are worth it.

                                        Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
[EMAIL PROTECTED]                         have teddy bears and even
                                      teddy bears get drunk

Reply via email to