Dan Sugalski <[EMAIL PROTECTED]> wrote: > At 9:15 PM +0100 11/23/04, Leopold Toetsch wrote: >>Below inline/attached are some thoughts WRT the subject. >> >>leo >> >> >>Lexicals, continuations, and register allocation >> >>1) Recent discussions have shown that we obviously can't handle all >>the side effects of continuations correctly. Reusing preserved >>(non-volatile) registers after a call isn't possible any more, due to >>loops in the CFG a continuation might create.
> I admit, I've been watching the discussion and I just don't > understand why there's a problem. > So far as I can tell there are two cases here: > 1) A return continuation > 2) A regular continuation > We've already established that a return continuation preserves the > top half of the registers (though I think that's not been clear) so > there's just no problem there -- That term "preserves" needs some more clarification. Some months ago we used the "savetop" / "restoretop" opcodes. They made a copy of half of the register frame and restored it on return. The caller and the subroutine did executed in the registers inside the interpreter structure. We decided to give up this scheme in favour of the indirect register addressing. Now we have a new register frame, where a subroutine is executing. Returning from the subroutine returns to the other register frame, which of course means that the registers are preserved, because the subroutine executed in a freshly allocated and of course different register frame. > ... at the point a return continuation > returns, [IPSN]16-31 will be as they were when the return > continuation was created. Which, in practice, makes the I and N > registers useless for variables like loop counters, though fine for > constants (both real and effective) Huh? You are now back with register copying? With the additional "benefit" that we can't use integer loop counters anymore? Sorry, I can't believe that you are proposing such a broken usage of (return) continuations. > N.B. that this is an issue that only affects the PIR register > allocator Yes. That is what we are discussing since weeks. >>There are two proposed, accepted but undesirable work arounds: >>a) don't reuse registers - drawback spilling >>b) refetch all from lexicals - drawback execution time > Before I comment on this one, I want to double-check -- you're > proposing tossing the pads and going with a variable-sized register > frame, yes? Yes. The data storage of one pad nesting is one register frame. The lexicals in the top pad are reachable directly as registers. Lexicals in outer pads still need fetching by the fetch_lex opcode. R0..R15 are used as now, R16 .. Rn are preserved registers and lexicals. This scheme BTW supports also Perl6 natural types as lexicals. leo
