Re: seeking embeddable statement compiler code

"Edward G. Nilges" wrote:


> Silvius Rus <rus@tamu.edu> wrote...
> > At one end, you could write an interpreter for the expression
> > language. The code would be pretty slow as every evaluation would be
> > based on a traversal of the graph that represents your expression.
>
> Why not translate his expression to Polish notation using top-down
> recursive descent, and write or find an interpreter that evaluates the
> expression using a LIFO stack? I see no need to traverse a graph.
>


True, it is not necessary to chase pointers around a GRAPH. But a
stack evaluator is an implementation of a postorder traversal of the
TREE that represents the expression. These expressions seem simple
enough to be represented as a tree but one could use a DAG to identify
common subexpressions. Cyclic graphs would only be needed for
recurrences. I was just trying to be a little abstract, but I did use
a stack evaluator myself when I had to.


This is still slower than compiled+ optimized native code. Run-time
compilation is a viable alternative and Java hot-spot compilers are
the living proof. They are usually profile-driven, but in this
particular case you could develop a custom way of identifying the
hot-spot and invoke the compiler only when profitable.


Silvius Rus

Return to the comp.compilers page.
Search the comp.compilers archives again.