> -----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
