On Fri, 12 Oct 2001, Dan Sugalski wrote:
> At 01:30 PM 10/12/2001 -0400, Michael Maraist wrote:
> >I'm of the opinion that you shouldn't just be able to jump into
> >another code-segment.
>
> [Snip]
>
> >And thus be prevented from changing context; That would be relegated
> >to a subroutine invocation (especially since such subroutines can be
> >dynamically modified).
>
> Ummm... what do you think we're using to call into subroutines? Or just do
> global control-flow changes?
True, even a supposed callCV or gotoCV would have to return something valid.
My current impression of the direction was to utilize callCV in a
manner similar to "exception handling", which the last time I heard
would look something like this:
ne I1,I2, good
setException ...
end
good:
It stood to reason that callCV could do the same thing. Considering
for a moment that the direction isn't completely different, the way I
see this is as:
// usage:
// callCV P5
// end
// fooOP // utilized on return
AUTO_OP callCV_p {
PMC cv = PMC_REG(P1);
if ( !isCV(cv) ) {
EXCEPTION(.)
RETURN // auto-next-op, which is end (handles exception)
}
// excluded in gotoCV
push( interp->return_stack, code + CUR_OP_SIZE + END_OP_SIZE );
if ( isCVInCurContext(cv, interp) ) {
// set up local return value
RETURN(getPCFromCV(cv)); // jump
} else {
interp->next_pc = getPCFromCV(cv);
// further setup return value
RETURN // auto-next-op, which is end, (does an inter-module jump)
}
}
The advantage is that any context/scope cached values in the do-loop can be
flushed on a context-switch. To minimize the overhead (of a c-call)
we optimize for intra-context calls; what-ever that might entail; I'm
guessing intra-module calls.
Well, right off the bat, I admit that this method is paradoxical,
since PMC->op is from a vtable, separate from op-codes. Such a vtable
function handler can't just call into the op-code-table, so things get
more complex anyway. None the less, this is the basic idea I had in mind.
-Michael
