Subject: Re: discussing on T_KIND

From: Zheng Gengbing <[email-masked]>
Date: Sun, 21 Apr 1996 10:09:34 +0800 (EAT)

On Fri, 19 Apr 1996, Guansong Zhang wrote:

> On Apr 19, 10:23am, Zheng Gengbing wrote:
> > Subject: Re: T_KIND
> > 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 .
> >
> 
> I only try Vdumpdep once, because it cause memory fault for almost any program
> (I try several, all memory faults), I don't try it after that. Then our focus
> is on developing the basic things first. I let pku and hit to care their
> special things yourself.
> 
> >
> > 	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 .
> 
> This is the thing I am really afraid of, I guess every time pku want to do
> semantice checking on type, you will use the way according to your definition.
> 
> >
> > 	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.
> 
> But for this T_KIND adding new string won't solve the problem, you have to
> change the string "%TYPE" to "%TYPE%IF(%LL1!=%NULL)%LL1%ENDIF". That means if
> ll1 is not null, unparse it.
> 
> And then changing the way unparse interpret the %TYPE.
> 
> > 	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 .
> 
> I think it will work.
> 
> In this case, unparse will travel ll3, and still need to change the way it deal
> with %TYPE: when meeting T_KIND do nothing at all. Or just do as I have to do
> now, don't care about ll3, when meeting T_KIND, find out its base type to
> print.
> 
> Yet this method do solve the problem exists for dumpdep at some extent. Because
> it can be seen from dumpdep what the base type is, while the drawback is that
> it also print out the information of a repeated T_KIND.
> 
> I think the best way is to get rid of T_KIND, and let the TYPE_OP's type point
> to a basic type. By allowing TYPE_OP's ll1 pointing to an expression, you can
> always figure out whether this is an old T_KIND.
> 
> For example, grep T_KIND in src/hpfcc, you will find
> 
> if (lp->type->variant == T_KIND  && rp->type->variant == T_KIND) {
> 
> if change it to the following,
> 
> if (lp->ll1!=null && rp->ll1!=null) {
> 
> is it going to work?
> 
> For those use type variant derectly (near 20 places), is it always possible to
> make similiar judgement at type's parent level?
> 
> How do you think about it?
> 

	I'd say you do not quite understand the program we write and how
the AST is constructed .
 
I will try to explian it , but I am not sure I will make myself understand,
  We donot use the TYPE_OP any more after we parse the VAR_DECL . We only 
refer to the type pointer of symbol to check the exprssion .
	
     If we get rid of T_KIND , we lost the type to indicate if a variable
is a kind . We also need the inforamtion of the kind expression value to
check if a assignment is legal . And to find the bfnd where you decalred
the symbol and parse the llnd to get TYPE_OP is impractical .
	
	And what you mean we can check lp->ll1 ? what ll1 contains is according 
to the defintion of AST . That 's not for type . We need to check the 
type pointer of a llnd (the type of llnd is added by us ) . for example:

	a =  b+c * f

the llnd of right hand side is

                     +
                     |
                 +--------+
                 |        |
                 b        *
                          |
                       +-----+
                       |     |
                       c     f

 We have expaned the llnd to contain a type pointer .
 After we parse the expression , the llnd of + will contain a type which
is the final type . We will use this type to check if it is assign compatibal
to the left hand side variable .

	If we deal the problem like you , how do we process the T_KIND type 
in an expression ?

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

---

From: Zheng Gengbing <[email-masked]>
Date: Mon, 22 Apr 1996 16:40:11 +0800 (EAT)

On Sun, 21 Apr 1996, Guansong Zhang wrote:

> But TYPE_OP has been recorded there, you can always retreive it.
>

	I did not make myself understood . We never use TYPE_OP after we
parse the VAR_DECL bfnd . That's why we must use T_KIND to record the type.
And to retrive type from the declaration bfnd is impratical , because in 
that case we will store a bfnd in every declared symbol , but we only have
type pointer to store the type .How can we retrieve the bfnd where I declared
the symbol ? The only method is to scan every bfnd is a scope , that's
terrible .

> 
> I don't make myself clear: I mean when ever you meet a TYPE_OP, see if its ll1
> is null, if it is, then it is an old kind of TYPE_OP, its type will point to a
> basic type; if not, then it is a T_KIND, this time, you can still use its type
> to point to a basic type, while letting its ll1 to express what kind this
> TYPE_OP is. Right?
> 
> I don't think this will affect the necessary definition used in bellow.
> 
> Our focus is whether we need a new base type.
> 
> If we allow T_KIND, then we add a new basic type. What I mean is that it is not
> necessary (also cause trouble for dumpdep & unparse). We can use the old
> TYPE_OP to express this new thing good enough.
> 
> If you insist on using T_KIND, we need to change dumpdep to dump more
> information for T_KIND, like it does for T_ARRAY. (I have noticed that, in this
> case the base_t in T_ARRAY doesn't mean basic type only, it also include
> T_KIND, which will link the T_ARRAY to a basic type.)
> 
> Do I understand the situation right?
> 

	I think to discuss this problem any more is useless . If we do have
a method to solve it , and the method is applicable, let's implement it 
then .