runops speculation

[Andrew Whitworth]

On Mon, Feb 9, 2009 at 9:22 PM, chromatic <chromatic at wgz.org> wrote:
> On Monday 09 February 2009 18:10:28 Allison Randal wrote:
>
>> What if Parrot's core opcode runloop were a coroutine instead of a C
>> function? All "runops" invocations anywhere in the code would simply be
>> calling into the same coroutine.
>
> That has definite possibilities for the slow core, but I'm not sure how to
> make it work for the other cores.

I've been thinking about this all night too. The problem that I keep
running into is that you would have to call a setjmp in the runcore
before calling any opcode that might cause a recursive call into the
runcore. Because you have two methods of rentry: The opcode doesn't
cause a recursive call to runops, so it returns to the core and
continues like normal, or the opcode does cause a recursive call and
needs to invoke the continuation. What happens in cases like a vtable
override when both of these need to happen? The vtable override is
invoked recursively and then returned to the point in the runcore
where the vtable override was first called. What happens for recursive
calls to these overrides, where we would end up with a long string of
jump points to manage?

I really like the idea, but I don't think I am seeing the big picture with it.

--Andrew Whitworth