Juergen Boemmels wrote:
Leopold Toetsch <[EMAIL PROTECTED]> writes:Is there any compelling reason, why the {get,set}_<type>_keyed_int vtable methods are defined to take a KEY* value instead of a plain INTVAL value?IIRC, to support operations like add P0[7], P1, P2[0]
We can't do these multi_keyed ops in that way. They would need ~64 times the opcodes we currently have. Please read my RFC WRT multi_keyed ops.
There is already a hook in imcc to do these multi_keyed ops in a different way - but this is really not tested.
I still prefer a special B<key> opcode, which does keyed argument fetch and store.
With a 64K op code count all code locality and cache coherency would be history and performance would really suck.
without the need of 8 diffrent vtable entries,
The vtable entries are really not the primary problem - or at least not until now, where we only have statically allocated vtables. When objects emerge, this might as well be a problem. But I dunno, if the vtable slots may be changed or if a lookup is done.
bye boe.
