Lecture #10 (14 February 2002)

Parsing Arithmetic Expressions

Overall Reading
Brookshear: pp. 255-262
Decker/Hirshfield: Mod. 6.4

Outline:

  • Program Translation
  • Grammer
  • Parsing
  • Code Generation

    • Program Translation

    For review, the goal of high-level programming languages is to balance finding a language which should be easy for humans, yet still understandable by a machine.

    The goal for this lecture is to examine the program translation process more closely, using examples which involve arithmetic expressions.

    Example 1: 

      W = X + Y
    vs. 
      LOD X
  ADD Y
  STO W

    Note: In computer science the equal sign often has different semantics in different settings. Within a Boolean expression, we might expect the statement "X=Y" to be a condition which might either be true or false.

    However, it is common to use an equal sign to designate statements of assignment. In this context,the statement "X=Y" may be interpreted as an instruction that the value of a variable X should be set so that it equals the value currently associated with Y ("let X equal Y").

    Different computer programming languages have adopted different syntax to differentiate equality tests versus assignment statements.

    Example 2: 

      W = (X+Y)/(Z+8)
    vs. 
      LOD Z
  ADD 8
  STO T1
  LOD X
  ADD Y
  DIV T1
  STO W
  • Grammer
    A strict grammer for arithmetic expressions might require opearators to be binary, and compound expressions to be strictly parenthesized. Such a grammer might be described by the following production rules: 
    Expression:  number 
               or
             variable
               or
             ( [Expression] [Operator] [Expression] )

Operator:    '+' or '-' or '*' or '/'
    Examples of expressions according to that grammer would include:
  • 28
  • Y
  • (5+X)
  • (3*((X+2)-(Y/23)))
    • However, the string "(3+5+7)" is not a valid expression by the above rules. Rather "(3+(5+7))" is a valid expression, as is "((3+5)+7)".

    More General Expressions
    From algebra, we are used to dealing with a relaxed definition of arithmetic expression, that are not so strictly parenthesized. Such relazed grammers are often used in computing as well. See Figure 5.14 of [Br], for example.

    Avoiding ambiguity Unfortunately, the grammer given in Figure 5.14 is ambiguous (See Question 3 of Ch. 5.4, on p. 264 of [Br]).

    How should the following be interpreted?

  • X-Y*Z
  • X-Y-Z
  • 2-X/5*Y+Z
    • Rules of operator precedence

  • We always evaluate what is within a pair of parentheses, before we use that result in any part of a larger expression.
  • If a part of an expression involves many terms and operators, without explicit parenthesization, we do the following:
  • Multiplication and Division are given precedence over Addition and Subtraction (e.g., 3+8/2).
  • Operators of equal precedence are evaluated from left to right (e.g. W-X+Y-Z)

  • Parsing
    For arithmetic expressions, an intermediate goal of a parse is to build what is commonly called a "parse tree" which represents the computational structure inherent to an arithmetic expression.

    Let's look at some examples using Rosetta software from the Decker/Hirshfield text.

  • W = X+Y
  • W = X-Y*Z
  • W = X-Y+Z
  • W = (X+Y)/(Z+8)

  • Code Generation
    After a parse tree has been built, the only complicating factor in generating code is the careful use of temporary registers for storing the results of intermediate calculations.

    Let's look at some examples using Rosetta software from the Decker/Hirshfield text.

  • W = X+Y
  • W = X-Y*Z
  • W = X-Y+Z
  • W = (X+Y)/(Z+8)

    • comp150 Class Page
    mhg@cs.luc.edu
    Last modified: 20 February 2002