Leo~
On Tue, 30 Nov 2004 17:30:43 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote: > > > 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. Not necessarily, you only need to copy in the case where a return continuation was promoted. Thus, you can avoid copying for the common call/return case. Also, we could allow hints that indicate a point below which continuations do not need to be promoted (although this is an optimization). Also, it is not that broken. In fact it has identical semantics to the old save/restore ones. Recall that the restore would overwrite the I/N values with what they were at save time. Matt -- "Computer Science is merely the post-Turing Decline of Formal Systems Theory." -???
