> -----Original Message----- > From: Peter Gibbs [mailto:[EMAIL PROTECTED]] >
[snip] > An interesting question, not discussed when the change was > initiated, relates to property assignments eg > new P0, .PerlArray > set P0, 6 > This most certainly does not set register P0 to six, so the 'set' > opcode should not apply, but it is also not really an assignment > either. Any thoughts? there is a similar problem with subs new P0, .Sub set P0, <some label> I guess the problem is that set is being used for too much? This is the way I thought things were headed: set_x_x just moves a pointer or a value, possibly needing a cast, copy or conversion $1 = $2; $1 = string_from_num($2); etc While assign_p_x calls the appropriate vtable method $1->vtable->set_pmc(interpreter, $1, $2); $1->vtable->set_integer_native(interpreter, $1, $2); etc The above .Sub and .PerlArray examples could be handled with op new(out PMC, in INT, in PMC) op new(out PMC, in INT, in INT) etc instead of the set op. I think this separation could be more clear, but I suppose this leaves some cases out. So maybe a set_property op? Though some things could be left to _methods_ instead of ops. -- Jonathan Sillito > > The primary goal of the exercise was to be able to distinguish > between 'set P0, P1' which simply sets the P0 register equal to > the P1 register, and 'assign P0, P1' which would, somehow, > cause the existing PMC referenced by P0 to acquire the value > of the PMC referenced by P1 (via the vtable method set_pmc). > How to achieve this has never been resolved. The changes of > the other 'set P0, xxx' opcodes to 'assign' are basically for > consistency. > -- > Peter Gibbs > EmKel Systems >
