Dan~
On Tue, 30 Nov 2004 10:22:29 -0500, 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 -- 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) So continuations, as such, don't > make any difference here. A return is a return, and if it works right > the first time it should work right all the times. > > 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. > > N.B. that this is an issue that only affects the PIR register > allocator -- I'm not seeing a case where this can be an issue for > anything else, including plain assembly. If I'm missing something > this would be a good time to point out the missing bits. That makes sense to me (and in fact matches what I have been failing to articulate for a while now), thanks for the clarification. Matt -- "Computer Science is merely the post-Turing Decline of Formal Systems Theory." -???
