I'm getting a little confused about what we're arguing about. I will
take a stab at describing the playing field, so people can correct me
where I'm wrong:
Nonprototyped functions: these are simpler. The only point of
contention here is whether args should be passed in P5..P15,
overflowing into P3; or just everything in P3. Dan has stated at least
once that he much prefers the P5..P15, and there hasn't been much
disagreement, so I'll assume that that's the way it'll be.
Prototyped functions: there are a range of possibilities.
1. Everything gets PMC-ized and passed in P3. (Oops, I wasn't going
to mention this. I did because Joe Wilson seemed to be proposing
this.) No arg counts.
2. Everything gets PMC-ized and passed in P5..P15+P3. Ix is an arg
count for the number of args passed in P5..P15. P3 is empty if
argcount <= 11 (so you have to completely fill P5..P15 before
putting stuff in P3.)
3. Same as above, but you can start overflowing into P3 whenever you
want. Mentioned for completeness. Not gonna happen.
In fact, anything above this point ain't gonna happen.
4. PMCs get passed in P5..P15+P3, ints get passed in I5..I15+P3, etc.
Ix is a total argument count (number of non-overflowed PMC args +
number of non-overflowed int args + ...). Arguments are always
ordered, so it is unambiguous which ones were omitted in a varargs
situation. I think this is what Leo is arguing for.
5. PMCs get passed in P5..P15+P3, ints get passed in I5..I15+P3, etc.
Ix is the number of non-overflowed PMC args, Iy is the number of
non-overflowed int args, etc. I think this is what Dan is arguing
for.
6. PMCs get passed in Px..P15+P3, ints get passed in I5..I15+P4, etc.
Ix is the number of non-overflowed PMC args, Iy is the number of
non-overflowed int args, etc. I made this one up; see below.
Given that all different types of arguments get overflowed into the
same array (P3) in #4 and #5, #4 makes some sense -- if you want to
separate out the types, then perhaps it should be done consistently
with both argument counts _and_ overflow arrays. That's what #6 would
be. Note that it burns a lot of PMC registers.
The other question is how much high-level argument passing stuff (eg,
default values) should be crammed in. The argument against is that it
will bloat the interface and slow down calling. The argument for is
that it increases the amount of shared semantics between Parrot-hosted
languages. An example of how default values could be wedged in is to
say that any PMC parameter can be passed a Null PMC, which is the
signal to use the default value (which would need to be computed in
the callee, remember), or die loudly if the parameter is required.
Supporting optional integer, numeric, or string parameters would be
trickier. Or disallowed.
Hopefully I got all that right.
