Juergen Boemmels wrote:
Leopold Toetsch <[EMAIL PROTECTED]> writes:
No, take the "new px, .PerlUndef" out of the opcode, it must only be done once. This temporary Px can be reused by _all_ _keyed ops.
Im not sure about this. This really depends on the fact if the
op does something depending on the type of LHS.
My timing test was done with the "new px, .PerlUndef" out of the loop, and worked after some tweaking of the array_set_pmc_keyed_int.
... If it doesn't need any
information about this type then even the "new px, .PerlUndef" is not
really needed (This is just an artefact of the fact that the
vtable-functions are called with value of the register instead of the
register).
We will see, what Dan's plans WRT variable/value vtable's will look like.
... But if the context-information is needed then the right
context must be provided. If this context evalutation is done in the
vtable function then its up to the PMC-implementation to decide if
its needed.
The LHS of an add_keyed may exist or not. Extending a PerlArray creates a PerlUndef anyway. So the LHS is not concerned. The questions is already, how to set the value of the LHS.
If we would change the signature of the vtable function to
add (PMC *, PMC *, PMC **lhs) and the call in the op to $2->vtable->add($2,$3,&$1), then the new is not need.
Yes, that's similar to my current hack.
... The signature of the add op could also be changed to add (out PMC, in PMC, in PMC)
If the add creates a new PMC holding the value (or the value is changed directly), yes. I think this is similar to set vs assign.
b.
leo
