Leopold Toetsch <[EMAIL PROTECTED]> writes: > Dan Sugalski wrote: > >> At 4:15 PM +0200 9/23/04, Leopold Toetsch wrote: >>> 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. > > That's fine too. > > >>> 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. > > Well, basically, if an interpreter template is used (hanging off the > subroutine), the previous interpreter template is the return > continuation. That means that for the usual case (function call and > return) there isn't any need to construct a return continuation and put > it somewhere. The return continuation would only be needed to create a > real continuation out of it and pass it along somewhere. > > If that calling scheme doesn't fly, its still better to have specific > locations in the interpreter context that hold the sub and the return > continuation to allow simple function backtrace for the error case or > introspection. That's currently not possible, because P0 and P1 can be > swapped out into the register backing stack and reused to hold something > totally different. > >> 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. > > Ok. Good point. We could get rid of C<invoke Px> (call the sub in Px w/o > calling conventions) in favor of C<invoke_with_retc Px>. Anyway, the > visible part of a return continuation (in above opcode or C<get_cc> > would be a continuation. The "normal" case (call/return) could just have > that continuation internally in the context. No additional PMC is > constructed ifn't needed.
I could be wrong here, but it seems to me that having a special 'tailinvoke' operator which simply reuses the current return continuation instead of creating a new one would make for rather faster tail calls than fetching the current continuation out of the interpreter structure, then invoking the target sub with with this new continuation (ISTM that doing it this way means you're going to end up doing a chunk of the work of creating a new return continuation anyway, which rather defeats the purpose.)
