All the vtable operations that do PMC things are three-arg versions--they get both the args and the destination PMCs passed in. This is done specifically for speed reasons, as the assumption is that, for example, the add vtable method for a PMC represents the expression:
a = b + c
turns to
add a, b, c
in which case b's add function does the math and hand the result to a via it's set vtable function, which is fine. A has the option of overriding the assignment if that's necessary, for example if its tied to a backing store of some sort. Fine. The addition may create a temporary PMC, but there's really no way around that if we're to maintain the proper API.
This becomes a bit less efficient when we're looking at intermediate values of expressions. Something like:
a = b + c + d
turns to
new $P0, SomeIntermediateType add $P0, b, c add a, $P0, d
and we need to create that $P0 temp beforehand. While that's fine, it leave things to the compiler to figure out what the intermediate type should be, and often ends up creating two temps instead of one. Moreover, it's distinctly possible that the temp that's created isn't the right type, as the compiler may not know what the intermediate expression will return.
I see three options:
1) Have a version of the binary vtable methods that create the destination PMC
2) Make a universal assignment PMC that takes on the characteristics of the RHS of the assignment
3) Have a "this PMC intentionally left blank" flag to mark blank PMCs and have vtable methods check that first
#1 doubles the number of vtable entries. Ick.
#2 has the most overhead
#3 leaves it to the vtable methods to check, which is error prone. (Though if the #2 and #3 schemes were implemented with the same PMC there'd be a good fallback)
Discussion time, folks. Pointing out things I've missed wouldn't be out of line either...
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
