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

Re: Continuations, basic blocks, loops and register allocation

Thread Previous | Thread Next
From:
Dan Sugalski
Date:
November 16, 2004 13:24
Subject:
Re: Continuations, basic blocks, loops and register allocation
Message ID:
a06200709bdc01e5ce364@[172.24.18.155]
At 4:10 PM -0500 11/16/04, Matt Fowles wrote:
>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.

We could, but it would be wrong. Hell, it's arguably wrong for return 
continuations to do so, and it wouldn't be unreasonable to argue that 
I and N register contents are guaranteed crud and required refetching.

I'm not particularly concerned with pressure on the register 
allocator, honestly -- it's a pleasant add-on, and one we will 
continue to do, but it's not strictly necessary. We deal with that 
after we get things correct.
-- 
				Dan

--------------------------------------it's like this-------------------
Dan Sugalski                          even samurai
dan@sidhe.org                         have teddy bears and even
                                       teddy bears get drunk

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