If memory serves me right, Nicholas Clark wrote: > I had a (possibly) impractical idea - computed goto / JIT > (or even computed goto / prederef / jit) core > > I don't know whether this is possible: > > Inside a cgoto core have 1 extra op - enter JITted section. > > The bytecode is "compiled" by the JIT (at some point) - if there are a run > of consecutive JIT-able ops, then issue a section (an isolated section) of > machine code for those ops, and replace those ops in the bytecode with an op > that calls that section. If there isn't a run of JIT-able ops, then just > leave the ops as ops, and use the regular computed goto core dispatch.
Are you discussing some sort of unroller for native code for some opcodes ? .. basic blocks ?. Anything too complicated to unroll is replaced by a jump back into the interpreter core ?.. This strategy has been used in pnet's engine (which is still a souped up interpreter) ... the motivation was ease of porting unrollers than full JITs, ie opcode by opcode . > I'd envisage it becoming a win if PBC often ends up with tight, isolated > loops that use a lot of JITted ops, but most of the code is ops we've not See the Unrolling section on Rhys's paper for a detailed discussion on this idea <http://www.southern-storm.com.au/download/pnet-engine.pdf> Speaking truthfully , all I know is that it lifts pnetmark score for loops by about 10 times . Hope it helps, Gopal -- The difference between insanity and genius is measured by success
