> Luke said: > > > > sub ($param1, [EMAIL PROTECTED]) > > > > In which case, if it's prototyped, we stuff > > everything besides the > > first parameter into a PMC representing > > @otherparams. > > > > And if you meant something else, can't help ya. > > > > Luke > > Maybe I misunderstand what 'prototyped' means. I > assume this means that the caller knows exactly what > function it is calling, and so knows that how the > callee expects its parameters to be organised (one in > P5, the rest in an array in P6 or whatever). If you > don't know exactly what function you're calling (like > you got a Sub object out of a variable) then you have > to do a non_prototyped call on it. > > now, assuming I got that right: > > Are you saying that it will be impossible to implement > variable-length parameter lists to non-prototyped > functions? Because that's kind of essential to at > least a few languages. Ruby's 'print' function, for > instance, has a signature that looks something like > this: > > print(*stuff_to_print) > > Now, you take that method and pass it out to someone, > and they want to call it. How are they to know that > they're supposed to shove the parameters into an > array? Now, if you *always* put all the parameters > into an array for non_prototyped subs, this wouldn't > be a problem.
Ahh, you're talking about unprototyped calls. Misunderstood you there. Sure that will be possible. You put the first 11 args in P5-P15, and the rest in P4. You tell the sub that there are I2 parameters in the registers, and I1 parameters in P4. And the reasoning behind this, I think, is that for many subs, interpreting prototyped and non-prototyped calls will need no distinction: the same code can be used for both. At first I was a little uneasy about using PMC registers for parameter passing, lest the bookkeeping code should get in the way of efficiency (of both code generation and the generated code itself). But, I realized that this bookkeeping code would probably be there even if we used an array, and registers are likely to be faster. Plus, parameters to functions are likely to be used in the code of the function (and likewise with return values), so we're just skipping unloading the array into registers. > But otherwise you can't host Ruby. And I *know* you > don't plan to miss out on that, so obviously I'm > missing something :-) Meh. :-) Luke
