Re: seeking embeddable statement compiler code

spinoza1111@yahoo.com (Edward G. Nilges)
7 Dec 2001 23:39:12 -0500

          From comp.compilers

Related articles
seeking embeddable statement compiler code bvarley@comswest.net.au (Bruce Varley) (2001-11-25)
Re: seeking embeddable statement compiler code rus@tamu.edu (Silvius Rus) (2001-11-26)
Re: seeking embeddable statement compiler code spinoza1111@yahoo.com (2001-11-29)
Re: seeking embeddable statement compiler code Sid-Ahmed-Ali.TOUATI@inria.fr (Sid Ahmed Ali TOUATI) (2001-11-29)
Re: seeking embeddable statement compiler code rus@tamu.edu (Silvius Rus) (2001-12-03)
Re: seeking embeddable statement compiler code spinoza1111@yahoo.com (2001-12-07)
| List of all articles for this month |

From: spinoza1111@yahoo.com (Edward G. Nilges)
Newsgroups: comp.compilers
Date: 7 Dec 2001 23:39:12 -0500
Organization: http://groups.google.com/
References: 01-11-115 01-11-126 01-11-132 01-12-007
Keywords: interpreter, design
Posted-Date: 07 Dec 2001 23:39:11 EST

Silvius Rus <rus@tamu.edu> wrote in message news:01-12-007...
> "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.


My practice in developing simple compiler/interpreters may need to be
updated for I am an old Polish Logic kinda guy. I am aware that
Polish Logic tends to not short-circuit Or expressions, and waste time
when there are common subexpressions, but for simple projects it is
easy to implement in comparision to directed acyclic graphs.


At ACM ASPLOS 1986 a lot of RISC speakers said mean things about
Polish Logic because it cannot easily be optimized. But its
reliability is higher, to me, than new mojo that needs to be carefully
tested. I sense the old American bias against European high technology
which was seen in the failure to adopt Algol.


You may be interested to know that Microsoft is catching up, rapidly,
with the Java and Sun world as regards just in time compilation. I
took a class for book authors in August and the development people I
spoke to were completely *au fait* with advanced compiler technology.


Post a followup to this message

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