(original) (raw)
2010/7/23 Stefan Behnel <stefan_ml@behnel.de>
stefan brunthaler, 23.07.2010 08:48:
If we take for instance the BINARY\_ADD instruction, the interpreter
evaluates the actual operand types and chooses the matching operation
implementation at runtime, i.e., operands that are unicode strings
will be concatenated via unicode\_concatenate, for float operands on
the other hand, the interpreter would end up invoking float\_add via
binary\_op1\. Now, a very efficient way to achieve purely interpretative
inline caching is to quicken the type-generic BINARY\_ADD instruction
to a type-dependent FLOAT\_ADD instruction (this technique, i.e.,
inline caching via quickening, is the primary contribution of my ECOOP
paper). Hence, I have a very simple code generator, that generates
type-dependent interpreter instructions in a pre-compile step of the
interpreter, and uses runtime type information to quicken/rewrite
instructions.
Aside of the operators, I have implemented this quickening technique
for FOR\_ITER, COMPARE\_OP and CALL\_FUNCTION instructions.
This sounds like wpython (a CPython derivative with a wider set of byte code commands) could benefit from it.