Subject: Re: binding

From: Zheng Gengbing <[email-masked]>
Date: Wed, 19 Jun 1996 09:30:26 +0800 (EAT)

On Tue, 18 Jun 1996, Guansong Zhang wrote:

> It seems our discussion divers from FNAME problem to seperate compiling!
> 
> Well, I am quite glad to have discussion with you on compiler issues. I will
> check your example program further to make more comments.
> 
> As to FNAME, HIT also think it is not necessary to have a special name for it.
> We can remove it from lexer, this will make linux pass.
> 
> The problem is that, NAME() should be a function instead of array if not only
> ref show up in a .f file.
> 

	Yes , I have adjusted the hpfsc , so that if hpfsc cannot decide that 
the NAME is array , it is considered function ref. I mean when hpfsc said
it is not array , it have search all the modules the current scope used ,
even the modules defined outside the file .

> In fact, I can not present ideal solution to this problem yet. Because in
> current situation, the ideal solution should be one not cost much effort while
> get rid of the problem. I have no difference with you on this point.
> 
> So all I am talking about in previous letters are only suggestions. I think if
> we consider NAME() as function ref instead of array ref when no def is given
> will remain the possibility of further seperate compiling. And whether seperate
> compiling or not, simply treated as array ref in hpf2dep certainly is wrong.
> 
> I know the def in module may complicate the situation, in fact that is the
> thing I hope you can make decision. Based on the work has been done in hpf2dep
> and hpfsc, you can decide in which module we check on this.
> 
> We may leave the question on how to do seperate compiling for a while, then the
> question comes as this: why semantics checking need to access global
> information to get an accurate .dep file? In any compilers this was done when
> obj file is generated, which means they do not have global info yet.
> 

	I never said hpfsc need to access global information , what I
emphasis is that hpfsc should prepare for the next step - program conversion.
I believe program conversion must depend on some global information .
And in fact global semantic checking do lost if we keep .o as object .
Think the compile step as you concieve :

	hpf2dep file?.f
	hpfsc -c file?.dep
	unparse file?.dep
	f77   -c  file?.f
	f77  -o file   file1.o file2.o

Then we have depent on f77 to do the global checking when linking , but 
that is not enough. hpfsc cannot access to the AST when f77 do the link work.

> If you look thing in this way, you will see my point more clearly.
> 
> As to the detailed way of how to support seperate compiling, we can keep
> discussion.
> 
> 
> Guansong
> 

Gengbin