On Sep-15, Dan Sugalski wrote:
> On Sun, 14 Sep 2003, Steve Fink wrote:
>
> > But that's really just shifting the burden to the receiving end, which
> > will now have to filter P5..P(5+L1-1), P3[0..] into the appropriate
> > local variables. So what would be even easier, and probably just as
> > fast, would be to say that unprototyped functions pass *all* of their
> > arguments through the overflow array.
>
> I considered that. The standard is set up for two common cases:
>
> 1) The function is prototyped as taking a list of PMCs, with 10 or fewer
> named parameters passed in
>
> 2) The function is unprototyped but can be found, by static code
> inspection, to be taking 10 or fewer named parameters.
And by "named parameters", you mean "unnamed aka positional
parameters"? Perl6's named parameters are another story.
> In this case, the scheme, while a pain on the calling end, makes the
> callee end very simple--the parameters map directly to registers. If
> you've a declaration:
>
> sub foo($bar, $baz) {
> }
>
> or
>
> sub foo {
> my ($bar, $baz) = @_;
> }
>
> two common perl idioms, then the compiler can map $bar to P5 and $baz to
> P6 directly, without having to do anything. Since the majority of the subs
> and/or methods behave like this--taking a small number of parameters, it's
> a win on the callee end.
Hmm... I can buy that argument. Of course, if people start using a lot
of basic-typed parameters, then it may not be that common, but my
guess is that you've hit the 90% case. Unfortunately, it's only 10% of
the cases that must be implemented in a compiler...
> Yes, this does mean that dealing with splatted arrays and hashes is a
> bigger pain than it ought otherwise to be, but that's supposed to be (and
> generally is now) an uncommon occurrence. That doesn't mean we can't give
> engine support to it, however--adding in an op that took a parameter array
> in P3 and took the first few items out and loaded them into P5-P15 in one
> go (and a corresponding version that respected the calling conventions and
> took the elements out of P5-15 and put them onto the beginning of the
> array in P3, or any other P we might want)
There are several possible ways of doing this, some more general than
others. Okay, so I'll assume we'll get some solution to this. What
should the PIR look like?
Would could have a '.args PMC' directive to go along with '.arg REG'.
'.args' would mean to concatenate the aggregate PMC onto the argument
list.
f($a, [EMAIL PROTECTED], $c) ->
.arg _SV_a
.args _AV_b
.arg _SV_c
The callee side would then need to have a way of saying "...and all
the rest". So that would be
.params PythonArray foo
Then how should it construct foo? Using the magic new operator, of
course, but does that operator push the elements one at a time? Should
array PMCs have a method for copying batches of PMCs into them?
('append' works fine for P3, and I'd like that for some other Perl6
stuff anyway, but how to grab out a contiguous subset of the register
file?)
Or should the type of P3 and a receiving .params variable be
more constrained?
Hey, we could have a RegistersDuctTapedToArray PMC that could
represent a chunk of the register file plus at least one array PMC.
That would make it fun to track register usage.
