On Friday 25 January 2008 07:46:32 Andy Lester wrote:
> On Jan 25, 2008, at 2:16 AM, chromatic wrote:
> > Did you test this with make testC and make testj?
> I'm unaware of testC and testj. So no.
Okay.
> I'm looking at the Makefile, and I guess I'm not understanding the
> differences between the various cores.
There's a standard runloop, where each opcode is a separate C function.
That's pretty easy in pseudocode:
slow_runcore( op ):
while ( op ):
op = op_function( op )
check_for_events()
The GC debugging runcore is similar:
gcdebug_runcore( op ):
while ( op ):
perform_full_gc_run()
op = op_function( op )
check_for_events()
The switched core eschews a bunch of tiny op functions in favor of cases in a
large switch statement:
switch_runcore( op ):
while ( op ):
switch *op:
case NOP:
...
case STORE:
...
...
There's computed-goto (which avoids the overhead of function calls by jumping
directly to the address where each opcode's function starts, I believe) and a
JIT core (which knows when to jump to JIT-compiled code for supported
opcodes).
Most of the difference outside of the runcore code itself is that we have to
be slightly careful about certain assumptions, especially related to passing
around opcode pointers and addresses of or offsets into bytecode.
Usually most of the code doesn't trip any differences in runcores, but if you
saw some of my commits before the previous release, you may have noticed that
I had to fix some of the runcores to check for events appropriately. That's
all runcore changes.
The change I responded to here changed the address in bytecode where Parrot
should resume after an exception for certain runcores, and that caused some
crashes because it was wrong. Fortunately, it was easy to rewrite the code
so it wasn't correct but wrong looking.
-- c
