Re: Lexicals, continuations, and register allocation

[Dan Sugalski]

At 5:30 PM +0100 11/30/04, Leopold Toetsch 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.
No, we didn't. We mandated that call/return preserved the top 16 
registers of all the types automatically. That's *all* we did. The 
rest is implementation detail.

 > ... 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?
No. I'm still on register preserving, which is where we started. 
Quoth PDD 03 (which, I'll note, you agreed with)

      The return continuation PMC type, used to create return
      continuations used for call/return style programming, guarantees
      that registers 16-31 for all types (P, N, S, and I) will be set
      such that the contents of those registers are identical to the
      content of the registers when the return continuation was
      I<created>.
It's pretty clear, I think.
 > N.B. that this is an issue that only affects the PIR register
 allocator
Yes. That is what we are discussing since weeks.
Just checking. The answer is "no" of course, but you knew that when 
you started this discussion. Architecture changes aren't an option 
we're entertaining until after we're functionally complete. *That*, 
I'm quite sure, I was clear on.
--
				Dan

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