Subject: Re: T_KIND

From: Zheng Gengbing <[email-masked]>
Date: Fri, 19 Apr 1996 10:23:59 +0800 (EAT)

On Thu, 18 Apr 1996, Guansong Zhang wrote:

> 
> Now I understand the above, why you say Vdump is more accurate then dumpdep.
> 
> I don't pay attention to this claim at that time. But now I'd say I made a
> misunderstanding.
>

	Then Vdumpdep can execute on your machine ? Please give me the 
comments .

> First let's see what dumpdep is.
> 
> dumpdep is difficult to read, but it must be accurate, it must reflect all the
> useful tree link feild in the internal structure, other wise, what we need it
> for?
> 
> So suppose you add a def for the internal structure, you must at least let
> dumpdep to know it (then unparse). After that, we can say the new def is
> implemented, right?
>

	Since I have no time to maintain so many files at same time , I prefer
to maintain the program I wrote intead of dumpdep which is wrote by sage . 
	I 'll modified dumpdep  in some days .

> Therefor we can not say the def for T_KIND now is implemented.
> 
> Right now, the def for T_KIND is not only a problem on dumpdep, (it's sage's
> convention that no son as llnd is added to type node. so dumpdep don't know
> when to display detailed information for T_KIND) but it also presents a problem
> for unparse. I will try to explain it bellow.
> 
> Remember I intruduce the way unparse do its work, it was called table-driven
> method, so tag TYPE_OP will correspongind a string for unparse to interprete,
> in this case the string is %TYPE. unparse see this string, it will go along the
> link to type node and see what kind of type it is, to print out the
> corresponding "real", "integer", etc. Please note, at this level, there is no
> string to interperate, this time it is C code.
> 
> In fact, unparse follow the way sage do the work, only basic type (the first 9
> kind of node in type node list) can be unparsed with string %TYPE, if we hope
> to finish the work fast. Other wise I have to write a special rontine for this
> T_KIND.
> 
> So, I don't know if it possible for you to change the definition a little, then
> it will make dumpdep work and unparse work easier.
> 
> The following is my suggestion for def of decl like bellow statement, in this
> way, I think we can solve the problem quite well.
> 
> integer(SP) i
> 
> in this situation, VAR_DECL will have ll1 and ll2 as sons and ll3 null, we can
> use this ll3 to express things like (SP), while let ll2 to point to the basic
> type node, instead of T_KIND.
> 
> If ll3 is reserved for other reason, we can let ll2 point to an EXPR_LIST, in
> which ll1 is basic type and ll2 is used for things like (SP).
> 
> In either above way, I think both dumpdep and unparse will work more smoothly
> than now.
> 
> I don't know if pku has special need for T_KIND. Even if you have in semantics
> checking, it is still not difficult to retreive the information in above mode.
> Right?
> 

	I think your suggestion is impratical for this reasons :

	 this modification concern not only yacc , but also the parse 
 of hpfcc . We will spent more needless strength to change all the 
correspondent codes both in yacc and hpfcc than change only unparse . 
Since now we have debug all the known bugs of T_KIND in project , to change 
them carelessly will cause trouble . 

	I'v read the source code of unparser . I think it is not difficult
to add a new type like (T_KIND) . You have to define a new  string to
inteprete by unparser. 

	If that is't help . Then let's use a compromise one . We change
yacc to let ll3 point to the base type , instead of T_KIND . and leave ll1 
& ll2  unchanged .

wait for you comments ,

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