> -----Original Message----- > From: Leopold Toetsch [mailto:[EMAIL PROTECTED] > > Jonathan Sillito wrote: > > >>-----Original Message----- > >>From: Leopold Toetsch [mailto:[EMAIL PROTECTED] > >> > >>The patch is fine with two exceptions: > >>1) still breaks existing P6C tests WRT exceptions & rules > > > You didn't mention this point. It might be only a small change in P6C > code, I didn't look at (4 tests are failing now due to invoke changes).
Sorry I haven't looked at this yet. > >>2) performance of CPS sucks > > > This is the reason for the new implementation of the invoke op > which assumes > > that the continuation has already been put in place. > > > Ok then we need a new opcode: > > newsub Px, .Class, jump_or_ret_addr Sounds fine to me. At one point the following worked: new Px, .Class, address > This constructs a sub or continuation type subroutine PMC in Px of class > .Class and the referenced label - in one instruction. > > > Also allowing the > > invokecc to take an argument specifying the type of > continuation to save may > > be helpful: > > > No, don't think so. The type is specified by the PMC class. The invoke > of this class takes the appropriate action. I agree that constructing the continuation separately is functionally equivalent: new P1 .SomeContinuationClass, label # or newsub invoke label: # return's to here however I think a common case is made more convenient using: invokecc .SomeContinuationClass # assumes expr NEXT() # return's to here though, either way is fine with me. > >>2b) There is still too much context copying going on AFAIK. The register > >>top and base pointers are copied too in {save,restore}context worth of 8 > >>words, while just copying the 3 stacks (pad, control, user) should more > >>then be enough. The coroutine code only swaps these - BTW and doesn't > >>set them COW. > > > I am not sure I follow this. Are you suggesting that the > register stacks do > > not need to be copied? Again different types of continuations > would be good. > > > I honestly don't know, what has to be copied. I just know that all now > do copy different things and if CPS is involved also restore different > things. Please look at sub/continuation/coroutine and their context > saving: all are different. I guess this needs some reworking see below. [snip] > Still a lot (almost all) of my original concerns are not addressed yet. And performance and consistency are the main concerns, correct? Following are some ideas that may address theses. (1) A continuation is an invokable pmc that contains some context and an address to jump to. The context can vary and I suggest that we provide several continuation types to support this. I think the following may make sense (ordered from fastest to slowest). - no context (just an address) - just the pad stack - three stacks (pad, control and user) - three stacks plus register stacks I suppose other variations could be added as well. I am not sure what names to give each of these, but probably the "no context" pmc could be the base extended by the others. (2) Could the Parrot_Context struct be reworked such that the register stacks are only one pointer each? This would make the save and restore slightly more efficient. (3) One other efficiency thought: I wonder if the interpreter's context could be changed to a pointer to struct Parrot_Context? This would make accessing the stacks slightly slower but would of course make restoring the context very quick. Just a thought ... What do you think? -- Jonathan Sillito