develooper Front page | perl.perl6.internals | Postings from November 2004

Re: Continuations, basic blocks, loops and register allocation

Thread Previous | Thread Next
From:
Matt Fowles
Date:
November 16, 2004 10:03
Subject:
Re: Continuations, basic blocks, loops and register allocation
Message ID:
f2601a7f04111610031fc30899@mail.gmail.com
Dan~


On Tue, 16 Nov 2004 12:29:19 -0500, Dan Sugalski <dan@sidhe.org> wrote:
> At 11:52 AM -0500 11/16/04, Matt Fowles wrote:
> 
> 
> >Leo~
> >
> >On Tue, 16 Nov 2004 16:37:04 +0100, Leopold Toetsch <lt@toetsch.at> wrote:
> >>
> >>
> >>  Matt Fowles <ubermatt@gmail.com> wrote:
> >>  > Leo~
> >>
> >>  > On Tue, 16 Nov 2004 09:23:24 +0100, Leopold Toetsch <lt@toetsch.at> wrote:
> >>
> >>  >>     i = 0
> >>  >>   lp:
> >>  >>     foo()
> >>  >>     inc i
> >>  >>     if i < 10 goto lp
> >>
> >>  > There is one thing I am not sure about here.  The loop will work
> >>  > correctly for each seperate invocation of the appropriate
> >>  > continuation.
> >>
> >>  No. Imagine, foo() is not a simple function anymore. Someone e.g. Jens
> >>  Rieks[1], discovers that the algoritm is simpler implemented with
> >>  continuations. So inside foo() the return continuation of foo() is
> >>  copyied, stored elsewhere, passed along to another function, and that
> >>  one now suddenly returns via this continuation to your loop.  If this
> >>  invocation of the continuation would restore registers suddenly the loop
> >>  will become an infinite one, as C<i> is always restored to zero.
> >>
> >>  [1] Have a look at runtime/parrot/library/Streams/Sub.imc
> >>
> >>  leo
> >>
> >
> >I disagree with that analysis.
> 
> You would, however, in this case be incorrect.
> 
> The loop variable must have a backing store outside of the register
> set. The contents of registers must be assumed to be unreliable when
> a continuation is continued. If we declare that they are put back
> into the state they were when the continuation was taken, which is
> reasonable though not required, the values of non-reference type
> registers (ints and floats) will be reset. The rference type
> registers (strings and PMCs) will also be reset so the pointers to
> the string/pmc structs will be what they were when the continuation
> was taken, but as they are references the referred-to thing may have
> changed and the changed value will be seen.

I am having trouble in that I agree with what you are saying, but I am
coming to a different conclusion.  I think that foo would create a new
continuation (from it return continuation) each time it is called, and
thus things below it on the call stack would be unaffected by its own
internal continuation tricks (assuming for the moment that registers
are put back into place by continuations).

Since both you and Leo are arguing against me here, it seems like that
I am wrong, but I would like to figure out exactly why I am wrong so
that I can correct my train of thought in the future.

Thanks,
Matt
-- 
"Computer Science is merely the post-Turing Decline of Formal Systems Theory."
-???

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About