Re: How to build a simple compiler/expression analyzer? (Dmitry A. Kazakov)
21 Sep 2001 23:40:40 -0400

          From comp.compilers

Related articles
How to build a simple compiler/expression analyzer? (Sacha =?iso-8859-1?Q?Sch=E4r?=) (2001-09-16)
Re: How to build a simple compiler/expression analyzer? (Rainer Schwenkreis) (2001-09-20)
Re: How to build a simple compiler/expression analyzer? (2001-09-21)
| List of all articles for this month |

From: (Dmitry A. Kazakov)
Newsgroups: comp.compilers,comp.lang.c++
Date: 21 Sep 2001 23:40:40 -0400
Organization: Compilers Central
References: 01-09-068
Keywords: interpreter
Posted-Date: 21 Sep 2001 23:40:40 EDT

On 16 Sep 2001 00:37:14 -0400, Sacha =?iso-8859-1?Q?Sch=E4r?=
<> wrote:
>We need a simple compiler that converts a self defined script language
>into byte-code. What bothers me most are general algebraic
>expressions. I know quite well, how the script language and the
>corresponding byte-code should look like. Here is an example:
>set x = 1.2 * ( b + 2 ); (or similar)
>should convert into the following byte-code primitives:
>command: arguments: (comments:)
><set_int> [t1] (2) (t1 = 2)
><add_int> [t2] [b] [t1] (t2 = b * t1)
><int_to_float> [t1] [t2] (t1 = (float)t2)
><set_float> [t2] (1.2) (t2 = 1.2)
><mult_float> [x] [t1] [t2] (x = t1 * t2)
>For simplicity, the primitives will all occupy the same amount of
>memory. The tokens inside angle brackets are symbols, the contents of
>the square brackets correspond to array indices (where the variables
>are stored), inside the round brackets are number constants.
>I know there are many parser/compiler generators around, but it's hard
>for me to choose one. Somehow I prefer to have an algorithm/source
>code for the problem above rather than a program that generates
>unreadable c or c++ source code which does the job. However, if there
>is a compiler generator which is easy to operate and produces exactly
>what i want, i'm also open for this...

If the set of supported types is limited you could simply code it
manually. You just need two stacks (of operands and operators) to
parse the infix expression. I believe in an old Grees book there is a
description, but the algorithm is very straightforward. Each argument
[literal or variable] is loaded onto the operand stack. Each operation
first unloads the operators stack [all operators with higher priority]
and then loads itself. When you unload the operators stack you write
the corresponding command into the output with its operands from the
operands stack. There are also obvious modifications for brackets,
prefix and postfix unary operations, if you have them.

Dmitry Kazakov

Post a followup to this message

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