Subject: Reply

From: Zheng Gengbing <[email-masked]>
Date: Tue, 2 Apr 1996 11:48:36 +0800 (EAT)

On Mon, 1 Apr 1996, Guansong Zhang wrote:

> Hi,
> 
> I like to know how you hpfcc works. So we can merge the two work to gether.
> Here is a question list:

   It's better to leave this work for us to merge the hpf2dep & hpfcc , 
because there are some details about the work which cannot be said by letter.

> 
> 1). Does hpfcc change the input? I mean supporse there is .dep file is the
> input of hpfcc, then the output of hpfcc is as same as before?
> 

  The hpfcc does change the input for these reasons :
  1.  The AST are inavoidablly wrongly made by the first parser , such as
	in first parse , you cannot tell the statement function statement ,
	such as  f(x) = x*7 , from the array assignment .  In this example ,
	the variant of bfnd must be changed from ASSIGN_STAT to STMT_FUNC_STMT.
	In other cases , even the llnd tree must be reconstructed.

  2.  In first parser , some information are not be filled in AST , such as
	the attributes of the symbol table , for example :
		TYPE atype
		   SEQUENCE
		   INTEGER  i,j
		ENDTYPE 
 	in this example , the sequence attributes are not processed by first
	parse . We must fill this attribute to atype .
	   another example:
		FUNCTION f(x,y)
		INTEGER f
		END FUNCTION
	In this example , the parser make two symbol of variable 'f', our
	work is to merge the two symbol entry and fill the attributes. When
	we meet these problems, sometimes we solve them in our hpfcc ,
	sometimes we change the hpf2dep directly . 

   3. Add the intermediate result of our parse to AST tree . 
	when we parse an expression , we have already decided the type of
	each node , and we save these information in .dep. 
	
	In one word, our goal is to make sure that the ASTs are  correctly 
made and record the information produced by intermidiate process . 

> 2). If not, how hpfcc affects the .dep file? Whether the pointers among nodes,
> such as bfnd, llnd, are changed? In another words, if an unparse program can
> unparse the results of hpf2dep, can it also unparse results of hpfcc?
> 
	
	I cannot imagin if an unparse program can unparse the old version of
hpf2dep of HIT , because the bfnd , llnd , especially the symb table are
made incorrectly in some place .

	As i think, the unparser need not care about if the result(.dep) is 
produced by hpf2dep or hpfcc , it really do care of how the AST is constructed. 
The goal of hpf2dep & hpfcc is same .The unparser only take the correctly made 
.dep as its input . So, since we will merge the hpf2dep & hpfcc in the 
future , the unparser should take the  result of the second parser (now hpfcc) 
as its input . You can assume that what hpfcc does is to correct the AST 
nodes produced in first parse , check the sematic errors and do some 
analysis which produced some results.

> 3). .y file is changed, could you tell me how this affects the results?
> 

	These changes are important , in the letter before I mentioned some
cases we changed the  .y & some other files in hpf2dep and basicop .
We changed the .y only to produce correctly made AST , not mean to change 
the constructure of AST made by HIT , although we do change some AST 
constructure , that's because our miss when we first conceive the constructure 
of the AST . 
	There is a brief description of our changes to AST tree:
  in ll.h:
	add two field in PTR_LLND :
	. attr : this carrys the intermediate attributes when parse an
		expression.
	. const_val: this carrys the intermediate result of the computation
		of a constant exprssion.
  in symb.h
	add 5 fields in PTR_SYMB :
	. use_list :  use link made by parser.
	. common_table : common block table.
	. cml          :  common link
	. EQ:		  equivalence link.
	. MR		: equivalence ring .
	modified the attr filed of SYMBOL from u_short to int type .

  we also changed some AST constructures:
  1. add new variant T_KIND of type. 
  2. T_STRING : if the length is specified , T_KIND instead of T_STRING is
	created , and kindexp(LLND) point to the expression of the length .
  3. a new variant LOGIF_STMT from LOGIF_NODE.
  4. a new variant INTRIN_FUNC_CALL of bfnd to tell the intrinsic func call
	from ordinary func call.
  5. add STMT_FUNC_STAT of bfnd to process the function statement.
  6. add new T_PROCESSORS & T_TEMPLATE type to record PROCESSORS & TEMPLATE
	hpf directives.
  7. ...
	
  For recording the intermediate result , we changed the dep_struct acordingly. 
I also updated the readnodes.c and writenodes.c to follow the same structure.

> 4). We can see more conflicts reported by yacc, (9 rules never reduced), Does
> things like these affects the language which parser can recognize?
> 
	
	These changes have been carefully debugged .I cannot see the wrong 
effects.
     You can believe the correctness of our changes , because if the .dep are
wrongly made by the first parse of HIT although a very small error , our 
work of second parse cannot go through . That is also the reason why we changed 
the parser of HIT directly instead of spend time waiting the modification of 
HIT .   

> Guansong

	I'v succesfully compiled unparse by gcc . I added  some fields in
symb.h , because your unparser use some union fields of TYPE which we no 
longer use in hpf . Due to the same reason I mentioned before , I add 
__builtin_va_start() in unparse.c .

      I tried some sample files . What i found are :

	1.  some statement not recognized , such as CYCLE , EXIT . (z1.f)
	2.  T_KIND not supported ,both in type definition and exprssion which 
	  is not provided in sage++ .
	3.  Intrinsic functions cannot be recognized . 
	4.  Contains not supported. The contains block is lost in the result
	  files.
	5.  Construct name of if structure lost . (z7.f)
	6.  Do structure produced by unparse are different from the original
	  files.   (z9.f)

     In one word , the extentions added by HPF are processed not good.
     We can contact details of these bugs later one by one , if you want to 
correct them .

	Since this version of unparse only convert programs of HPF to HPF,
many details of the constructure of AST are ignored . If we want to convert
HPF to maybe F77 & MPI , we need more details of knowledge of the AST ,
such as the intermediate results of align and distribute .

	I also modified some places in hpfcc & hpf2dep , I made a compresed
version called the same name in the home dir today ,it has a little 
difference from last one . Please get it , and find if the hpfcc core dump
again.

***************************************************************************
*     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   *
***************************************************************************