[EMAIL PROTECTED] wrote:
I think we have basically 3 choices: support continuations such that they work correctly in all HLL situations and accept likely poor performance, or support only escape continuations, or devise a strategy whereby Parrot itself doesn't provide continuations, but allows them to exist at the HLL level somehow. I don't know of a way the third approach could work (though maybe someone has a clever idea), and the first two both carry significant down sides.
Actually these are only two approaches (as 'provide only escape continuations and let compilers fend for themselves' is same as 3rd approach).
Yes, it's possible to make the continuations efficient - Schemes have been doing this for a long time (note that possible != easy). In particular, Leo's variable-sized frames look like a workable solution to me and aren't intrusive at PIR level, are moderately intrusive at the VM implementation level, they do heavily impact things on assembly/bytecode level... and ought to be quite speedy. Modulo unforeseen problems *evil cackle*
Biting the bullet and just spilling a lot is also acceptable, or at least it looks like that for me. You get a constant factor penalty and it's not a huge constant factor, esp. if you have a bulk spill/reload opcode. Read Bill's posts about hammering the allocator into doing this - I wouldn't put the words in his mouth but from his posts this seems completely feasible. The architectural impact is low across the board (if Bill is right about being able to do this easily in the register allocator), and while slower (compared to variable frames), this doesn't seem too bad a solution.
A scheme that requires en-masse dropping of I and N registers and adding double-referenced P registers does not sound like a good idea to me. Performance-wise, it's no better (but is possibly worse) than refetching everything from lexicals after each function call - you simply refetch from the extra refs rather than the lexical pad, and you have to do it *every time* you access a variable, and you can't do bulk spill. VM implementation impact should be lower than the 2 solutions above, but every single code generator in existence will break, and if this is ever fixed, they'll have to be broken again.
It's also possible to provide continuations for specific languages only, for example by using trampoline. That's why you can implement Scheme on top of JVM. No, this doesn't interoperate with languages that don't use the trampoline, at least not bidirectionally. Considering that Parrot is primarily targetted for Perl6, this begs the question of whether Perl6 needs real continuations. So far, nothing I've seen in Apocalypses or Synopsi (Synopse? Synopses?) looked unimplementable without them - junctions are datatypes that affect function calls at call sites, not at their point of creation (since they can be introspected), the laziness is handlable by closures and coroutines can be handled specially - the way Python and Lua handle them. Still... continuations are a pretty neat toy to have. ;)
Miro
