On Oct 16, 2004, at 12:26 AM, Leopold Toetsch wrote:
Jeff Clites <[EMAIL PROTECTED]> wrote:... But, we use this currently, because there is one issue with threads: With a thread, you don't start from the "beginning" of the JITted code segment,
This isn't a threading issue. We can always start execution in the middle of one segment, e.g. after an exception. That's already handled on almost all JIT platforms and no problem. The code emitted in Parrot_jit_begin gets the C<cur_opcode *> as argument and has to branch there, always.
I was remembering wrong--we do this on PPC too.
On Oct 16, 2004, at 4:47 AM, Leopold Toetsch wrote:
String, number (and PMC) constants are all addressed in terms of the compiling interpreter....
When we do an eval() e.g. in a loop, we have to create a new constant table (and recycle it later, which is a different problem). Running such a compiled piece of code with different threads would currently do the wrong thing.
The correct constant table depends on the code segment, rather than the specific interpreter, right? That means that referencing the absolute address of the const table entry would be correct for JIT code no matter the executing thread, but getting the const table from the compiling interpreter is wrong if that interpreter isn't holding a reference to the corresponding code segment.
Access to constants in the constant table is not only a problem for the JIT runcore, its a lengthy operation for all code, For a string constant at PC[i]:
interpreter->code->const_table->constants[PC[i]]->u.string
These are 3 indirections to get at the constants pointer array, and worse they depend on each other, emitting these 3 instructions on an i386 stalls for 1 cycle twice (but the compiler is clever and interleaves other instructions)
For the JIT core, we can precalculate the location of the constants array and store it in the stack or even in a register (on not so register-crippled machines like i386). It only needs reloading, when an C<invoke> statement is emitted.
For PPC JIT, it seems that we are putting in the address of the specific const table entry, as an immediate.
OTOH it might be better to just toss all the constant table access in all instructions, except:
set_n_nc set_s_sc set_p_pc # alias set_p_kc
This would reduce the interpreter size significantly (compare the size of core_ops_cgp.o with core_ops_cg.o).
Reducing the size is good, but this doesn't overall reduce the number of accesses to the constant table, just changes which op is doing them.
The assembler could still allow all constant variations of opcodes and just translate it.
For this we'd need a special register to hold the loaded constant, so that we don't overwrite a register which is in use.
JEff
