Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> wrote: > And I show my ignorance yet again. I really need to do some serious > research into how things have changed...
> Leopold Toetsch wrote: >> It could work, if the sequence is: >> >> $P0 = $P1 + $P2 >> null $P3 >> $P3 = $P0 + $P4 >> >> The C<null (out PMC)> opcode cuts the life range of C<$P3> because of >> its C<out> specifier. > Hmmm...that might work. >> But now we have the runtime overhead in each such vtable method (test >> for PMCNULL) and one additional function argument to pass. > I don't see the additional argument--dest is already being passed to the > vtable methods. There's a new return value, but no new argument. There > is also a branch on dest == PMCNULL, which is rather suboptimal. Yep. > What if, by calling PMCNULL's set_(integer|string|float|pmc) vtable > methods, you actually allocate a new PMC of the appropriate type? In > other words, for null: > PMC* set_integer_native(INTVAL value) { > PMC* ret=pmc_new(INTERP, some_integer_type); /* Er... */ > VTABLE_set_integer_native(INTERP, ret, value); > return ret; > } Well that seems to boil down to move the problem from PerlUndef to PMCNULL. What is the approprate type? HLL should know it. It's getting worse IMHO. A PerlInt/PerlNum ... knows how to morph a destination PerlUndef to the appropriate type. So should a Python scalar. Moving this to PMCNULL for *all* different HLL scalars isn't really good. leo