At 9:50 AM +0200 6/8/02, Jerome Vouillon wrote:
>On Sat, Jun 08, 2002 at 01:15:48AM -0400, Dan Sugalski wrote:
>> First, we need to beef up ret, but that's a problem of definition. It
>> should walk the control stack until it hits something it can return,
>> so we can undo exception handler pushes, scope change, and suchlike
>> things. (My problem, I'll update the docs)
>
>Why does ret need to be so smart? We can have an opcode that pop
>exception handlers (we need it anyway) and a ret that just return. If
>this turn out later to be a performance bottleneck, it will always be
>possible to optimize this by adding an opcode that performs both.
There's more than just exception handlers going on the control stack.
Anything that needs rolling back or undoing (like localized variables
or scope entry) will have an undo marker put on the control stack
that gets called when we pop its entry off the control stack. It's an
easy way to remember overwritten values--you put an "overwritten"
entry on the control stack with the old value, and we restore it when
we pop the entry off the stack.
> > Second, in the final go, the callco op won't be needed--call should
>> be sufficient, but that'll need support in the PMCs.
>
>Alternatively, I think you can just replace the definition of yield
>by:
>
> inline op yield (in INT) {
> struct Parrot_Sub * sub =
> (struct Parrot_Sub*)interpreter->pmc_reg.registers[0]->data;
> sub->init = OFFSET($1);
> stack_pop(interpreter, interpreter->control_stack,
> &dest, STACK_ENTRY_DESTINATION);
> goto ADDRESS(dest);
> }
Bit too simplistic there--we need to potentially return data from the
yield, the stacks need to have their current positions remembered,
the caller's stacks need to be restored (I think--we might be able to
cheat with this one a bit), and the rest of the register sets need
remembering for later resumption.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
