Re: Number of compiler passes

Michiel <m.helvensteijn@gmail.com>
Tue, 29 Jul 2008 18:27:51 +0200

          From comp.compilers

Related articles
[8 earlier articles]
Re: Number of compiler passes gah@ugcs.caltech.edu (glen herrmannsfeldt) (2008-07-27)
Re: Number of compiler passes gneuner2@comcast.net (George Neuner) (2008-07-28)
Re: Number of compiler passes gneuner2@comcast.net (George Neuner) (2008-07-28)
Re: Number of compiler passes gah@ugcs.caltech.edu (glen herrmannsfeldt) (2008-07-29)
Re: Number of compiler passes gah@ugcs.caltech.edu (glen herrmannsfeldt) (2008-07-29)
Re: Number of compiler passes m.helvensteijn@gmail.com (Michiel) (2008-07-29)
Re: Number of compiler passes m.helvensteijn@gmail.com (Michiel) (2008-07-29)
Re: Number of compiler passes barry.kelly@codegear.com (Barry Kelly) (2008-07-30)
Re: Number of compiler passes gah@ugcs.caltech.edu (glen herrmannsfeldt) (2008-08-01)
Re: Number of compiler passes gneuner2@comcast.net (George Neuner) (2008-08-03)
Re: Number of compiler passes gneuner2@comcast.net (George Neuner) (2008-08-03)
| List of all articles for this month |
From: Michiel <m.helvensteijn@gmail.com>
Newsgroups: comp.compilers
Date: Tue, 29 Jul 2008 18:27:51 +0200
Organization: Wanadoo
References: 08-07-041 08-07-044 08-07-048 08-07-058 08-07-059 08-07-065
Keywords: analysis
Posted-Date: 01 Aug 2008 06:46:33 EDT

George Neuner wrote:


> No, depth first is fine (and I think, preferred). As long as the
> compiler can tell a declaration from other expressions in the AST, the
> actual traversal order doesn't matter.


Then I still don't understand how you want to merge those two stages
(finding declarations + finding references). A variable may be declared
*textually after* a function that references it. So it seems I have to
traverse twice to fully qualify the reference, or I need to do a breadth
first traversal.


>>I've seen the terms used in both contexts. As in: A variable is an
>>l-value. A constant is an r-value. I believe the Dragon book does this.
>
> I've also seen this usage, but IMO it can be confusing and I don't
> like it. The practical usage: L-value = result/target, R-value = operand,
> has some meaning.


That's fine. I don't actually use these terms in the language docs. I use
read-only, write-only and read/write. I only used the l-value and r-value
terms to try to explain it here.


> 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.


To me, a subexpression is still an expression. It has a type (the
content-type of the type of array A), an access-type (most probably
read/write) and a location in the source code.


To find the type and access-type of an expression, you need this knowledge
of its subexpressions. In the limited state our language is in now, I would
report an error if X did not evaluate to an `int' expression at this point.
(No associative arrays yet.)


> I see what now what you're getting at - it's your terminology that's
> throwing me. You want to know whether the variable is ever written to
> or only read, but that's different than _being_ an L-value or R-value.


Yes, of course. I admit I don't know all the compiler-theory terminology.
(Plus, I sometimes think the existing terminology is too limiting.)


> L-value and R-value at the expression level are not synonymous with
> "write" and "read" at the symbol level. Take, for example, a
> write-only function parameter passed by reference. How do you assign
> to that value?
>
> <...>
>
> As you can clearly see, the "write-only" variable "A" is used only in
> an operand position, ie. as an R-value. It is never used (directly)
> as an L-value.


But our syntax tree and our symbol table are both relatively high level.
They understand the nature of arrays. And to them, indexing an array is not
the same as reading from it.


To be blunt, I'll worry about the implementation details later. As long as
it works conceptually.


--
Michiel Helvensteijn


Post a followup to this message

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