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. 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." -???
