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.)
