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.
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;
}And then for an integer type:
PMC* add(PMC* value, PMC* dest) {
/* A bunch of fancy logic that boils down to... */
return VTABLE_set_integer_native(INTERP, dest,
VTABLE_get_integer(INTERP, SELF) +
VTABLE_get_integer(INTERP, value)
);
}Any other type's set_integer_native would be like:
PMC* set_integer_native(INTVAL value) {
PMC_int_val(SELF)=value;
return SELF;
}(Plus or minus morphing code.)
The big problem is some_integer_type. I'm not really sure what to do about that.
-- Brent "Dax" Royal-Gordon <[EMAIL PROTECTED]> Perl and Parrot hacker
Oceania has always been at war with Eastasia.
