Subject: Re: binding

From: Zheng Gengbing <[email-masked]>
Date: Mon, 17 Jun 1996 18:03:13 +0800 (EAT)

On Fri, 14 Jun 1996, Guansong Zhang wrote:

> On Jun 14, 10:37am, Zheng Gengbing wrote:
> > Subject: Re: Multi-files
> >
> > > > 	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 ?
> > > >
> > >
> > > You have your point, I think I fully understand it. But here is mine.
> Please
> > > think this again.
> > >
> > > Let hpfsc to generate the .dep for a whole program prevent further seperate
> > > compiling method. Suppose we are going to use hpf program to solve a big
> > > problem, it cerntainly possible to wirte several .f files. Now before
> > > generating node program for the project, every .f need to be changed to
> .dep
> > > file, and more, they need to be merged by hpfsc file to get a correct AST,
> > > (Here, I am not sure about how hpfsc need to change the .dep file, so I
> > > emphasize "correct", if without merging all the .dep files together, each
> > > individul .dep file is also correct, then this question is less serious
> than I
> > > thought.) then it is impossible to generate seperated node program to be
> > > seperate compiled by the node processors compiler. Right?
> > >
> >
> >
> > 	Well , hpfsc ensure that .dep is always correct . It always contains
> > all the information it needs , even the temperary symbol entry of the mod
> > files are also include . Before link , nodes which point to the symbol
> > outside its file will point to these temperary symbol entry .
> > 	After link , these temperary information are deleted , and all nodes
> > will point to the right symbol .
> >
> > 	And as to  unparser , I cannot see the different . I have done the
> > test , unparser can see almost no difference . The dep compiled separately
> > is the same as before , only mod information are added when necessary which
> > keep the dep complete .
> >
> 
> The thing I am concerned have nothing to do with unparse, unparse can do a good
> work as long as tree link is ok.
> 
> Now I am suggesting we make a clear definition of each ST entry. It is
> fundamantal to any further compiler work. (In another words, if we decide to
> support seperate compiling, we have to make the user understand the def of the
> temperary entry you mentioned, and the def should be a complete and consistent
> one.)
>

	The temperary entry is the same as the ordinary ST entry , the type is 
also PTR_SYMB . It is the struct when write into files are different . 

> > 	The point is that if a user don't link dep togather ,he cannot continue
> > his work  of the compilation , but he can always unparser every dep file .
> >
> 
> The question is, can he generate node program for this .dep file? That is real
> seperate compiling! Please note this point.
> 

	It seems that we have a diverge on this issue. As I think the object 
file should be .dep while you think it should be .f or .o after unparse . 

	Because I think only after all .dep link to a complete dep , can some 
program translation work  be conducted .For example because f77 do not 
support contains , the subprocedures in contain block must be taken out , 
so we must check globally if there is duplicate name after it is taken 
out.

> > 	So .dep match the .o files in convention . and the a.dep.out generated
> > after link correspond to the  executable files , except it need further
> > process of the compiler .
> >
> >
> > > And one step more, this may cause it is impossible to build up a hpf lib,
> like
> > > one in Fortran, for some special application.
> > >
> >
> >
> > 	I cannot see the reason .
> >
> 
> The problem is. If a seperate .dep file can not be used to generate node
> program, the useful hpf subroutines can not generate node program, and can not
> be compiled to real .o file, then we can not get a real .a file for a special
> machine. (Maybe I don't make myself clear, a hpf lib should be machine code,
> not a .dep file.)
>

	In that case, since all the information needed by the  seperate .dep 
file is contained in the corresponding dep file , I cannot see why we 
cannot generate node program. But don't expect to get the full global 
information then . I think this limitation will somewhat block our work of
unparser it to f77. 

	In fact , we should consider not only the explicit parallel language
component in HPF , but also consider how to convert the f90 features to f77 
such as interface , contains and pointer.

> >
> > > So, my suggestion is that we do not implemented in this way.
> > >
> > > Don't think this is an easy work. To support seperate compiling (I mean by
> node
> > > processor), to make the seperated .dep file meaningful is more difficult
> than
> > > make a whole .dep file meaningful. That's why I insist that we make a clear
> > > understanding of our binding method used currently, and a better one for
> the
> > > next step.
> > >
> > >
> >
> >
> > 	It do is very hard work . I think I have done a helpful test .
> >
> > You are right when you say to make the seperated .dep file meaningful is
> > more difficult than  make a whole .dep file meaningful. But I am almost
> > succeed . And that even we have no clear  understanding of our binding
> > method used currently won't prevent us continue the work , they are just
> > details .
> >
> > Gengbin
> >-- End of excerpt from Zheng Gengbing
> 
> Then you muse find good definition, and not far from the current ones. Please
> formalize them and let HIT and me know. That is a quite meaningful work.
> 
> The following is binding method previously, I quote from HIT.
> 
> On Jun 14,  8:44am, Li Xinying wrote:
> > Subject: Re: LOCAL
> >
> > First,I present my thought about "sub1"(function refered and defined)
> > during my constructing AST. Becuause the building of ST and AST are doing
> > at same time, it is difficult to check the refered function has been
> > defined or not. So I build a entry of ST when I encounter a function
> > name,and left the further explicit work to sementics. At that time no
> > other one was concerning with this problem. Hence, I decided it by
> > myself. And my thought about the further explicit work includes two ways:
> > one is if sementic analysing finds sub1 is refered and defined ,it will
> > get rid off one and only leave one entry in ST; the other is to leave
> > both of them, while indicated one is refered and one is defined, but
> > notice: we should think of the fact that it will be refered for many times.
> >

	In fact we use the first principle when semantic check ,we always
use the def node to replace the ref nodes .

> > xinying
> >-- End of excerpt from Li Xinying
> 
> Guansong
> 

Zheng Gengbin