On Sep-23, Leopold Toetsch wrote: > Steve Fink <[EMAIL PROTECTED]> wrote: > > > Just to be sure we're talking about the same thing: > > > sub f ($a, $b, $c) { ... } > > $x = phase_of_moon('waxing') ? \&f : \&CORE::print; > > $x->(3, [EMAIL PROTECTED], [EMAIL PROTECTED]); > > I don't expect such contrived functions calls happen too often, but > anyway ... > > > i.e., I'm calling f() without a prototype. > > > A builtin that took three parameters would expect them in P5, P6, and > > P7. But how do I do that in IMCC for $x->(3, [EMAIL PROTECTED], [EMAIL > > PROTECTED])? I am > > suggesting > > > .arg 3 > > .args _AV_x > > .args _AV_y > > > with some deep magic going on under the hood to get them into the > > correct registers, most probably by means of a new, specialized op > > because the current way of doing it is ugly and slow. > > The current way is to flatten @x and @y and pass the 2 lists, that's it. > That is you pass (3, _AV_x[0], ... _AV_x[i], _AV_y[0], ...).
Ok, we don't seem to be communicating. I am not talking about optimizations. I am talking about what is possible. Currently, there is no way to do what you suggest with the PCC support in IMCC. At compile-time, you do not know the value of i (the length of @x), so there is no sequence of .arg statements that work. Unless I am badly misunderstanding things? I am under the impression that the neither the .arg nor the .param directive may be mixed in with regular instructions, so you cannot loop over the elements of an array to flatten it. > I'm not against a specialized ".args" directive, but first, we need the > "normal" cases. Then, we can think of optimizations. I proposed .args simply because it seemed easier to implement than runtime .arg directives. Would you prefer that the call be done like this?: .pcc_begin non_prototyped .arg 3 $I0 = 0 $I1 = _AV_x _arg_loop: if $I2 >= $I0 goto _next_arg_1 .arg _AV_x[$I0] $I0 = $I0 + 1 goto _arg_loop _next_arg_1: . . . But in either case, please understand that I am asking for _a_ way of doing this in IMCC; I don't care how slow it is, so long as it's possible. If I am incorrect about that, and it *is* already possible, please show me a code example. > Another question: E6 seems to indicate that splat flattening happens > before parameter binding: > > ,--[ E6 ]----------------------------------------------------------------- > | This operator (known as "splat") simply flattens its argument into a > | list. Since it's a unary operator, it does that flattening before the > | arguments are bound to their respective parameters. > `------------------------------------------------------------------------- > > Before is of course not a definition, when the flattening should happen, > but it seems to indicate, that flattening is done in the caller. > > And can the flattening have side effects? What about tied arrary > splats? I can imagine, that the called sub can't flatten the array > because of tieing. Huh? If you're talking about f([EMAIL PROTECTED]), then the called sub cannot flatten because it doesn't know whether it should or not. (Unless you pass some magic extra parameter to all non-prototyped calls that says which arguments to flatten, but that makes no sense.) If you're talking about sub foo ([EMAIL PROTECTED]) { ... } foo(@x); then it still makes no sense to flatten in the called sub, because you could have just as easily called foo(1, 2, @x, @y, 3, 4), and so the caller would have to bundle all of the args up in order to give the callee something to flatten. (And the bundling would require the flattening of @x and @y anyway, so you'll have to have caller-flattening semantics no matter what.)