Subject: Re: LOCAL

From: Zheng Gengbing <[email-masked]>
Date: Fri, 14 Jun 1996 08:53:48 +0800 (EAT)

On Thu, 13 Jun 1996, Guansong Zhang wrote:

> PKU please also pay attention to this letter.
> 
> On Jun 13,  1:36pm, Li Xinying wrote:
> > Subject: Re: question on symbol table definition (fwd)
> >
> >
> > On Wed, 12 Jun 1996, Guansong Zhang wrote:
> >
> > > > >
> > > > > ++++++++++++++++++++++++++++++++++++++
> > > > >       program test
> > > > >       real x,y
> > > > >       x = 3.14
> > > > >       call sub1(x)
> > > > >       y = x*2
> > > > >       stop
> > > > >       contains
> > > > >         subroutine sub1(x)
> > > > >         real x
> > > > >         x = 1.0
> > > > >         return
> > > > >         end subroutine sub1
> > > > >       end
> > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > >
> > >
> > > But you don't tell me, when we set the symbol as LOCAL?
> > >
> >
> >    OK. If the variable is used in the local subroutine (function) , it is
> > LOCAL; If it is the input var it is set INPUT; if it the output var it is
> > set OUTPUT.
> >    So in "test" x,y is LOCAL; in sub1 x is INPUT.
> >    I remember we have discussed this problem.
> >
> > xinying
> >-- End of excerpt from Li Xinying
> 
> 
> Any way, let me make myself more clear:
> 
> Question 1:
> 
> In fact, the following is ST from the above file (get from 1.57)
> 
>    id   var   type  attr     next   scope  variable-name
>    1-S  550   ----    0       2-S    1-B              *    DEFAULT
>    2-S  505   ----    0       3-S    1-B      PROG_NAME    PROGRAM_NAME
>    3-S  505   ----    0      ----    1-B           test    PROGRAM_NAME
>    4-S  503    2-T 536870912  5-S    2-B              x    VARIABLE_NAME
>    5-S  503    2-T 536870912  7-S    2-B              y    VARIABLE_NAME
>    6-S  600    2-T    0       7-S   ----           sub1    LOCAL
>    7-S  506   ----    0      ----    2-B           sub1    PROCEDURE_NAME
>    8-S  503    2-T 536870912 ----    9-B              x    VARIABLE_NAME
> 
> (I edit a little to make it clear.)
> 
> We can see neither x or y are LOCAL. They are VARIABLE_NAMEs. ???
> 
> Qestion 2:
> 
> In your previous letter:
> 
> On Jun 13,  6:18am, Li Xinying wrote:
> 
> > > 3, sub1 present two times in the ST, one as LOCAL one as PROCEDURE_NAME,
> what
> > > does this mean? and especially, what LOCAL mean?
> > >
> >
> >     This reason is same with 1.
> >
> >-- End of excerpt from Li Xinying
> 
> I don't understand this well. The thing you refered to is a redundant program
> header. You mean sub1 should appear only once?
> 
> Here is PKU's comments on this:
> 
> On Jun 13,  4:45pm, Zheng Gengbing wrote:
> >
> > > 3, sub1 present two times in the ST, one as LOCAL one as PROCEDURE_NAME,
> what
> > > does this mean? and especially, what LOCAL mean?
> > >
> >
> >
> > 	Again one of this PROCEDURE_NAME is useless . hpfsc pick up the right
> > one .
> >
> > 	When sub1 first encountered in program test , hpf2dep make a symbol
> > entry , while in subroutine sub1 , hpf2dep also make a symbol entry. That's
> > why it presented twice .
> >
> >-- End of excerpt from Zheng Gengbing
> 
> 
> My question is how we define the symbol table for this.
> 
> In fact, to me it does not matter whether sub1 present one or two times. But we
> have to present reasons for that:
> 
> First: If sub1 present two times in ST, we should explain them as following:
> 
> one as definition of the subroutine, one as the reference of the subroutine.
> Form the AST we can trace that 6-S is rooted on call statement, so it should be
> a ref, while 7-S is rooted on proc-header, so it should be a def.
>

	Yes .

> Then what this LOCAL mean? It means a reference to a FUNC_NAME? Then what about
> its scope? NULL? (as show by dumpdep now)
> 

	To us , LOCAL play the same role as field seen you mentioned in the 
letter. We can deal this better .

> Second: If sub1 presnet one times in ST. That means at compile time def and ref
> of function call can be linked together as one entry in ST. (The scope of the
> symbol should be it's def.) Then the LOCAL may only mean a tempory mark for
> those function ref.
> 
> I don't understand when the value LOCAL was assigned, what do we mean now?
> 
> Is it mean a possible function ref without "seeing" its def? Then to all the
> form NAME(), if we can not see NAME as array def and function def, it should be
> put as LOCAL.
> 
> But this seems not the case again. In my letter about token FNAME, we see a f
> was considered as an array ref, not a LOCAL. ???
>

	So you know the difficulty of hpfsc to deal with the whole messy
situation .

> In fact, this question is related to dealing with FNAME. I need to know the
> current meaning of this LOCAL. Or it is just a mistake.
> 
> 
> I will make comments on your replay about FNAME in next letter.
> 
> 
> Guansong
> 
> 
> 

Gengbin