Got Warnocked, I think. I'm partway through partitioning the vtable up to make overriding vtables on a per-PMC basis less expensive. I'm pretty sure that most of the keyed variants will end up being used, but we may end up pruning a bunch of these out.
The _keyed math, logical and binary ops are history. As mentioned several times, I don't see any chance to implement them without having about 64 times the opcount we have now.
This doesn't mean, that we never support multi keyed ops:
$ cat 3key.imc
new P0, .PerlArray
new P1, .PerlArray
new P2, .PerlArray
set I0, 0
set I1, 100000
loop:
set P1[I0], I0
set P2[I0], I0
add P0[I0], P1[I0], P2[I0]
inc I0
lt I0, I1, loop
...
$ parrot -o- 3key.imc
new P0, 22
new P1, 22
new P2, 22
set I0, 0
set I1, 100000
loop:
set P1[I0], I0
set P2[I0], I0
set P18, P1[I0]
set P17, P2[I0]
new P16, 27 # .PerlUndef
add P16, P18, P17
set P0[I0], P16
inc I0
lt I0, I1, loop
...
This code can for sure be improved, also the semantics of the LHS (new, assign) has to be defined, but that problem has the original code too.
WRT _same opcodes: I finally found a usage for some of these, when fixing the assign Px, Px vtables ;-) But I still can't imagine any usage besides the set_<type>_same variants.
leo
