call and return conventions
Togos
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
Luke Palmer
> 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 ;-)
This is brilliant! And it's not because you can re-use your Params
class. It's because call context falls right out of the calling
conventions.
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
Leopold Toetsch
> 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
Makes a lot of sense. When the return is prototyped the current info in
I1 ... I4 isn't needed. For unprototyped returns its unused.
Dan?
leo
Togos
wrote:
Tee-hee! I didn't even think of that, but yes,
that's very clever. I'll throw my thoughts about
how signatures could work on the table...
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?