Subject: Re: module file is different from object file

From: Zheng Gengbing <[email-masked]>
Date: Thu, 20 Jun 1996 15:17:12 +0800 (EAT)

On Tue, 18 Jun 1996, Guansong Zhang wrote:

> I mentioned in previous letter that multi-file features in F90 have three
> aspects:
> 
> 1. include file
> 2. module file
> 3. object file
> 
> Please note, module file is different from object file when seperate compiling
> is envolved.
>

	What's include file ? Need we separate it from source file ?

> 
> On Jun 18,  9:11am, Zheng Gengbing wrote:
> > Subject: Re: binding
> >
> >
> > 	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
> >
> 
> Here I have question, if unparse at this point, we can not see j and k? Then
> the implementation of module file has its problem.
>

	j,k is there , futher more , if program t use k which is defined 
in module B , it will point exactly to the k symbol entry .
	In a word, j,k is in symbol table having the module statement bfnd
as their scope , but you cannot see it from unparser.

> > 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 .
> >
> 
> >From this, it seems we should unparse out something that cover all information
> in file 1 and file 2. (including integer j, and integer k). If this is the
> case, I see nothing wrong.
> 

	Only after link , file1 and file2 are integrated togather as program
module .

> >
> > 	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) .
> >
> >
> 
> We can not consider the thing ready to unparse as the final result of a
> compiler, it is only a result of a frontend. Right?
> 
> Guansong
> 
> 
> 
> 

Gengbin

---

From: Zheng Gengbing <[email-masked]>
Date: Fri, 21 Jun 1996 17:20:40 +0800 (EAT)

Hi,

	everyone , I am very glad to tell you that version 1.58 is ready.

	In this version , some dramatic changes have done to do the separate
compilation.

	This version have these improvement:
	1. configure is improved so that cache are enabled .
	
	2. Files in hpf2dep , hpfsc are adjusted to enable the config.h ,
		but I forget if I have changed the files in dump and unparse.

	3. separate compilation enabled :
	   use hpfsc -h , you can see the flag the hpfsc recognize .

	Testsuite contain a new dir -- mult , which derived from the black
hole problem , this is a demo for separate compilation.
After separate compilation , a file bh is produced , use unparse to this
file , you can see the result of linking .
	'make dep' enable you to see the mod file dependence .

you can enjoy it now .

Today , I have no time to explain further now ,

Gengbin