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 13:11
Subject:
Re: Continuations, basic blocks, loops and register allocation
Message ID:
f2601a7f04111613107847d293@mail.gmail.com
Dan~


On Tue, 16 Nov 2004 15:54:48 -0500, Dan Sugalski <dan@sidhe.org> wrote:
> At 3:39 PM -0500 11/16/04, Matt Fowles wrote:
> 
> 
> >Dan~
> >
> >
> >On Tue, 16 Nov 2004 15:25:24 -0500, Dan Sugalski <dan@sidhe.org> wrote:
> >>  At 3:12 PM -0500 11/16/04, Matt Fowles wrote:
> >>
> >>
> >>  >Dan~
> >>  >
> >>  >On Tue, 16 Nov 2004 13:41:25 -0500, Dan Sugalski <dan@sidhe.org> wrote:
> >>  >>  At 10:32 AM -0800 11/16/04, Jeff Clites wrote:
> >>  >>  >The continuation preserves the frame (the mapping from logical
> >>  >>  >variables to their values), but not the values of those variables at
> >>  >>  >the time the continuation was created.
> >>  >>
> >>  >>  This is one of the fundamental properties of continuations, but it
> >>  >>  does throw people. And it's why register contents have to be thrown
> >>  >>  away when a continuation is invoked, since the registers have values,
> >>  >>  and continuations don't preserve values.
> >>  >
> >>  >I think right here we have the crux of my failure to understand.  I
> >>  >was/am under the impression that the continuation will restore the
> >>  >register frame to exactly as it was when the continuation was taken.
> >>  >Thus those registers which are values (I,N) will continue to have the
> >>  >value they had when the continuation was taken, while those registers
> >>  >which are pointers/references (S, P) will still point to the same
> >>  >place, but that data may have changed.  Is this correct?
> >>
> >>  No. The registers are just about the only thing that *isn't* restored.
> >>
> >>  Continuations put the environment back. This includes things like the
> >>  lexical pad stack, the namespace stack, the stack itself, any
> >>  security credentials... basically everything that describes the
> >>  environment. *Data*, on the other hand, is *not* restored. Data stays
> >>  as it is.
> >>
> >>  Registers are a special case of data, and they're just declared crud
> >>  by fiat, since otherwise things get nasty and unpredictable.
> >
> >Then I am not sure what you mean by "The return continuation PMC type,
> >used to create return continuations used for call/return style
> >programming, guarantees that registers 16-31 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>."
> >
> >I read that as saying that registers will be restored by
> >continuations.  If that is not what it is intended to mean, could you
> >clarify for me.
> 
> Return continuations are special, basically. There are a number of
> specialized continuation forms, and this is one of 'em. Which makes
> things a bit more confusing but, well, there you go.

It seems to me that it would simpilify much of the code, and reduce
the number of special cases if we extended that to all continuations
instead of just return ones.  This would allow the register allocator
to re-use registers as it chose without having to refetch everything
from backing store (which is rather problematic for non-PMC
registers).

This does mean that if an N register wants to have its value change
across continuations it needs to have a backing store somewhere, but
even without this change things need to be fetched from backing store
as the register allocator might clobber them.  So this does not seem
like a burden in that case, and it does seem like a win for the
allocator.

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