Subject: Re: token FNAME

From: Zheng Gengbing <[email-masked]>
Date: Fri, 14 Jun 1996 09:20:27 +0800 (EAT)

On Thu, 13 Jun 1996, Guansong Zhang wrote:

> First I make comments on your letters:
> 
> On Jun 13,  5:05pm, Zheng Gengbing wrote:
> > Subject: Re: token FNAME
> > On Wed, 12 Jun 1996, Guansong Zhang wrote:
> >
> > > > >
> > > > > 2, Yes, to distinguish function and array by yacc rule is difficult.
> But
> > > what
> > > > > about the yacc action?
> > > > >
> > > > > I talked abou that the array reference should be declared at first
> > > otherwise
> > > > > things like NAME(...) should be considered as function, only function
> name
> > > can
> > > > > be used with out declaration. (PKU did not agree with this, the problem
> is
> > > I
> > > > > can not find this on FORTRAN book, but this was convinced by two
> Fortran
> > > > > programmers here. Can we have an example conflicts this?)
> >
> >
> > 	In fact I have the same opinion on this . The problem is when yacc
> > time , hpf2dep can dot find the  array reference thoroughly . If we only
> > search the  array reference in current scope not consider the module used ,
> > our roughly decision considering the NAME() as function is perhaps wrong .
> >
> 
> You are right, when search the ST under current scope, a "use" statement will
> add more contents. And it is a recursive one, which means module can use
> another module. Another possible trouble is that some names may be renamed.
> 
> If we decide to do so, all these things should be taken into consideration.
> 
> > 	When we consider multi files , this problem is even serious . This time
> > the function or  array reference of NAME(...) maybe defined in other module !
> 
> Yes, even with changed name. But it still possible to detect them with yacc
> rules. (Please see the following about module file, they are different from
> seperate compiled object file.)
> 
> 
> Here I want to say a few words about multi-file, since hpfsc is developing to
> support it, but HIT, you should also pay attention to this, it concerned with
> definition of Symbol table.
> 
> In Fortran 90, multi-file feature reflects in the following three aspects,
> which all pose new things for our project:
> 
> 1, include file: though the file is written seperately, but it just the same as
> one big file, execpt line number.
> 
> A program like cpp will merge the file to one, but with directives on line
> numbers.
> 
> Since in our dep file, line number is stored, so to support include, something
> should be done about this. Even if just use cpp, in fact, both DEC and IBM F90
> compiler use cpp as preprocessor.
>

	We did not consider the issue yet , since we think it is the work of
lex . Any way this cannot prevent us from implementing the multifiles.

	I hope HIT will consider this.
 
> 2, seperated object file. This is concerned with the binding of def and ref.
> Ideally, in each object, when there is a ref, there should be a def. or at
> least a declaration (something like extern function prototype in C.) So it
> always possible to bind them whether in the first pass (hpf2dep) or the second
> pass (hpfsc). The question is how to bind them? Leave two entry in ST with same
> name, one as def(or dec), another as ref? (It seems this is the current
> solution.) Then what about the about the dec is omitted, (this is allowed in
> Fortran)?
> 
> These kinds of thing are not serious problems, but we need a uninamous
> definition for them. Now I don't understand this definition. The question on
> LOCAL reflects my puzzle.
> 

	I have mentioned this issue in previous letter . The symbol entry
of sub1  as ref become useless after the def entry is found .  In fact , 
we forget to link the def symbol entry to substitute the ref one , but 
you can see the scope of ref symbol entry is NULL , which indicate that it
is a gabage . Now I have done the change in hpfsc.

> 3, module file.
> 
> Please pay attention, a seperate module file is different from a seperate
> object file. To obtain seperate object file, you can compile .f one by one, in
> any order. But module file is not like this. A module definition must be
> compiled before module use.
> 
> Let me describe how commercial compiler (IBM and DEC) deal with this issue.
> When a .f file was compiled, even with -c flag, if there is module defined in
> the .f file, a mname.mod file will be generated in the current dir, mname is
> the module name. It possible that there is more than one module is defined in
> this .f file, in that case, as many .mod file is generated.
> 
> Then when .f file with "use mname" is compiled, mname.mod will be searched at
> current dir. If the .mod file is not found, the process simply stop.
> 

	Well , we also implement like this , except we add the -m to tell
hpfsc when to produce the .mod files. 
	structure of .mod files are defined in mod_struct.h . It is like
dep_struct.h . But dep_structure can not fit mod files.

> In fact, F90 handbook specify that some order maybe needed by an implementation
> of the compiler, but I don't know why IBM and DEC decide to use the same
> strategy and naming convention.
> 
> I am not sure how module is going to be supported in our project.
> 
> PKU's effort of multifile seems one level upper than the above two (I don't
> know if they deal with the first one). If hpfsc will generate a .dep file for a
> complete program, it seems that we don't support multi-file well. Because the
> hpfsc is also part of a compiler, its out put is not final compiler out put
> yet.
>

	Hpfsc should generate a .dep file for complete program, here is 
the reason .
	The conversion of the AST need a global dep file . We can not affort
to do the  conversion and checking in separate dep files .
	Though , the output of hpfsc is not the output of compiler, hpfsc
must prepare for the next work . To make a whole dep is very meaningful for 
next step , though it is very hard work . The program conversion and 
unparser can depend on a whole dep and need not to consider dep files
separately . This make thing easier , don't you think so ?   

> >-- End of excerpt from Zheng Gengbing
> 
> 
> On Jun 13,  3:55pm, Zheng Gengbing wrote:
> > Subject: Re: token FNAME
> > On Thu, 13 Jun 1996, Li Xinying wrote:
> > >
> > > On Wed, 12 Jun 1996, Guansong Zhang wrote:
> > >
> > > >
> > > > >    I distinguish intrisinc func from user defined func is because the
> > > > > number of intrisic func is limit,we can deal with it just as the
> > > > > keywords.Of course we can also only return NAME , but this will lead to
> > > > > pression on yacc, because now the intrisic func , user defined func
> > > > > and array refrence are all matched to same rule. We must deal with them
> > > > > seperately in the yacc action: look up in the intrisic func table to
> > > > > check if it is the intrisic func name, if not ,decide whether it is the
> > > > > func or array ( I have not good idea to do this ).
> > > > >    Maybe we should do it as this method.
> > > > >
> > > > >-- End of excerpt from Li Xinying
> > > >
> > > > I am confused. In fact, I suggest two methods, which one do you mean?
> > > >
> > > > Guansong
> > > >
> > >
> > >     I think I have expressed above. This part of work should be added in
> > > the action part, that is hpf2dep, I think. Though it involves with
> > > semetic analysing, but it is related with the correction of AST building.
> > > So I prefer to hpf2dep.
> > >
> > > xinying
> 
> Sorry I don't grasp the idea at first glance. I think in above I have talked
> about the algorithm needed for solving the problem, the following is data
> structure. (Please note we do not decide to do so yet.)
> 
> The idea is to keep a "seen" symbal entry list during parse, as parser go
> inside out side a new scope or use some module (recursive to check all the
> module may be used) the contents of this list is changed. So when a new name is
> encoutered, first look inside the table, to see if it is a def/dec for array or
> for function, if not then consided it as a direct reference of a function. If
> the reference was renamed when use module, some mechanism needed for the new
> one to inhereit the old's features.
> 
> In fact, I think hpf2dep do some kind this work, the problem is that the scope
> to look up is not as full as described above. And the final guess is ARRAY_REF.
> (Or LOCAL?)
> 
> > >
> >
> >
> > 	In hpfsc , we already dealt with the intrinsic functions . So , hpf2dep
> > do did a redundent work on this . In intrinsic.f , we have a thorough
> > definitions of intrinsic procedure prototypes even include HPF extension
> > part . It 's more complete than the one provided in keywords.h .
> > 	Though , there maybe some loopholes in hpfsc , I believe we have
> > done the check unless we forgot .
> >
> 
> You are right. In any solution, the check in keywords.h is redundant.
> 
> And I think hpfsc can plug the hole by checking more place.
> 
> >-- End of excerpt from Zheng Gengbing
> 
> If I make myself clear in the above, I think we can decide on what we do. Still
> two methods:
> 
> 1. let hpf2dep take care of this (We do not support sepetated module
> temporarily). It is quite a clean way, but I am afraid too much work involved.
> Please make estimate on this.
> 
> 2. let hpfsc to deal this. In fact, this is just to implement the above
> algorith in the second pass. This doesn't mean hpf2dep need not to be changed.
> hpf2dep should leave special tag to indicate that the binding of def and ref is
> not complete, instead of making a guess as an ARRAY_REF. If the AST after
> hpf2dep is not a complete one, at least it should not be a wrong one.
> 

	In fact we have spent many effort on this . I think to make a
dramatic change is unafortable. We need only make some details more clear
like LOCAL or seen .

> Please make comments on this. (First let me know the current binding method
> used in hpf2dep and the meaning of LOCAL)
> 
> Guansong
> 

Zheng Gengbin