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