On Wed, 24 Sep 2003, Luke Palmer wrote:

> Okay, considering that it's hard to pack registers into an array, and
> that it's easy to unpack an array into registers (in the context of
> signatures), why don't we make the unprototyped calling conventions just
> to pass everything in the overflow array?  (Hmm, I think I remember
> saying this before... sorry if I'm repeating myself)

Ah, repeat yourself and it's talk past each other week, huh? I'll join in.

No.

:)

The common case, the one we're targeting, is the case where a subroutine 
is called with only PMCs. Let's assume, for a moment, that we're passing 
in five parameters. In the unprototyped case, it is:

  I0 = 0
  I2 = 5
  P5 - P9 = parameters

In the prototyped case, the registers are:

  I0 = 1
  I2 = 5
  P5 - P9 = parameters

See the difference? Notice how *little* difference there is? (This isn't 
accidental)

Now, filling in those registers is less heavily weighted. Currently things 
are pretty evenly split between calling with a compile-time fixed list of 
PMCs, and a compile-time unsure list of PMCs. (The latter case is one with 
flattening arrays and/or hashes) 

In the fixed-list case, the compiler can map scalars to registers, and 
making the call is easy. and compile-time fixed. Either a bunch of get_lex 
Px, 'foo' (with the right parameter register for Px substituted) or some 
set Px, Py if the variables are already in registers. There may be some 
pushing onto an overflow array if we need it, if you've got a really big 
list.

In the variable list case things are messier, definitely. This requires a 
small chunk of code to decide which register things need to go in 
dynamically, with overflow on the overflow array. For this, I think we're 
going to need a "setp Ix, Py" op which does indirect register addressing. 
More ops than pushing onto an array, but I'm unconvinced it's more actual 
*work* than pushing onto an array.

Do note that perl 6 is working to discourage hash/array flattening, and 
python and ruby both don't do it (I think) so the weight goes to the 
compile-time-fixed list of parameters.

On the callee end, registers can be a pain if everything's in a single 
array like perl's @_, but since most perl code yanks things out of @_ 
immediately in a "my ($foo, $bar, $baz) = @_" sort of thing, that's not a 
problem. We're also moving towards specified and/or named parameters, 
which makes things easier as well, since we just map parameters to 
registers. (Things get messy-ish with more than 11 parameters, but that's 
pretty uncommon)

No solution's perfect, as there are too many conflicting cases. I think, 
however, that this solution's better and faster in the common cases, so it 
stands, thanks. Time to move on to the next bikeshed.

                                        Dan


Reply via email to