From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
Date: Wed, 22 Feb 2006 22:06:22 -0600
. . .
PGE does not expect that a sub will restore the state of the user
stack, but it does expect that *coroutines* get their own copy of
the user stack, and that calling/returning from a coroutine will
not affect the current user stack. This expectation comes from
two sources-- first, it's claimed at the bottom of page 165 in
"Perl 6 and Parrot Essentials", and the docs/pmc/subs.pmc file
says that coroutines get a COW copy of the user stack.
Are you talking about the table under "Items in the Subs Context"? I
had forgotten that existed. Is it still prescriptive? Because most of
the "C" items are in fact "X", if I understand correctly.
Based on the trace I just looked at, it appears that a save opcode
executed inside a coroutine -- the coroutine generated to handle
the <after c> subrule -- is indeed affecting the results of a
restore in the caller and causing an infinite loop. In particular,
I'm seeing the following sequence...
So, with this patch applied, user stacks in coroutines don't
appear to be working the way I would expect them to.
Yes, what you're seeing is what I thought I had implemented. I had
realized that coroutines would be affected this way, but it didn't even
occur to me that PGE might rely on this. In particular, I didn't think
it was specified behavior. In any case, thanks for figuring this out.
FWIW, the current stack implementation only works for you (unless I
am much mistaken) since all of the push/pop ops within each coroutine
happen in the same sub. Otherwise, the change of context would work
against you.
From: Leopold Toetsch <[EMAIL PROTECTED]>
Date: Thu, 23 Feb 2006 10:37:00 +0100
. . .
Moving the user stack from context (which is distinct for a coroutine)
to the interpreter needs definitely more code:
a) create or copy user stack on coroutine creation, store it in the
coro structure
b) swap user stacks on yield/reinvocation
Yes. Given such ops as C<rotate_up>, it seems to me that copying the
stack on creation, or creating it empty, would be cleaner than a
solution that shared stack entries.
> As I said, I'll be the first to admit that my understanding of
> how the user stack is supposed to work may be incorrect.
Well, there are two issues involved with the user stack:
* do we really need it / want it / keep it [1]
* if so, how are the semantics across sub calls or for coros
[1] the stacks are rather inefficient and big structures:
one stack entry occupies 12 words (96 bytes on 32-bit)
using a local ResizableIntegerArray is by far more efficient
leo
Yes, and compilers/humans that want to use stacks can scope such stacks
arbitrarily (i.e. globally, per-coroutine, per-sub, whatever) simply by
stuffing the array in an appropriately-scoped variable.
From: "Patrick R. Michaud" <[EMAIL PROTECTED]>
Date: Thu, 23 Feb 2006 17:23:19 -0600
I've just committed an update (r11722) that eliminates PGE's
use of save/restore opcodes in the code it generates -- indeed,
PGE no longer has any save or restore opcodes and thus doesn't
need the user stack at all.
Also, with these changes, the patch that started this thread now
seems to work (all tests pass on my system, including PGE tests)
. . .
Works for me, too.
From: Leopold Toetsch <[EMAIL PROTECTED]>
Date: Fri, 24 Feb 2006 00:57:24 +0100
On Feb 24, 2006, at 0:23, Patrick R. Michaud wrote:
>> [...]
>> Well, there are two issues involved with the user stack:
>> * do we really need it / want it / keep it [1]
>> * if so, how are the semantics across sub calls or for coros
>
> I've just committed an update (r11722) that eliminates PGE's
> use of save/restore opcodes in the code it generates -- indeed,
> PGE no longer has any save or restore opcodes and thus doesn't
> need the user stack at all.
That's indeed an (indirect) answer to the 'do we really need it' part ;)
leo
I myself have no real interest in keeping the user stack, having no
particular use for it. The real point of this exercise (besides, IMHO,
making stacks more stack-like) was as a warm-up for dynamic bindings. I
intend to argue (in my long-overdue dynamic binding proposal) that the
control_stack needs to be moved into the interpreter, since it must be
saved/restored by continuations and coroutines, much as you say above
for the user stack. While considering this, though, I realized that
moving the user_stack would also have benefits.
I do think this patch adds something useful, for those who want a
stack. But if the choice is to have per-coroutine stacks, or flush the
feature altogether, then there's no point to it.
-- Bob
