|Equation compiler? email@example.com (Alan GARNY) (1999-10-27)|
|Re: Equation compiler? Sid-Ahmed-Ali.TOUATI@inria.fr (Sid Ahmed Ali TOUATI) (1999-10-29)|
|Re: Equation compiler? firstname.lastname@example.org (Quinn Tyler Jackson) (1999-10-29)|
|Re: Equation compiler? email@example.com (Zalman Stern) (1999-10-31)|
|Re: Equation compiler? firstname.lastname@example.org (1999-11-02)|
|Re: Equation compiler? email@example.com (1999-11-03)|
|Re: Equation compiler? firstname.lastname@example.org (1999-11-20)|
|From:||"Quinn Tyler Jackson" <email@example.com>|
|Date:||29 Oct 1999 02:37:41 -0400|
Alan GARNY <firstname.lastname@example.org> wrote in message
> The idea
> is, for instance, to allow the user to enter an equation, such as y =
> 3x+2, and compile (in assembly language for faster computation?) it
> and use it to plot the corresponding graph. Note that I am not
> interested in an equation interpreter as I know how to do that and
> that it is far too slow for my purpose.
About which, John noted:
> [There's not much difference between an interpreter and a compiler. With
> a compiler, you lex and parse the equation the same way as you would with
> an interpreter, but the output of the parser is a program in some language
> you can interpret faster. -John]
It seems to me, from the work I did on ARDAF, which included some
constant and function identity folding as an optimization, that
instead of just solving in the parse, I could just as easily have
produced a cached stack of n-nary structs that were interpreted as a
VM, and this would possibly give the necessary efficiency without
losing the benefits of parsing at run-time.
I'm considering eventually getting back to ARDAF, and that would
probably be the first thing I'd add after cleaning up the code.
Someone else could probably hack ARDAF to do that without much
Quinn Tyler Jackson
Return to the
Search the comp.compilers archives again.