Re: Number of compiler passes

George Neuner wrote:


  > Ok, we have different definitions of expression. I consider an
  > expression to compute something or cause a side effect like altering
  > control flow. To me, a variable reference like "A[X]" is a
  > subexpression that can't stand on its own.


I think a symbolic location reference like A[X] is an appropriate
structure to have in an expression tree, and that it has a type, and
that when evaluated for computation it acts as an rvalue, but it can
also serve as an lvalue if it occurs e.g. as the operand to an
address-of unary expression node, or on the lhs of an assignment.


I suggest that it should be up to a later visitor that puts meaning to a
tree like (index (symbol 'A') (symbol 'X')). The tree itself is just a
symbolic description of a location; it is neither read-only nor
write-only (unless the types and/or members have constness associated
with them like C++).


To make this rather subtle distinction clearer with a concrete example,
an assignment might look like:


(assign (symbol 't') (index (symbol 'A') (symbol 'X')))


"t := A[X]"


or:


(assign (index (symbol 'A') (symbol 'X')) (symbol 't'))


"A[X] := t"


That is, A[X] is just as much an expression that can stand on its own as
any other expression - when computed for its value it returns A's Xth
entry (presumably). However, a code generator might compute it for its
*location*, in which case it acts differently - but the decision is in a
visitor to the tree, not in the tree construction itself.


In practice, however, it's probably best to annotate nodes based on
whether they can be assigned to or not, so that errors like "(4 + 5) :=
10" can be found nice and early; and similarly for rvalue-ness or not,
if that's appropriate for the source language.


-- Barry

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