Calling conventions:
I0  Prototyped call?
I1  Number of overflow params
I2  Number of params in PMC registers
P3  Overflow params

Return conventions:
I0  Prototyped return?
I1  Number of return values in integer registers
I2  Number of return values in string registers
I3  Number of return values in PMC registers
I4  Number of return values in numeric registers
P3  Overflow return values in an array PMC

I'm wondering why the conventions for calling
and returning aren't more symmetrical...
Why doesn't a return use I1 and I2 the same
as a call does? Especially with CPS, where
calls and returns seem almost interchangable
(you could do tricks involving passing subroutines
in P1 and pretending they were return continuations),
I think it would be better if calls and returns
used the same conventions. The existing (assuming
the return conventions in the PDD are up to date)
return conventions don't really make much sense,
anyway; if a return is non-prototyped, you'll
have to stick all the return values in P registers,
and won't use the others. So why use I1,2,and 4 like
that? I would prefer to see this:

I0  Prototyped return?
I1  Number of overflow return values
I2  Number of return values in PMC registers
P3  Overflow return values in an array PMC

so as to make call/return symmetrical
(this would also allow me to use the same
Params class in my compiler for both
calls and returns ;-)

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

Provided that we have a way to attach signature information to a PMC
(which would be pretty nice, I suspect), then the signature of P1 is the
context of the call.  And now we don't have to pass in context
information seperately.

And if you feel like fooling with continuations; i.e. putting somebody
else's return continuation in P1, the context will work out correctly
there, too.

Actually, attaching dynamic signature information to various kinds of
.Subs seems to have a lot of advantages.  It makes cross-language
calling easier, because the caller has an idea about what the callee
wants.  For instance:

    my &pysub := get_some_python_sub();
    for @a, &pysub;

Would take appropriate chunks of @a, depending on how many parameters
&pysub wanted.  Or &pysub could be from any language, maybe not even
known by the program, and this would still work correctly.

Of course, there may be some big issues that I'm missing.

Luke

Dan?

leo

Every PMC has a 'get_signature' method.
You can use this to get the signature of the object
so that you can make a prototyped call on it.
Now, there are at least 2 special signatures that I
can think of:

* Uhh... I don't really have a signature. Just
  pass in whatever you want (basically an
  unprototyped call)
* Go away! I'm not invokable! Please don't
  invoke me!

The caller can feel free to ignore the signature,
however, and simply call the sub in the
unprototyped fasion. The callee could then
(if it felt like it) call a make_params_prototyped
op, which would change the un-prototyped parameters
into prototyped parameters using the callee's
signature. It could also raise an exception
if it had the wrong number of parameters or
something.

BTW,
If there is no way to get a sub's signature, then
how would you implement named parameters on an
unprototyped sub?

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com