-----Original Message----- From: Leopold Toetsch [mailto:[EMAIL PROTECTED] 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
Extending the C<new> opcode or doing a new one isn't much difference. Thinking in imcc POV and register allocation I'd prefer a distinct opcode.
invokecc .SomeContinuationClass # assumes expr NEXT()
Still this one doesn't work - or yes works but only with additional overhead: invoke and such are called on a specific PMCs invoke() method. So I don't see any need to pay an additional penalty for a) an additional parameter (opcode) and b) some "if" inside the invoke() to decide what todo according to that param. This should just be a different class that implements a possibly slightly different invoke().
And performance and consistency are the main concerns, correct? Following are some ideas that may address theses.
Yep exactly.
WRT performance: Constructing the return continuation solves this - thats totally ok, albeit, and this was one questions, I don't know, if its totally equivalent to construct the return continuation at C<invoke> time or where "newsub" is called.
Issues regarding current inconsistencies remain:
E.g. with this scheme a coroutine or continuation may return and restore different items from "context" what the caller did preserve.
(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
Thats all ok. But I think, we currently need some background, what is really "some context" that is and shall preserved:
Intstack? Register backing store? User stack? And if when one of these and why ...
This are just my current concerns.
(2) Could the Parrot_Context struct be reworked such that the register
stacks are only one pointer each?
The primary questions is what to preserve (and restore) when.
(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 ...
Yes. This could be fine. OTOH, when "context" comes out as being just the lexical pad, that's one pointer. Dunno.
Jonathan Sillito
leo
