Subject: Re: About hpfcc

From: Zheng Gengbing <[email-masked]>
Date: Thu, 25 Apr 1996 09:10:42 +0800 (EAT)

On Wed, 24 Apr 1996, Guansong Zhang wrote:

> In this letter, I will explain my view of relation between hpfcc, hpf2dep and
> unparse.
> 
> On Apr 24,  8:59am, Yan Mi wrote:
> > Subject: Re: modification of IO
> > Hi,Zhang Guansong:
> > 	Will you please tell me whatis your purpose of yuor unparsing work?
> > It is like :HPF source program --> .dep -->HPF program? Do you work in
> > order to if our .dep has faithfully reprenent the source program ? Otherwise,
> > is your unparse  get another language program  from .dep of HPF? If your
> > purpose is the latter, I think you'd better unparse after hpfcc, because your
> > work need know explicitly about semantic and many work can't be finished
> > in yacc itself and hpfcc has complement many semantic information.
> 
> I don't quite understand your point. Let's think it in this way:
> 
> What a parser do? It generate the intermediate representation of a source
> program.
> 
> What a second pass semantics checking do? It check if the intermediate
> repersentation generated by the parser is correct.
> 
> So it is quite clear for us to seperate the process in two pass. The first pass
> for generating tree, the second pass checking if it is correct.
>

	Unlike C language , Fortran has its own features . As I think ,
to expect to construct whole AST in correct mode in the first pass in 
impossible .
	Something do have to be decided in the second parse . Let me give
an example , this case will always occurs in the forword-reference .

	PROGRAM main
	a = f(3)
	END main

	FUNCTION f(k)
	f=k+1
	END 

	Now , how do you know the f(3) is an array or a function call ?
So in the first parse , just let it be . We can decide the type of f(3)
only after yacc parse all the file , after that we can search the AST 
created by yacc , and find the function f  backwards.
 
	Anyway , this maybe is of no importance to unparser temporarily , 
because you can always unparse  array and function call in same look in 
HPF . But , please notice , if you want to unparse  this program to C , you 
will meet the trouble . 

> Well, the idea may be too pedantic to be practical, but it is not something we
> can not implement. If we don't do so, I'd say we have to admit that we don't
> well design the whole project together. Do we? I am responsible for the project
> in Jan, and know little about what is going on before that.
>

	We do expect to draw a clear line between hpf2dep and hpfcc ,but you
know it is something too difficult . It's determined by the features of 
Fortran and we seemed feel quite helplless . 
	Think about c , it give many method in language to resolve the
cases of forward-reference . Such as you must use extern to declare a 
variable if it was declared backword . And any fuction you call which is
defined backwords will be taken as int  type  output as default . 

> 
> But that doesn't necessaryly mean we should be slave of these codes. We can try
> to manage to make them a little clear, of cause, we also don't want to spend
> too much effort.
> 
> So I am trying to figure out how hpfcc do the work, and try to make a clear
> line between which things should be the first pass, which should be the second.
> Combining hpf2dep and hpfcc or not does not mean much, If the line is clear.
>
> Here we try to describe such a line:
> 
> On Apr 24,  4:11pm, Zheng Gengbing wrote:
> 
> > As I think if your
> > unparser are designed according to  the specification of AST , it will be
> > ok in most of case . That's mean perhaps in those cases that we changed some
> > AST specification while you are using the old defintion , you unparse will
> > fail .
> >
> > 	There is some subtle issues you must notice . In some cases ,
> > we will change the dep dramatically . But the change is still according
> > to the AST specification . I remember I have given this example :
> >
> > 	f(x)= x*3
> >
> > this is a statement function statement . this means it is a small function
> > declaration , not an assignment . In the first parse , yacc cannot tell them
> > apart , and you will find there is no STMT_FUNC_STMT bfnd in yacc .
> > So we must differentiate this kind of bfnd from ASSIGN statement bfnd
> > according to the context .
> > 	2.  yacc did not do very well to discrimnate
> > SUB_STRING from ARRAY_REF . We will check it out and reconstruct the tree .
> > 	3.  when yacc fail to discrimnate a func call from  a array type
> > such as  a(1,2) , it's our task to check it out and convert the ARRAY_REF
> > tree to FUNC_CALL tree.
> >         4.  ...
> >
> > 	From the points above , you can find though we changed dep , we are
> > still based on the AST specification . So if your unparse can unparse all
> > the bfnd specified in AST , it certainly can parse the dep processed by
> > hpfcc.
> >
> > 	So , the most important thing is that our work are all based on
> > a same AST specification .If that is the case , we certainly need not
> > worry about the binding our work .
> > 	I think in many times we both sides modified yacc actions to change the
> > AST in one_side without consider the other side . It is not strange that we
> > will meet trouble when we merged our work .
> >
> >-- End of excerpt from Zheng Gengbing
> 
> >From this, I get the idea that hpfcc is not something I described as a second
> pass checking, it also involved in build up the syntax tree. In another words,
> the building tree need two pass to finish. The second pass also check the
> semantics of the source program.

	Yea , that's what I mean . And this seems inavoidbabe , can we ?

> 
> In this case the line I discribed above is within hpfcc itself. The output of
> hpf2dep is meaningless, though it is a AST but it serntainly an inaccurate AST.
> Unparse before hpfcc also become meaningless (the tree is not finished) though
> it may produce a right looking output.

	I am glad you have somehow understood the work of hpfcc , but 
to say that the AST produced by first parse is meaningless is so pessimic , 
most of the AST is well built . And to unparse a AST which is not be semantic
checking is also meaningless , why must unparse before hpfcc ?  The output
of hpfcc is really the outcome of compilation of HPF frontEnd , don't you
think so ?

> 
> If this is the case, I hope the hpf2dep and hpfcc to be combined together as
> one program. Let them sseperate doesn't make sense.
> 

	We certainly will combine them in the future , but it also does
not matter if we make them apart. 

> If we still want to emphasize an seperate semantics checking part, my
> suggestion is to split the hpfcc, add the first part to hpf2dep, while
> remaining the second part as a new hpfcc. Of cause, if doing so is possible.
> 

	You know some semantics checking depends on the information which
can only be obtained after yacc parse all the file. That is the problem
we must face to.

***************************************************************************
*     Zheng Gengbin                 *                                     *
*                                   *                                     *
*  Dept. of Computer Science        *  Phone:  86-10-2585088              *
*         & Technology              *  Email:                             *
*                                   *      [email-masked]   *
*  Peking University P.R.China      *  Mail:                              *
*                                   *      Room 1077 ,Building 47,        *
*                                   *      Peking University, P.R.China   *
***************************************************************************