At 5:07 PM +0200 6/18/03, Leopold Toetsch wrote:2) performance of CPS sucks
Are you sure? Tell us what you *really* think... :)
Exactly that, what I've outlined. But, when its ok, to generate the Continuation outside of a possible loop, then its as fast as using the control stack (or faster ;-).
ad 1) I'd like to preserve the old style invoke/ret scheme too.
Sure, it's a useful thing. Only subs/methods/whatever that need to conform to the calling conventions absolutely must use PDD03 style calling conventions, though this *will* be all the Perl, Python, and Ruby subs, as well as any sub or method that can be called from them.
Then we barely need an invoke/ret functionality too, except for reparing P6C's closure tests.
sub.pmc (+ contsub.pmc), continuation.pmc, and coroutine.pmc do very
similar things. The only major difference is, where they branch on invoke.
We need to unify them. Each of them sort of dates to a different period so they're not quite matching. Yet. :)
So all these subroutine types should have probably this structure:
typedef struct Parrot_Sub {
struct Parrot_Context ctx;
opcode_t *address;
} * parrot_sub_t;On *construction* they would do:
all: save_context(); // like in new_continuation sub, coro: push_current_lexpad_on_own_ctx(); // like new_coroutine
On invoke they do: sub: copy ctx to interpreter = restore_ctx coroutine: swap_ctx continuation: restore_ctx
Is that correct?
leo
BTW I've added 2 new ops, which makes code using CPS much simpler.
