Sean O'Rourke <[EMAIL PROTECTED]> wrote: > Leopold Toetsch <[EMAIL PROTECTED]> writes:
>> A keyed "add" vtable doesn't help to provide more semantics. The set vs >> assign thread applies here too. On the contrary: to provide all >> semantics you would need "add_set_p_k_p_k_p_k" and "add_assign_p_k_p_k_p_k" >> and possibly "add_clone_p_k_p_k_p_k". > If I'm on target, what Dan's trying to avoid is having to create > magic proxy objects for autovivification. If this is all we want out > of keyed ops, then we can get it more cheaply by only adding keyed > variants for the _out_ parameters of each op. In one of my proposals I had something like this: key k1, P[] # add P[], P[], P[] key k2, P[] key_dest k3, P[] add k3, k1, k2 The source C<key> opcodes are basically like C<set> (albeit they could use a special key register (pointer), so no PRegs are globbered). The C<key_dest> does whatever is necessary to autovivify the LHS. This sequence is autogenerated inside the assembler (like imcc.y:multi_keyed()) now. JIT can emit only the vtable calls and have e.g. the pointers in processor registers. So JIT doesn't have any overhead, for CGP there are 3 additional jumps. There are no tests needed, if a key isn't present (the Ckey> instruction is omitted then). There is no overhead for e.g. overloading add - this would need code duplication if there is add_keyed. KISS. > /s leo
