Re: evaluator

[Paul Thomas]

Paul,

I read George Almasi's thesis from cover to cover last night.  For the 
main part, it talks about type inferencing, type speculation, range 
chacks, shape checks and subscript checks, rather than the JIT 
compilation.  Even when all this is done, "disambiguation" (The process 
of sorting out the remaining type uncertainties) is an important element 
of the execution. To cover this, there is a "code repository" from which 
the appropriate bits of code, according to type and range, are called. 
If the bit of code does not exist, it is compiled.

To judge by Almasi's benchmarks, you comment about doing arithmetic on 
octave values is quite correct.  Mainly, there are factors of 100 in 
execution time for the taking. However, writing a type 
inferencer/speculator will be quite an undertaking.  

Almasi points out that inline code, in languages like these, does not 
benefit enormously from any of the speculation or JIT'ing and that it is 
repetitively executed elements of code that benefit.  This leads me to 
the conclusion that rather than inferencing and speculation, 
disambiguation is the order of the day, since octave is, in essence, a 
code repository.

Paul T

Paul Kienzle wrote:

> The evaluator is built into the node classes of the parse tree.
>
> You can find the root invocation in the function eval_string
> in parse.y.  The root node is a tree_statement_list as defined
> in pt-stmt.h.  eval_string calls the eval method of the
> tree_statement_list.
>
> The whole point of the compiler is to translate the parse tree
> into C++ statements, not to call the octave evaluator.  The
> simplification in the first pass is that you will be using
> arithmetic on octave values rather than type inference.
>
> Paul Kienzle
> address@hidden
>
> On Feb 23, 2004, at 7:41 PM, Jens Ruecknagel wrote:
>
> > can somebody give me a hint to the evaluator? I am looking for the 
> > clases that evaluate the pt-* parse tree.
> >
> > I am familiar with the pt-pr-code.h - I was hoping there would be 
> > something similar for evaluating, so I can just "merge" them to build 
> > a first octave compiler.