Subject: Re: binding

From: Zheng Gengbing <[email-masked]>
Date: Tue, 18 Jun 1996 09:11:39 +0800 (EAT)

> > > >
> > >
> > > 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 .
> 
> Yes, that is the problem. Though we may have different opinion on this. Here I
> want to emphasize my point of view.
> 
> A .dep file can not be viewed as an object file when seperate compiling is
> envolved, at least, in general sense.
> 
> When we got a .dep file, we only got an internal representation of the source
> program. We may do a lot work a semantics checking to get a better, more
> accurate one, but it does not mean we start the compiling work, right?
> 
> Then how can you see it as an object file when thinking about seperate
> compiling?
> 

	I am afraid you always think things easy . After we unparse HPF to
f77 source code , we actually lose the control then . We have to depent 
on the f77 compiler to do the semantic checking when linking , which is 
not quite fit in some cases .

> Strictly speaking, we can devide the compile process in two steps, first got
> the representation, second transformation, which correponding to frontend and
> backend work. A .dep file is only a result of the first step (unless you have
> got the compiler output program's .dep, with unparse command, it can be turned
> into a .f file), the heavy work of compiling does not start yet!
> 
> Though hpfsc do a lot work on .dep file, but we do not design it to start
> compile work, do we?
> 

	Ideally , I also don't want to bother to do the work of merging , but
if you don't foresee the problem , you will meet the trouble .

	Of course , if your goal is to translate f77 + HPF directive (somewhat
like Fortran D) and do not concern the f90 features , the work is relatively
easy . 

> So after hpfsc the program should be a complete one can not reflect our efforts
> on seperate compiling. (Of cause, we may decide not to support seperate compile
> at all.) Please think it over.
> 
> > 	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.
> >
> 
> You have your reason. Again, I will insist on my point. Think about comercial
> compiler, they can do seperate compiling, righ? So there must be someway to
> deal things like this.
> 
> As to this particular problem, a special naming system may solve it: try to
> rename the procedure take out as something no one will used as a name, and it
> is safe to move it out. I am sure there are other methods to deal with this.
> 

	How can we dare to say no one will used the name if we have no global
information. 

> >
> > > > 	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 .
> 
> Do the compile work without global information, that is seperate compiling,
> right?
>

	You have not understood what the problem is yet.
	I have no objection that we cannot do the seperate compiling of each
file , the problem is to the unparser . Unlike cc or f77 compiler , they
have the full control of all the intermediate information ,while we lose 
them after unparse HPF to f77+MPI , so to the unparser , we must have 
enough even the global information to do the compilation , otherwise we 
lose them forever , because unparser is the last stage we can access to 
the intermediate information we created .  

> 
> > 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.
> >
> 
> I don't understand you well on above. Why you consider F90-to-F77 is something
> different from our compiler work? In my mind, there is nothing quite different
> from compiling HPF program if only seperate compiling is concerned. In fact,
> you can view HPF program target one machine as F90 to F77 in our effort, if we
> choose F77 program as node program of HPF.
> 

	Translate HPF to f77 + MPI include the work of translating F90 to
f77+MPI . They will be some difference from to translate Fortran D to 
f77+MPI, right ? We actully must implement a F90 translater as well .	
In fact , prof.Li 's papers have dealt with some explicit parallel component,
like forall , where , but it seems that we have no consistence how to deal
the f90 features like contains , interface and pointer .
and I don't think this work is easy.	

> Changing full F90 to F77 is also a compiler work, we can not expect simple one
> pass travel of AST will solve the problem.
> 

	So some global information is needed , I am afraid . My opinion 
is to unparer from a complete whole AST is better.

> 
> > > >
> > > > > 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 .
> >
> >
> 
> I am still not sure if you understand me. No matter which way we use, if we
> want to claim we support seperate compiling, we need a way to support def and
> ref in different files, cross-reference may be a more accurate name for this.
> 

	I will fully explain the separate compilation strategy below:

for an example :

file1:

module A
integer j
end

module B
use A
inther k
end

file2:

program p
use B
end

after compile file1 use -m flag , two mod file is produced A.MOD and B.MOD .
a.mod contain such information :  symbol j, type : integer 
b.mod contain these information : symbol k, type : integer , use module A

when compile file2 ,  hpfsc find mod file b.mod is needed and try to load 
it , then before loading , it find a.mod is also needed . So , hpfsc decide a
sequence and load the a.mod first and b.mod next .
after load , hpfsc creat two virtual bfnds at the end of the file2 , now
the unparse of file2 is :

program t
use B
end

module A
end

module B
end

notice 2 virtual module blocks is created in AST , the corresponding symbols
are then hung on these two bfnd , so that hpfsc semantic checking cannot see
the difference . 

	In some sense , you can do the unparse on this file2 now ,
But when do the AST conversion , I think the information in this file is not
enough , we also need the information of other modules (other than file1) . 

Gengbin