Subject: Re: Multi-files

From: Zheng Gengbing <[email-masked]>
Date: Fri, 14 Jun 1996 10:37:02 +0800 (EAT)

On Thu, 13 Jun 1996, Guansong Zhang wrote:

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

	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 .

> 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