Re: Fastening the run-time interpretation of mathematical expressions

"Tommy Thorn" <tommy.thorn@gmail.com>
13 Nov 2006 16:34:31 -0500

          From comp.compilers

Related articles
Fastening the run-time interpretation of mathematical expressions paolopantaleo@gmail.com (PAolo) (2006-11-11)
Re: Fastening the run-time interpretation of mathematical expressions haberg@math.su.se (2006-11-11)
Re: Fastening the run-time interpretation of mathematical expressions mailbox@dmitry-kazakov.de (Dmitry A. Kazakov) (2006-11-13)
Re: Fastening the run-time interpretation of mathematical expressions akk@privat.de (Andreas Kochenburger) (2006-11-13)
Re: Fastening the run-time interpretation of mathematical expressions martin@gkc.org.uk (Martin Ward) (2006-11-13)
Re: Fastening the run-time interpretation of mathematical expressions tommy.thorn@gmail.com (Tommy Thorn) (2006-11-13)
Re: Fastening the run-time interpretation of mathematical expressions 148f3wg02@sneakemail.com (Karsten Nyblad) (2006-11-15)
Re: Fastening the run-time interpretation of mathematical expressions martin@gkc.org.uk (Martin Ward) (2006-11-15)
Re: Fastening the run-time interpretation of mathematical expressions idknow@gmail.com (idknow@gmail.com) (2006-11-15)
Re: Fastening the run-time interpretation of mathematical expressions gah@ugcs.caltech.edu (glen herrmannsfeldt) (2006-11-16)
Re: Fastening the run-time interpretation of mathematical expressions darius@raincode.com (Darius Blasband) (2006-11-20)
| List of all articles for this month |

From: "Tommy Thorn" <tommy.thorn@gmail.com>
Newsgroups: comp.compilers
Date: 13 Nov 2006 16:34:31 -0500
Organization: Compilers Central
References: 06-11-052
Keywords: interpreter, performance

PAolo wrote:
> I am writing a piece of software that accept in input the definition
> of a mathematical function and a list of points in which evaluate the
> function and puts the result in output. The main feature of the progam
> is that once the function definition is read, the program evaluates
> the function very fast


You may want to check out previous posts. My example in
http://compilers.iecc.com/comparch/article/06-09-093 does exactly
that. If the native code generation is too much, you can trivially
replace it with threaded code for a loss in performance.


> [Well this isn't done already...]. I was thinking to build a pair
> of stacks, one containig the operands (floats) and the other
> containig the operators (function pointers).


Why are you ignoring 50+ years of compiler research and teaching? What
you want to do is


1. parse and analyse the source.
2. generate code.
3. run code.


For the most trivial examples, you can do 1 and 2 (sometimes even 3)
together. In my example (quite standard btw),


1. parses the source to a tree, rewriting it on the fly.
2. traverses the tree to generate the code.
3. the host processor execute the code for me.


In your case, you may instead want to generate a code for simple stack
machine and in step 3 run the interpreter for that. Something like:


double run(int pc) {
    double stack[STACKSIZE];
    int sp = 0;
    for (;;) switch (program[pc++]) {
    case PUSH_CONST:
        stack[sp++] = *(double *)stack + pc;
        pc += sizeof (double);
        break;
    case ADD: stack[sp-2] = stack[sp-2] + stack[sp-1]; sp--; break;
    case MUL: stack[sp-2] = stack[sp-2] * stack[sp-1]; sp--; break;
    ....


with lots of blanks to fill in.


Tommy


Post a followup to this message

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