Continuations (again)
Gregor N. Purdy
running imc --> pasm --> exec does the same thing as imc --> exec. I
ran into that before, and I don't think its going to get fixed until
the new imcc lands, at which point old-school pasm might even be
gone (although I don't know that I'm remembering that part right).
Regards,
-- Gregor
On Sun, 2004-03-21 at 08:53, Piers Cawley wrote:
> So, I'm trying to get my head 'round parrot's continuations. It's my
> understanding that, at creation time, a Continuation closes over the
> current user stacks, control stack and lexical pad (and possibly some
> other stuff but those'll do for now).
>
> So, it seems to me that the following code should print "Howdy,
> world".
>
> .sub main
> $P0 = new PerlUndef
> $P0 = "Howdy, world\n"
> save $P0
> $P1 = newcont after
> # $P1 = new .Continuation
> # set_addr $P1, after
> invoker($P1)
> sub_end:
> .pcc_begin_return
> .pcc_end_return
>
> after:
> restore $P2
> print $P2
> branch sub_end
> .end
>
> .sub invoker
> .param pmc a_cont
> invoke a_cont
> .pcc_begin_return
> .pcc_end_return
> .end
>
> Except, what actually happens is:
>
> Parrot VM: PANIC: Illegal rethrow!
> C file src/exceptions.c, line 356
> Parrot file (unknown file), line 0
>
> Which isn't quite what I had in mind. Bizarrely, if I do:
>
> $ parrot -o howdy.pasm howdy.imc
> $ parrot howdy.pasm
> Howdy, world
> $
>
> everything's fine.
>
> Weird hunh?
--
Gregor Purdy gre...@focusresearch.com
Focus Research, Inc. http://www.focusresearch.com/
Piers Cawley
Leopold Toetsch
> So, I'm trying to get my head 'round parrot's continuations. It's my
> understanding that, at creation time, a Continuation closes over the
> current user stacks, control stack and lexical pad (and possibly some
> other stuff but those'll do for now).
Yes register stacks. Which is one problem of your code. The calling
sequence has a "savetop" inside, which isn't in the Continuations
context.
I already posted an working example.
Here is another one (comments indicate problems with your code:
.sub main
$P0 = new PerlUndef
$P0 = "Howdy, world\n"
save $P0
# create continuation inside, so that it has this in context
savetop
$P1 = newcont after
P5 = $P1
P0 = find_global "_invoker"
invokecc
after:
restoretop
restore $P2
print $P2
end
# end *is* needed in main
.end
.sub _invoker
# ^^ global labels have an underscore
.param pmc a_cont
invoke a_cont
.end
> Weird hunh?
As long as no one really can tell the semantics of Continuations, they
have to be hand-crafted like above.
leo
Piers Cawley
> Piers Cawley <pdca...@bofh.org.uk> wrote:
>> So, I'm trying to get my head 'round parrot's continuations. It's my
>> understanding that, at creation time, a Continuation closes over the
>> current user stacks, control stack and lexical pad (and possibly some
>> other stuff but those'll do for now).
>
> Yes register stacks. Which is one problem of your code. The calling
> sequence has a "savetop" inside, which isn't in the Continuations
> context.
But why do I need the savetop? I only care about the
So why does the generated pasm work where the PIR doesn't?
I can see why saving P0-2 would be a good idea, but after doesn't need
any of the other registers.
Piers Cawley
> Leopold Toetsch <l...@toetsch.at> writes:
>
>> Piers Cawley <pdca...@bofh.org.uk> wrote:
>>> So, I'm trying to get my head 'round parrot's continuations. It's my
>>> understanding that, at creation time, a Continuation closes over the
>>> current user stacks, control stack and lexical pad (and possibly some
>>> other stuff but those'll do for now).
>>
>> Yes register stacks. Which is one problem of your code. The calling
>> sequence has a "savetop" inside, which isn't in the Continuations
>> context.
>
> But why do I need the savetop? I only care about the
Oops... what happened to that sentence?
Anyhoo, I looked again at the generated .pasm and noticed that P1 was
getting copied up to P20 so, if you don't do the savetop you're never
going to get the current continuation back. (I know, I'm telling you
something you already know). It seems to me that there's a good case for
saying that P1 should be closed over when a continuation is made and
restored when it's invoked. Not having to manage P1 explicitly until and
unless you want to promote it to a full continuation should help
enormously when you're wanting to write code that does (amongst other
things) tail call optimization because you know that, unless you've
fiddled with it yourself, P1 is always the current continuation. (Right
now you have to restore P1 from whichever hidden PMC register IMCC has
hidden it in, set up the various call registers by hand, stick the sub
in the right place and call it with invoke not invokecc. Since you don't
actually know *where* IMCC has shoved the continuation this is a little
tricky. You end up having to duplicate the work.)
Dan? Could you mandate this? Please?
Preserving self and the current function object could also be rather
handy...
Leopold Toetsch
[ Continuation usage ]
> Dan? Could you mandate this? Please?
As long as there are no usage patterns that precisely describe how
Continuations should work and how a PIR syntax could look like, there is
little to mandate ;)
> Preserving self and the current function object could also be rather
> handy...
C<self> is preserved around (method only?) calls. The subroutine object
currently not. This could be optional:
$P0 = getprop sub_self, "some" # sub_self := P0
>
leo
Leopold Toetsch
> So why does the generated pasm work where the PIR doesn't?
The generated PASM is all one compilation unit. Your (local) labels are
fixed up properly. In your PIR code you had local labels (w/o)
underscore refering to different compilation units.
> I can see why saving P0-2 would be a good idea, but after doesn't need
> any of the other registers.
s. a different f'up.
leo