All, As with most technical problems, fully specifying them, is often half the battle. In this case, I think we're getting close to understanding the issues at least.
[please treat all statements as possible questions] First, consider my original post in this thread: http://www.nntp.perl.org/group/perl.perl6.internals/27383 To summarize: Full continuations are powerful but expensive. They are like hidden goto's and add arcs to the control flow graph. This causes more registers to interfere. Proposed Solutions: - Accept the arcs and probable spilling. We still have the regions between sub calls. - Put labels on certain subs that denote they might call or be called by a continuation. - Pragmas indicating ranges where continuations won't be called (or will be). - Restore registers from lexicals somewhere, after each function call. - Accept incorrectness, as the current implementation does (discovered when new allocator failed 2 tests, and Leo saw the problem). Next, consider Dan's message, "Lexicals, continuations, and register allocation": On Tue, 30 Nov 2004 10:22:29 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote: > So far as I can tell there are two cases here: > > 1) A return continuation > > 2) A regular continuation > [snip return contuations, which are far from solved, but likely a subset of the below] > > The second case, where code takes an arbitrary continuation that > returns to location X, wherever X is. I'm missing the problem there, > too. Assuming there's a way to note the destination to the register > allocator (with those points being places where all registers must be > assumed to be trash) I'm not seeing the problem either. There are > only two cases here, where the destination is marked and where it > isn't. If it's marked, the register allocator assumes things are > dirty and loads everything, which is fine. If it's unmarked, the code > has essentially shot itself and everything quietly goes to hell since > you've lied to the register allocator and you shouldn't do that. > Which is fine too. Don't Do That. If I read the above correctly, Dan is advocating the strongest restriction of all, which is to specify any arcs that might be added. That is, specify all sub_i -> sub_j, where "->" means that a continuation saved in sub_j is invoked by sub_i. To reclassify the reasonable solutions: 1a. Concentrate on restoring registers after calling -- probably using the lexicals. 1b. Possibly increase the size of the register set, and/or try to use lexicals or globals (I think of this as a kind of improved spilling).. 2a. Insert all the arcs into the CFG, which will increase spilling, but 2b. Reduce the number of arcs in the CFG, by introducing various annotations on subs indicating when they do or do not save or invoke a continuation. Especially target library functions. Currently, I'm trying to work on 2a right now, but my day job is making that tough lately. Would like to see more attention payed to 2b, by those who care about the issue. In particular I'd like to see HLL designers say, "Yeah, 2b looks like a great idea!", and maybe a few, "yeah, let's specifically implement the following..." Then, there are additional problems to contend with... On Wed, 1 Dec 2004 09:49:34 -0800, Jeff Clites <[EMAIL PROTECTED]> wrote: > But so it sounds like I and N registers are a bit of a waste then, no? > They won't really be used. Even in your "my int @foo" case, you could > have an optimized backing store for the array, but you'd have to > on-the-fly create a PMC to hold any values you pulled out of the array, > e.g. for a subsequent "x = @foo[1]" (in Perl6 syntax)--x would have to > hold a full PMC there, it seems, so nothing there would end up in an I > register (except as in intermediate in immediately creating the PMC). [snippage of examples] If I understand right, PerlArray's would be used for "my int @foo". If you want to use these values, you have to copy back and forth from I* registers, for the most part. The ISN registers can be used in the nether regions, between sub calls (even the lower half of the registers can be used there). Subs which are garanteed not to call or save continuations are safe (see 2b above), and ISN registers can be used while crossing those. However, we now know that only P registers can cross unsafe subs, unless ... well, there's probably certain cases where ISN's can be used. That question would take more thought. My sense is that we want to support continuations, but we don't want to be crushed under the heavy load. Perhaps we can adapt the policy that if one is brazen enough to use full continuations, then s/he should be expected to at least inform the compiler about it. Bill
