Re: Prederefed run cores

Dan Sugalski wrote:
> 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