|seeking embeddable statement compiler code email@example.com (Bruce Varley) (2001-11-25)|
|Re: seeking embeddable statement compiler code firstname.lastname@example.org (Silvius Rus) (2001-11-26)|
|Re: seeking embeddable statement compiler code email@example.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 firstname.lastname@example.org (Silvius Rus) (2001-12-03)|
|Re: seeking embeddable statement compiler code email@example.com (2001-12-07)|
|From:||Silvius Rus <firstname.lastname@example.org>|
|Date:||26 Nov 2001 22:03:36 -0500|
|Organization:||Texas A&M University|
|Posted-Date:||26 Nov 2001 22:03:36 EST|
Bruce Varley wrote:
> The expression needs to be able to contain 4 variable elements whose
> values can be adjusted on consecutive calculations. Typically, it
> would be something like:
> a * ( b + cos(2.5 - c) * sqrt(d))
> Typically, one function would read the input string and generate the
> codified version. A second function would insert the values for the 4
> variables then evaluate the expression.
If you are looking for papers on this issue I would suggest trying
"Partial Evaluation" as a keyword.
There are many known solutions to this problem, and the ones I know
fall somewhere between the following extremes.
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.
This traversal cannot be optimized very well by compilers as the
expressions are only available at run-time. You would probably have to
write a couple hundreds lines of C++ code to implement it.
At the other end, you could write the expression into a file as text,
wrap a function stub around it and run a compiler on it. The
resulting code would be as fast as it gets. There is a big price to
pay though as you would have to run the compiler, load the resulting
code and link to it, everything at run-time. This approach is easier
to implement (in terms of lines of code), if your operating system
offers dynamic library primitives such as "dlopen" and "dlsym".
Since your problem seems well defined (you have knowledge about
operand types and operator complexity), you can design a cost model
that will help you make the better choice at run-time. If the
functions you read are applied few times, the first solution is
better. When the number of times you invoke the same function on
different sets of input values gets very large, the second option
starts to be better.
Run-time code generators are between the extremes. The ones I read
about are DyC, Tempo, and 'C. They are all academia projects you can
find on the Web.
Hope it helped,
Texas A&M University
Return to the
Search the comp.compilers archives again.