Jeff~
On Tue, 30 Nov 2004 11:20:50 -0800, Jeff Clites <[EMAIL PROTECTED]> wrote:
> On Nov 30, 2004, at 10:27 AM, Dan Sugalski wrote:
>
>
>
> > At 10:15 AM -0800 11/30/04, Jeff Clites wrote:
>
> > Oh. No, it won't. We've declared that return continuations will always
> > leave the top half registers in the state they were when the return
> > continuation was taken. In this case, when it's taken to pass into
> > foo, P16 is 0x04. When that return continuation is invoked, no matter
> > where or how many times, P16 will be set to 0x04. This does make
> > return continuations slightly different from 'plain' continuations,
> > but I think this is acceptable.
>
> Ah, I see.
>
>
>
> >> None of this should have anything to do with return continuations
> >> specifically, since this is the case where the body of foo (or
> >> something called from it) creates a "real" continuation, which as I
> >> understand it is supposed to promote the return continuations to
> >> "real" continuations all the way up the stack.
> >
> > The return continuations have to maintain their returny-ness
> > regardless, otherwise they can't be trusted and we'd need to
> > unconditionally reload the registers after the return from foo(),
> > since there's no way to tell whether we were invoked via a normal
> > return continuation chain invocation, or whether something funky
> > happened down deep in the call chain.
>
> Yeah, so I think that won't work correctly. Here's an example from Ruby
> which I posted in a previous thread. If the return from the call to
> strange() by outer() always restores the registers as of the point the
> (return) continuation was created, then the below would print out "a =
> 1" over and over, but really it's intended that the value should
> increase, so with the behavior you describe, the following Ruby code
> wouldn't work right:
>
> % cat continuation6.ruby
> def strange
> callcc {|continuation| $saved = continuation}
> end
>
> def outer
> a = 0
> strange()
> a = a + 1
> print "a = ", a, "\n"
> end
>
> # these two lines are "main"
> outer()
> $saved.call
>
> % ruby continuation6.ruby
> a = 1
> a = 2
> a = 3
> a = 4
> a = 5
> a = 6
> a = 7
> a = 8
> a = 9
> a = 10
> ...infinite loop, by design
a would need to be stored in a RubyInt PMC. In such a situation it
would work as the register for a is actually a pointer to its value.
An optimizer might try and lower a to an I register, but that would be
an invalid optimization.
Matt
--
"Computer Science is merely the post-Turing Decline of Formal Systems Theory."
-???
