At 11:13 AM +0200 10/28/04, Leopold Toetsch wrote:
1) use frame pointer relative addressing: + prederefed code is usable by different threads too - ~4 times increase in code size of core_ops_*.{c,o} [1]
2) Re-prederef on function calls, if frame pointer differs + no impact on code size - needs precise code length of functions - threads need distinct prederefed code - possibly slower then 1)
Or 3) Toss the prederef stuff entirely.
Well, the prederefed function core (parrot -P) is for sure not necessary. Are still remaining CGP and switched core, which is prederefed too. CGP is by far the fasted run-core for JIT-less architectures, if CGoto is available. The switched core can of course run w/o prederef too.
But one thing is nice with prederef: it's by far the simplest way to create a safe run core that verifies opcode arguments. This could of course be done w/o predereferencing afterwords, but while you are checking function args, predereferencing these is of almost zero cost.
Using option 1) above isn't really complicated. The problem we have is code size and opcode count, which is a problem with the CGoto core too.
I've proposed not too long ago to toss all opcode variants with constants and just leave:
set I, Ic set N, Nc set S, Sc
Immediate constants aren't really that useful with RISC cpus. You might have a look at e.g. jit/arm/jit_emit.h:459 ff.
leo
