Bls: State of JIT compiler

[John W. Eaton]

On 24-Feb-2011, Mario Ray Mahardhika wrote:

| > Do avoid HTML (formatting) and top-posting in your email responses
| if possible.
| 
| (?_?) I didn't write any HTML...
| 
| > I'm not exactly sure if you're expecting a document detailing the
| > syntax tree. It doesn't exist yet, but perhaps it should be written. I
| > pointed you to the parser source, because I think that's the only
| > formal "specification" of the Octave language that exists.
| 
| OK, that's fine. As long as the grammar in the generator-expected format
| exists, I can manage that. Maybe some semantics would be questioned if I don't
| understand it from the interpreter code.

Can you say more about exactly what you plan to do?

Why do you need the language grammar separate from the Octave sources?
Octave's lexer and parser generate a parse tree, which is then
evaluated (see the file src/pt-eval.cc).

What I think needs to happen is that some sections of code need to be
compiled and then executed by the evaluator in place of the current
parse tree evaluation.  As I see it, the difficult parts of this are
inferring types so that you can generate code that a C++ compiler can
do something intelligent with, and also deciding which blocks of code
to actually compile (full function bodies?  just some loops?).  In any
case, type inferencing is the key feature here.  If you only operate
on octave_value objects, you won't see much speedup, as a lot of the
time is spent decoding exactly what each octave_value object contains
and dispatching operations once the underlying types are decoded.  To
speed things up, you have to do the inferencing and dispatching ahead
of time.  I think that's what makes tracing JIT implementations
interesting -- they don't attempt general type inferencing, but wait
to see what values functions (or smaller blocks of code) are actually
called with, compile for those conditions, and then when the same
conditions are met, use the compiled code to perform the operations.

jwe