On Mon, 10 Nov 2003, Leopold Toetsch wrote:
> Dan Sugalski wrote:
>
> > Anyway, time to unify. The question, then, is what gets kept and what gets
> > tossed. The return spec says we pass in the number of P, I, S, and N
> > params we're returning, which is fine,
>
> I don't think we need these counts. If the call is prototyped, the
> caller knows the type and count of registers. If the function might
> return a varying amount of return values, depending, what the caller
> specified in I3, the runtime checks and register setup on both sides
> take by far more time, then what could be achived IMHO.
> When the call is unprototyped the count of P-Regs is enough.
I was thinking of the case where there are variable length returns for
N/I/S params. Which, arguably, ought to be there for calls too, to make
vararg stuff work properly. But since we're looking mainly to PMCs as our
primary datatype, I'm OK with tossing the I/N/S counts for returns.
> > We can toss some of the inbound stuff and make them optional properties on
> > the return continuation,
>
> I1 for call conventions is redundant, the overflow array P3 has the count.
Point. Gone.
> > ... which is where the return signature should live
> > as well (with the same property name as a sub or method's PMC signature)
>
> Prototyped returns with a signature as property seems too heavy to me.
Well... the prototype has to be somewhere so it can be queried at runtime.
The alternative is some sort of expected return prototype.
> But first I'd like to have some clarification. E.g. "compile-time
> prototype" vs unprototyped. Where and how do we have these prototypes?
> What happens if a library sub is called either prototyped or not e.g.
> from 2 different languages?
Prototypes are in there so the callee knows that the caller is using more
than just PMC registers. PMC counts are always there, since most of the
calls in real-world code will be just PMCs. It's not a prototype in the
general sense since it doesn't do much to indicate types beyond Parrot's
basic types -- it's certainly inadequate for HLL prototype management.
The reason to have them is compile-time uncertainty about call and return
types. Since we can't safely know with certainty what the definition of a
sub or method is, we need to pass into the sub/method a notation of what
parameters its getting. Otherwise we can run into the case where a sub is
expecting, say, three int and three string paramters but gets passed in
three num and one string parameter instead. While that's obviously an
error we'd like to have a chance for the callee to note that bad data has
been passed in and pitch an exception rather than, say, segfaulting
because the string register was NULL. (Which, arguably, is still
potentially a problem)
There's also the vararg issue -- I *really* hate having no metadata about
vararg parameters besides some crappy format string I have to parse or a
forced manual parameter count parameter. But there's a limit to how far
that annoyance will take me.
> Currently we are already spending about 1/3 of the fib[1] Benchmark in
> register setup for calling conventions. This doesn't take much time for
> JIT, but all other run cores have a severe runtime penalty. We should
> really try to reduce the needed register setup to a bare minimum.
I'll put together a proposed patch for PDD03 and post it to the list, and
we can hash it out. At the very least the PMC count will be in the same I
register for call and return...
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
