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.

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?
--
Dan


--------------------------------------it's like this-------------------
Dan Sugalski                          even samurai
[EMAIL PROTECTED]                         have teddy bears and even
                                      teddy bears get drunk

Reply via email to