> >destination register. Why would we *ever* care what's in the destination
> >register, since it never gets it's vtable methods called.
>
> That's not true. The destination needs its set method called.
> Otherwise tying/overloading won't work right.

Fair enough. I still have the problem brought up in the email that started
this thread, however. I'll reiterate it, and a possibly better solution,
in the email below.

Let me ask how '$a = $b + $c' is supposed to work. Currently, we have an
'add' vtable method, which has self, value, and dest. $a=dest, $b=self,
and $c=value. So right now, we never call set, and we transmogrify the
destination register PMC directly.

So perhaps we should assume that the dest register is a dummy one.
We transmogrify and initialize it however we want, in add. Then we
use a seperate opcode to store it into the destination register,
with set.

This means the above code becomes:
fetchlex P0, "$b"
fetchlex P1, "$c"
new P2, DummyPMC
add P2, P0, P1
fetchlex P3, "$a"
set P3, P2

Now $b's vtable gets called to add, an $a's vtable gets called to set,
supporting tied vars and whatnot. This also means that "$a = $a + $a"
never modifies itself in the same op. (which was the problem in the
example I gave in the email that started this thread), so that the rhs is
valid when performing the computation, and once the result is completed,
it's then able to store into the lhs and overwrite $a. This requires we
create a constraint that one cannot have any of the source registers equal
the destination register.

If, however, the the below code...
fetchlex P0, "$a"
fetchlex P1, "$a"
fetchlex P2, "$a"
add P2, P0, P1

....is supposed to work fine, we have two problems:
1) we transmogrify the destination register before we can set it, which
means we have to store the result of the add in a temp variable. Lots of
methods violate this. (See original email for more clarification on this.)
2) We can't dispatch based upon destination type *and* first-add-argument
type with a single op. We already ruled out multi-dispatch.. ;)

Mike Lambert

Reply via email to