Dan~
On Tue, 16 Nov 2004 15:54:48 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:At 3:39 PM -0500 11/16/04, Matt Fowles wrote:
>Dan~
>
>
>On Tue, 16 Nov 2004 15:25:24 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
>> At 3:12 PM -0500 11/16/04, Matt Fowles wrote:
>>
>>
>> >Dan~
>> >
>> >On Tue, 16 Nov 2004 13:41:25 -0500, Dan Sugalski <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
