Dan Sugalski <[EMAIL PROTECTED]> wrote: > At 9:59 AM +0100 11/19/04, Leopold Toetsch wrote:
>>Its in and named C<returncc> since yesterday "return with current >>continuation". > Hrm. The name's not right, I've proposed ret_cc and returncc, about two weeks ago the first time. I've asked for names of the opcode. As no answer arrived I just used that name. > ... since there's no current continuation > involved. Well, "current" in the sense of context, not P1. So the comment is better: "return with continuation in context" or such. >> push_eh handler, label > Nope. The only thing that push_eh (or whatever we name it) needs is > the address of the code to jump to if an exception's thrown. The > exception pushing code should take care of building whatever > structure's needed to call into it. Ah, ok. That makes sense. >>Allowing just one additional object doesn't properly support Python, >>which has two optional expressions for the C<raise> statement and Python >>attaches a traceback object to the exception. > Hrm. Well, the traceback object could just be the interpreter > structure at the time of the the exception. That'd be cheap enough to > pass in. I'm fine with adding that as a second PMC parameter. I don't think that this works. The handler continuation restores the context, which changes the interpreter context. During unwinding the control stack we should probably fill a (preconstructed) array-ish object with pointers to contexts up to the handler conext. leo
