I've started tweaking internals to get a faster calling scheme in place. Part 1 (in CVS) moved the subroutine's address into the parrot_sub_t structure. Accessing such Sub-internals via get_pointer & set_pointer is working still safely.
Anyway, next will be to hide the return continuation in the interpreter context. So we need to have some opcodes to access the return continuation, e.g.:
get_cc(OUT Px) # 1) get current continuation, i.e. the return cont.
In a rare, possibly unique burts of opcode parsimoniousness... perhaps this would be a good thing for the interpinfo op. It returns current interpreter info, and the current return continuation would be a good one to do, as would the current object and current sub/method PMC. (As well as the current namespace root, current lexical pad root...)
return_cc() # 2) return via current continuation
1) is only needed for special porposes, like passing the continuation on to a different place. The normal way to return from a sub will be 2)
If that's in, access to C<P1> as a return continuation will be deprecated.
Well... should we? We're still passing the return continuation *in* in P1, unless you want to move it out and unconditionally make it a parameter to invoke. Which is OK, but we should be up front.
The PIR sequence:
.pcc_begin_return .return foo .pcc_end_return
will do the right thing accordingly.
I think I'd also like to make a change to sub invocation, too, to allow passing in alternate return continuations, which makes tail calls easy. At this point I'm not inclined to have any special tail call support built into parrot because it's just not needed, but IMCC support is still handy.
A .returncont arg to the long-form sub call would work fine. If we want to have a variant short-form to support it that'd be fine.
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
