Okay, so it's time to get this taken care of.
Right now, the only true difference between a sub call and a return, at
least at the assembly level, is that we don't pass back a return
continuation when we're returning. You can, if you really want, even
arguably consider a sub PMC as a frozen semi-stateleless continuation.
(Not, mind, that I'd suggest it, as it'll make your brain hurt)
Anyway, call and return parameter lists are almost, but not quite, the
same. While that's not inherently bad, it seems pretty sub-optimal and
means two sets of parameter handling code, one for inbound call parms and
one for return parms. Seems silly, especially since they've got close to
identical semantics (since return params can be prototyped, as we can
return multiple values and may want to know what the assignment list for
the return is)
Anyway, time to unify. The question, then, is what gets kept and what gets
tossed. The return spec says we pass in the number of P, I, S, and N
params we're returning, which is fine, except we don't have enough
registers for that and the stuff we're passing in in I registers now. We
use all 5 when making a call. One overlaps with returns (The number of PMC
params) and that leaves us needing three ints.
We can toss some of the inbound stuff and make them optional properties on
the return continuation, which is where the return signature should live
as well (with the same property name as a sub or method's PMC signature)
which'd leave us needing two ints. I'm not sure if its worth trimming out
things from the registers to make space, or moving the two other counts to
N registers.
Oh, and we need to make sure the PMC count is in the same register for
calls as returns. It isn't now, which is a sloppy oversight and one we'll
fix as part of this.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
