On Thu, Feb 06, 2003 at 01:37:42PM +0100, Leopold Toetsch wrote: > This is one thing I allways wanted to try ;-) > > fast_core MOps: 11 > Prederef: 17.5 > CGoto MOps: 19.4 > CGP MOps: 27.5 > CGP -O3 MOps: 65 !!!1 > > This runloop combines the faster dispatch of opcodes via computed goto > and the clever register addressing due to predereferencing registers and > constants.
Oooh. Shiny > And it's compact due to the fact that all opcode variants with constants > collapse to just one implementation of the functions body. It's so > compact, that my ancient gcc 2.95.2 even can compile it -O3, which > didn't succeed with core_ops_cg.c. Oooooh. Shinier 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. 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 written JITted versions of. The sections with the loops are converted to native code, and the rest of the ops still gets the benefit of your sterling efforts at improving the "regular" bytecode dispatch. Nicholas Clark
