evaluator

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

evaluator

Jens Ruecknagel-2
Hi,

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.

Thanks a lot

Jens


Reply | Threaded
Open this post in threaded view
|

Re: evaluator

Paul Kienzle
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
[hidden email]

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.


Reply | Threaded
Open this post in threaded view
|

Re: evaluator

Paul Thomas-10
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
> [hidden email]
>
> 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.
>
>
>