Subject: Re: Forwarded mail....

From: Zheng Gengbin <[email-masked]>
Date: Thu, 12 Sep 1996 16:47:41 +0800 (EAT)

On Wed, 11 Sep 1996, Guansong Zhang wrote:

> Hi,
> 
> Here are 2 points concerned with Sage++ lib.
> 
> a. Without major modification, Sage++ lib can be put on our frontend. And my
> forall compiliation is based on them.
>

	I hope you can inform me the modification so that we can merge
our work togather and  work out a unified version .

> b. More detailed things need to be known, if we want to build up a better lib
> to use. (In fact, you will find a lot of problems in the original version.)
> 

	Yes , I have read some codes of sage++ lib which I think is important 
. 

> I also like to know your idea about Sage++ and the lib to be built.
> 

	It's clear that we need not to build a brand new lib of our own . We
can simply borrow it from sage++ . But we must be familar with how the 
lib is working . Liyu and I will be the men who is maintaining  the lib.

	I have a question here , since sage++ call some c functions which 
are defined in low_level.c and unparse.c , I wonder if your lowa.c and 
unparse.c ( in /tools/unparse ) are equivalent to those two files . I 
notice that your lowa.h is 3000 lines less than the low_level.c of 
sage++ . 
	In order to perform our little example , I appended the deleted 3000
lines in file lowa.c . Now I successfully compiled this example:
//
main()
{
        int i;

        PtProject p("t.proj");
        PtFile  *f;

        f=&(p.file(1));

        i=f->numberOfFunctions();
        printf("%d\n",i);
}
//

	the result of running is also quite good .

Zheng

---

From: Zheng Gengbin <[email-masked]>
Date: Fri, 13 Sep 1996 15:46:04 +0800 (EAT)

On Thu, 12 Sep 1996, Guansong Zhang wrote:

> On Sep 12,  4:47pm, Zheng Gengbin wrote:
> > Subject: Re: Forwarded mail....
> >-- End of excerpt from Zheng Gengbin
> 
> You are right. lowa.c is part of low_level.c.
> 
> >From what you said I think that your work on Sage++ just begin. The situation
> here is that I have written 4,000 of C++ code based on Sage++. But the problem
> is that my focus is not Sage++ lib its self. Whenever I found a way, I don't
> care whether it is good or bad. I know this is not good. But I have a deadline
> to finish the work. I can not care too much.
> 
> Now we can discuss together about Sage++ lib if you like. And I also can send
> all the modification code here to you, of course I will do my best to explain
> why I made those changes. (I don't think I can finish them with in one or two
> letters, we need work on it for some time.)
> 
> I also hope to know your plain on it. So we can work out a better one.
> 

	My plan now include 2 steps:

	1.  modified sage++ to fit our AST and directory structure . (done)
	    This include making a new directory (temperily called hpf++ ) ,
	    adding new head files and producing lib files (.a) . In one 
	    word , modified sage++ in our use. 
	2.  add new BFND classes and LLND classes to sage++ .  (almost done) 

	then next I will merge our change togather and do some test . After
that I think I don't want to pay more effort on this lib , but I will keep
maintaining it .

	During summer vocation , our progress became lagged than you . 
Now we are trying to keep up with you . I think we are about to do 
some actual work now. 

Zheng

---

From: Zheng Gengbin <[email-masked]>
Date: Mon, 16 Sep 1996 10:17:01 +0800 (EAT)

On Fri, 13 Sep 1996, Guansong Zhang wrote:

> In this letter, I will describe dir struncture and files I used in Sage++.
> 
> >From a compiler point of view, a frontend itself is useful only we have some
> basic functions to operate on the internal structures it builds up.
> 
> We can easily find the problem exist in our frontend that the functions in
> src/basicop is limited and most important, not intend for compiler writers (too
> much details need to know to use them.)
> 
> I think Sage++ class library is built just for this reason. So when you want to
> build up a declaration for array, you do not need to understand that how each
> subscription is linked together.
>

	Yes , that's why we use sage++ .And the design of sage++ is esay for 
maintaining , I think .

> Based on this, I set up a dir named basicopxx parrallel with basicop in our
> front end. And copy all the necessary files from Sage++ lib into this dir.
> These include not only .C files but also .h files and .c files. They come
> different dir in old Sage++.
>

	I don't think put .C and .c togather is good . I prefer to build 
another dir to produce some lib (.a) files .

> Then a basicopxx.a is built up with a simple Makefile (I have no time to
> improve it yet).
> 
> The idea is this, any compiler user can use Sage++ function if this xx.a lib is
> linked.
> 
> One problem arise here. Sage++ itself is based on Sigma, a C function lib. In
> this C lib, it includes unparse which our HPF frontend unparse come from. When
> I develope unparse for our frontend, I already cut off useful code from this C
> lib. And many change was made in our unparse. So I don't do extra work to link
> them again. In addition, if unparse function is linked back, the overall
> structure of the front end is not clear (unless we do some further add just,
> say put the unparse and dump module in basicop let things under tool dir just
> call them, that will be too much for that time.)
>

	That's a problem . My resolution now is adding those useful codes back
and link 7 .o files in our tool/unparse dir . But I also don't think that is
a good resolution . How about put .c files in a new dir such as /transop ?

> But the drawback is one of useful Sage++ function can not be used: unparse sage
> class to a string buffer.
> 
> To keep our frontend dir structure clear, I don't put any new .h file in
> include dir, the reason is that I can not explain the meaning of these file
> yet, and the way that compiler writers need to use these .h files is not
> figured out. They just been put all in basicoxx dir for the time being.
> 
> But the following .def files
> 
> bif_node.def  symb.def      type.def
> 
> were needed. You will find them defined the properties of the different nodes.
> These files are used by unpare, and I have already made many changes. So they
> should be put under include dir. Though I don't do so yet, I just have another
> copy and keep them same as the one in unparse dir.
> 
> Ok, that is all about the files and dir structure of my work. I will send a tar
> file to you when I found disk space to do that.
> 
> And then you can link it to our front end.
> 
> Guansong
> 
> 

Zheng

---

From: Zheng Gengbin <[email-masked]>
Date: Mon, 16 Sep 1996 15:52:17 +0800 (EAT)

On Sun, 15 Sep 1996, Guansong Zhang wrote:

> On Sep 15, 10:13am, Xiaoming Li wrote:
> > On Fri, 13 Sep 1996, Zheng Gengbin wrote:
> >
> >    The name hpf++ may confuse people. How about Xsage (for extended sage) ?
> >
> 
> Here, this dir was named as basicopxx, which means it is a C++ extension to the
> basicop in our original dir structure. In fact they are also different kinds of
> operations provided on AST and ST.
> 
> But I don't make any portibility effort yet. So if we want to put this lib in
> our frontend, no matter what name, we need to think about this. The orignial
> frontend can be configured to run on 7 different platform and operating
> systems.
>

	If we use g++ , I think propably we have no portibility worried .
In fact in HP , we have successfuly compiled the  lib .

> What is your plane on this new dir? (My work now is on RS6000) Please let me
> know. Should we consider this lib part of our frontend?
>

	I think the lib should be a part of our frontend , because it really
is wrap of our AST with operations . And it cannot exist without the 
frontend .

Zheng

---

From: Zheng Gengbin <[email-masked]>
Date: Tue, 17 Sep 1996 10:02:36 +0800 (EAT)

In general , I agree your division of the sage++ lib to 4 parts :
	1. low_level
	2. base class 
	3. derived class
	4. attributes  

	Rather than divide class definition into base or derived class , 
how about divide them according to the type of AST nodes , such as statement,
expression , type ? 
	If we reach any agreement on this , I will begin to tear the libSagee++
into several parts , which probably can solve the problem of compiling so 
long . 
	
	In this lib , unparse become subtle . We seem can ether treat it as a 
tool or as a part of the transform lib . What do you think about it ?

> In the following, I will describe my evaluation on Sage++ lib, this may help us
> understand each other better:
> 
> 1. The composition of the Sage++ lib
> 
> Sage++ lib is claimed as a C++ class library for compiler construction. The
> code may be devided in to the following four parts, in my opinion:
> 
> (a). low level C code, provide "real" operations on internal representation.
> These code, mainly in .c files, were probably come from the previous system of
> the Sage++, Sigma. Sage++ developers may also add some. Since there is no
> documents on this part, it is difficult to use them directly for a compiler
> writer. You don't know the calling sequence, even don't know how many functions
> are there.
> 
> (b). Sage base class. In this part, Sage++ developer package the above part
> with C++ constructions. For each type of intermediate node such as BFND, and
> LLND corresponding to program concept, a class was established.
> 
> For example:
> 
> class  SgExpression{
> public:
>   PTR_LLND thellnd;
> .....
> 
> }
> 
> These class are samiliar in the way that they composed with a pointer to C
> node,
> following various member functions, such as id(), variant();
> 
> A set of mapping functions take care of the constructor and destructor of these
> basic class.
> 
> I don't trace these maping functions, so I don't know how Sage++ manage memory
> space. If we want to make a serious effort on C++ lib, this should be analysed.
> 
> (c). Derived class. The basic idea is to construct different kinds of class for
> different language components. So many HPF construct certainly can not find
> their conterpart in this part, such as align statement, forall statement.
> 
> These clase provide a real valubale interface for compiler writers. They wrape
> around the base class, which can let compiler writer do not care about the
> internal structure of the AST.
> 
> For example:
> 
> There is a SgArrayRefExp in this part, which corresponding to array reference a
> program. In this class, there are two member functions:
> 
> int numberOfsubscripts();
> SgExpression * subscript(int i);
> 
> they return the number of subscript this array has, and corresponding ith
> subscript of this array.
> 
> With these two functions, a compiler writer did not to care how this array
> reference is composed by each LLND node, which of them is the first subscript.
> 
> As our front end AST is a little deferet from the one used in Sage++, you will
> find some member functions in this part need modification.
> 
> I think the main problem in this part is still that the memory strategy is not
> clear, your will find Sage++ conflict within itself. Some function are not well
> implemented. Documentations are not complete.
> 
> When I write compiler based on this part, lots of the usage come from lucky
> guess. And sometimes write the code do not care the memory at all just for
> convenience.
> 
> Another technical problem is that Sage++ put almost all its code in two files
> (a .h and a .C), this make change a small place need a lot of time to recomile
> the whole thing.
> 
> If we want to build a good lib for compiler, I suggest first to tear these two
> files into small ones.
> 
> (d). Attributes. I guess this part is also the last development part in Sage++.
> They provide a kind of container for user added attributes. I don't know much
> more about them, but I do seperate this part from the main file, and try a lot
> of functions in this part. They work well. The only thing I don't like is that
> to use this part we need explicit pointer casting, which is not recommended in
> C++.
> 
> We may discuss more on the use of this part.
> 
> Another thing, some one based on this part, developed Omega testing. I don't
> include this part of the code when I work on Sage++.
> 
> ==============================
> 
> The above is just a outlook of Sage++. Right now my use of Sage++ is just serve
> my purpose: compiling forall statement. Lots of work need to be done if we
> decide to offer this lib to a outside user.
> 
> 
> Guansong
> 

***************************************************************************
*     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 Gengbin <[email-masked]>
Date: Tue, 17 Sep 1996 10:30:29 +0800 (EAT)

On Mon, 16 Sep 1996, Guansong Zhang wrote:

> Yeah, basically that is true. But in practice I found some problems with g++:
> 
> 1. I don't know why, if the first name of libSage++.h and libSage++.C were not
> the same. g++ will have problem when link them.
>

	I don't quite understand this . What the first name mean ?

> 2. You will find g++ is too slow to be used when improve the code.
> 

	Yes , in fact it costed 10 minutes to compile it in HP. That why 
I decide to divide the Sage++ into sevral parts . The problem is how we 
divide them .

> I hope both of you make comments on the mail I send yesterday, which discribed
> the Sage++ construction. So we can decide how much work should be done for this
> lib.
> 

	In my last letter I have made some comments . Here I will 
emphasis that in fact it is impratical now to change the lib deeply by 
writing new codes  , our work is limited to  adjusting the lib just like 
dividing or combining . That 's my point of view , do you agree ?

Zheng