All~ On 6/3/05, Bill Coffman <[EMAIL PROTECTED]> wrote: > > There are several threads in the parrot mailing list that discuss the > continuations problem. I hoped to be able to address parrot register > allocator again, at some point, but it could be a while before I get to > that. In the mean time, search the perl6-internals mailing list for > continuations and register allocation. I'm sure you'll find it.
I would actually very much like to see this issue moved on. In the hopes of getting everything up to speed quickly I will try and summarize all of the discussions and suggestions that have been made. I am NOT trying to advocate any particular solution (yet), I just want to make sure that everyone is on the same page. I propose that we use this thread to ensure that we are not talking past each other. Discussions about specific solutions should and religion should have a seperate thread. PROBLEM: Continuations can be invoked repeatedly. Whenever a continuation is reinvoked, the registers must be in a defined state or the code will behave incorrectly. BASIC ANALYSIS The actual state of the registers does not matter as long as it is well defined. A) If the registers are defined to be garbage, then every continuation will start by returning them to the state it expects. B) If the registers are defined to be preserved, then every continuation merrily chugs along. Unfortunately these each have issues and as such much debate ensued. SUGGESTED SOLUTIONS 1) Context includes registers + continuations don't have to preserve specifc registers + register allocator can ignore continuations wrt spilling - copying overheard - value based registers (IN) return to "old" values - pointer based registers (SP) cannot have their pointers moved or require double indirection 2) Return Continuations include registers, non don't + register allocator can remain mostly ignorant + only non return continuations need to worry - promoting a return continuation will force copying as plan (1) 3) register are not restored + simple to explain - register allocator must add many extra interference edges - largely prevents reuse of register 4) variable sized register frames + never have unused registers + no need for a register allocator + could correspond directly to scratchpad - more complicated - no register reuse - large architectural change - more custom allocation (can't pool register sets) I believe the official spec calls for (2); however, I do not believe that it is currently implemented. Once again in this thread please try to remain objective and just summarize/correct. We can start a new thread to hash out the minutia of pro's/con's and new ideas, I just want everyone to be on the same page. Matt -- "Computer Science is merely the post-Turing Decline of Formal Systems Theory." -???
