[my last 2 f'ups didn't arrive at perl.perl6.internals, so I try again]
The patch is fine with two exceptions: 1) still breaks existing P6C tests WRT exceptions & rules
Yeah, that needs fixing.
2) performance of CPS sucks
Are you sure? Tell us what you *really* think... :)
ad 1) I'd like to preserve the old style invoke/ret scheme too. incokecc and friends could call a new ContSub[1] class, which is the same as sub.pmc but doesn't put the return address on the control stack during invoke.
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.
ad 2) CPS subroutines are 3 times slower for calling the sub. There are 2 problems here:
2a) The main is: the continuation object is generated for each[2] subroutine call. Replacing the invokecc with an explicit sequence of constructing the return Continuation object once outside the loop brings again the same speed as invoke/ret.
That's definitely doable. A continuation object, once created, should probably be considered immutable, though there are definitely things to be gained from being able to mess around with the stacks hanging off the continuation object.
Reusing these things should be considered OK, though they couldn't be reused without being reinitialized after any sort of stack manipulation on return, since COW will make pointers change.
I am fully, 100% OK with the interpreter core having evil deep knowledge of continuation PMCs, and unmercifully stuffing data into them directly. We don't have to jump through the continuation vtable or anything. Not that this will necessarily
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 tossed the base pointers entirely--they're flat-out wrong in most cases, so they're gone. Unfortunately a few more things, like the opcode table pointer and global pointer, needs to move into the context structure, so I think it'll ultimately have more things in it.
So we have currently:
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. :)
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
