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
