Re: CPS invoke return context
Dan Sugalski [EMAIL PROTECTED] writes: At 11:19 PM +0200 6/29/03, Leopold Toetsch wrote: Dan Sugalski wrote: ... I'd also like to be able to manipulate the stacks in a context, pushing things on them, changing values on them, and generally messing about with the things, so I'm all for it. Do you have some examples for a usage of such manipulations? I thought that a return continuations should exactly match the state of the caller, so that the Cupdatecc op would do the work. But there are for sure some hacks, that might need some: updatecc .stack .action item Yep, that could work. There are a few actual good reasons to do this: *) A subroutine may want to affect the warnings state of its caller *) A sub may want to add in block exit actions (though that's more an inspection for the block exit item on the caller's stack) *) It's possible the callee may want to mess around with an exception handler at an outer level, though that's probably a bad idea *) The callee may want to insert elements onto the control stack of the caller Not *very* good reasons, mind, but... :) Yeah, but at least one of 'em is required in Perl 6 (the 'affect the warnings state of the caller' thing) isn't it? -- Piers
Re: CPS invoke return context
At 2:43 PM +0200 6/28/03, Leopold Toetsch wrote: In the meantime interpreter-warns has moved to the context structure and gets now restored for CPS subroutine calls. But there is a slight problem (as well as with e.g. pad_stacks) When we have: warningson 1 newsub .Sub, .Continuation, _func, _ret ... invoke and _func turns warnings off, the warns are restored fine. When Cwarningson is after Cnewsub, the continuation has the old state of warns. So we should update the continuation context at Cinvoke time. Here are some possibilities to achieve this: - invokecc (this is slow) - a new opcode e.g. Cupdatecc (update continuation ctx) - toss invokecc's current functionality and use this opcode to update the context and call the sub. I like option 2. I'd also like to be able to manipulate the stacks in a context, pushing things on them, changing values on them, and generally messing about with the things, so I'm all for it. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: CPS invoke return context
Dan Sugalski wrote: [ update continuation PMC at call time ] Here are some possibilities to achieve this: - invokecc (this is slow) - a new opcode e.g. Cupdatecc (update continuation ctx) - toss invokecc's current functionality and use this opcode to update the context and call the sub. I like option 2. Fine. ... I'd also like to be able to manipulate the stacks in a context, pushing things on them, changing values on them, and generally messing about with the things, so I'm all for it. Do you have some examples for a usage of such manipulations? I thought that a return continuations should exactly match the state of the caller, so that the Cupdatecc op would do the work. But there are for sure some hacks, that might need some: updatecc .stack .action item leo
Re: CPS invoke return context
At 11:19 PM +0200 6/29/03, Leopold Toetsch wrote: Dan Sugalski wrote: ... I'd also like to be able to manipulate the stacks in a context, pushing things on them, changing values on them, and generally messing about with the things, so I'm all for it. Do you have some examples for a usage of such manipulations? I thought that a return continuations should exactly match the state of the caller, so that the Cupdatecc op would do the work. But there are for sure some hacks, that might need some: updatecc .stack .action item Yep, that could work. There are a few actual good reasons to do this: *) A subroutine may want to affect the warnings state of its caller *) A sub may want to add in block exit actions (though that's more an inspection for the block exit item on the caller's stack) *) It's possible the callee may want to mess around with an exception handler at an outer level, though that's probably a bad idea *) The callee may want to insert elements onto the control stack of the caller Not *very* good reasons, mind, but... :) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
CPS invoke return context
In the meantime interpreter-warns has moved to the context structure and gets now restored for CPS subroutine calls. But there is a slight problem (as well as with e.g. pad_stacks) When we have: warningson 1 newsub .Sub, .Continuation, _func, _ret ... invoke and _func turns warnings off, the warns are restored fine. When Cwarningson is after Cnewsub, the continuation has the old state of warns. So we should update the continuation context at Cinvoke time. Here are some possibilities to achieve this: - invokecc (this is slow) - a new opcode e.g. Cupdatecc (update continuation ctx) - toss invokecc's current functionality and use this opcode to update the context and call the sub. Comments welcome, leo
