Re: Number of compiler passes

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


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


When you encounter a reference to an undeclared something, you make a
conditional entry for it in your symbol table. Conditional symbol
entries are kept open so that new information can be added as it is
encountered - so for example an entry describing a record may have an
incomplete member list because you haven't seen them all used.


The conditional symbol entry records the location of each forward use
site and either marks the type as explicitly unknown or tracks the
usage to try to infer a type - that way if the same fully qualified
name is being multiplied and appended to in different places you know
have a problem even without seeing the type declaration.


When the actual type declaration is encountered, you can go back and
quickly check if all the forward uses are compatible with the actual
types and replace the conditional entry with a sealed one.




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


IMO there is too much terminology with too many context dependent
meanings. One of my pet peeves is acronyms - nearly every research
paper I see requires a dictionary to read because the authors have
invented dozens of new acronyms for things that already have acronyms
in the hopes that their particular use will catch on and make them
famous.




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


That's perfectly fine - I now understand what you are trying to do and
am just trying to clarify the terminology for the future.


George

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