Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Luke Palmer <[EMAIL PROTECTED]> 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)
>
> This doesn't help for flattening (splat) function call arguments:
>
> f([EMAIL PROTECTED], [EMAIL PROTECTED])
>
> repacking everything (at runtime!) into P3?
Yes. It seems to me that this is exactly what has to happen, at least
conceptually. Luke's point is clearest when considering how to
implement a Perl5-style sub with a variable number of arguments. If
args are passed in an array, they're all clustered together and easily
handled by a for-loop (or assembly equivalent). If they're passed in
registers, you have to have a huge, nasty switch statement at the
start of the function like so:
if $nargs == 0 goto done
# handle P5
if $nargs == 1 goto done
# handle P6
...
if $nargs == 10 goto done
# handle overflow
And that's just not pleasant.
> And what if the call is:
>
> f([EMAIL PROTECTED], $b, $c)
I'm not understanding your point here -- wouldn't this create an
array "[EMAIL PROTECTED]@a[n], $b, $c]" in P3, just like the above?
Steve -- As I see it, prototypes have two functions: (1) catching
wrong-arguments errors at compile time, and (2) (perhaps) allowing for
faster parameter passing. Since the second's really just an
optimization, I'd suggest skipping it for the time being, doing the
syntactic checking during compilation, but then passing everything in
P3. This also gives us a baseline against which to benchmark
prototyped passing. It's not clear to me a priori that it can be
reasonably used often enough to actually be faster.
/s
