Subject: Re: Putting our project onto internet

From: Zheng Gengbing <[email-masked]>
Date: Mon, 20 May 1996 11:11:45 +0800 (EAT)

On Sun, 19 May 1996, Guansong Zhang wrote:

> Hi,
> 
> After a few weeks of hard working, our project was successfully demoed at CRPC
> meeting. (I think even more important than the demo is that we finally merged
> out a single version, this will be a solid base for all of us to do the further
> compiler work on it.) Now it is time to improve our work and put it on to the
> internet.
> 
> This is not like the demo, in which we can choose not to show our weak points.
> This time some one will examine our work thorughly. (At least Rice University
> will do so.)
> 
> So let's begin with what kind of problem left in our project. I will list the
> thing which I think is important one by one. We can discuss how to deal with
> them (We may decide not to solve all of them). You may add more.
> 
> 1. hash table.
> 
> At first, compared with constructing AST, hash table is not important, but now
> it begins to affect the efficency in hpfsc. This not only makes hpfsc run very
> slow but also will affect any further work on compiler.
> 
> So hash table should be added. In fact, there is a hash algorithm in Sage++. I
> will talk this further if we decide to use the same one.
>

	Since hash table is not saved in dumpdep files , so only after we
merge hpf2dep and hpfsc can we implement hash table .

> 2. contains statement.
> 
> The implementation of contain statement is still a problem. At present time, it
> was implemented as the right son of the program unit contains this structure.
> This is not consistent with the overall rule of Sage++ definition: the right
> son is used to represent the false branch. It also set a problem for unparse to
> deal with the labeled end statement of the program unit.
> 
> In fact, let the contains_statement has its contents as son will be OK. Please
> let me know if we change this how much effort should be done.
>

	Do not implement like that , since if that the contents symbol have
their scope as contains_statement , which make our checking of 
scope very difficult .

> 3. implied do.
> 
> In test1.f of old comprehensive set. We need to comment at two positions. One
> of them is a data statement. Here is the reason, please see the following
> program:
> 
> program aa
> integer i(10), k(9)
> DATA var, (i(j),j=1,2), (k(j), j=1,2) /2,2,2,2,2/
> DATA var, (i(j),k(j),j=1,2) /2,2,2,2,2/
> end
> 
> This program can be successfully parsed by compiler on IBM (with a warning).
> but failed for our project on line 4. The reason is that the second date
> statement has some kind of complicated implied do, while line 3, which express
> the same thing, can be parsed.
> 
> ( In our implementation, I found DATA_IMPL_DO, I am not sure if the implied do
> at other place can be write as this too.)
> 

	In fact , according to F90 specification , data_i_do_object_list
cannot separated by COMMA (,) , so the second data statement should not be
passed by hpf2dep . I think the compiler on IBM do a certain extension .

> 4 keyword reserved.
> 
> Well, this is one of our limitations. I am not sure about how the language
> standard (f90) specify this. But it is obviously the resered key words part is
> less than ours. For this reason, some of the program in test90 need to be
> rewritten, while they can all be parsed by both of F90 compiler form DEC and
> IBM. (And I think the real(...,kind=*) problem also is related to this.)
> 
> Now I am considering whether we can get ride of this limitation. Here is a
> method used in Sigma: two notterminal is added, say, need-keyword-on,
> need-keyword-off. They can be reduced from null string. The action to these
> rules are controling a flag, which will let lexer return a keyword value or
> simply a NAME. Then in .y file, when ever a key word is needed, it was put in
> between these two nonterminals.
> 
> But this sure will complicate the yacc rules. More conficts may arrive. I don't
> know if the present situation of yacc rules can afford to do so. Please make
> comments on this.
> 
> (I noticed PKU add a terminal to deal with kind= problem, this is different
> from above method.)
> 
> 5 Some punctuations.
> 
> This includes: ";" at end of the statement; Omitable "," in format, (this is
> addressed in constrains, so it is easy to overlook from the rules.) Optional
> "," in 507 second option.
> 
> I don't think these are important. But if we can solve them when modifing yacc
> rules, that is certainly better.
> 
> 6 lexer.
> 
> So far, our testing program are mostly free format. The only fixed format
> programs we test are from our unparse results (they are fix-free format
> compatable.) I think we have some problems deal with this in lexer.
> 
> (In addition, lexer can not deal with unexpected end-of-file, you can see this
> when some test program let hpf2dep freeze there, with out giving out any
> result, even memory fault.)
> 
> 7 testing.
> 
> So far, none of the testing program is re-run. I will begin to do this as soon
> as we can successfully unparse all the program in test90. Also, the unparse
> results of the comprehensive syntax test were not checked. I think this will be
> done as unparse progress gradually.
> 
> 8 portibality.
> 
> The real work on this is not started, the configure and makefile so far are
> only as a preparation for this. When we put the project on internet, at least
> we have to let several platform produce the same results for our testsuite.
> 

	I found flex can not work on our lexer and I don't know the reason
yet . But the problem occured when input and unput are called in lexer when
to decide if return FUNNAME or NAME . 
	And now after I modified some places in f90.y , bison can successfully
compile yacc files without any warning and errors. But I have not tested the 
result of runing .

> --------------
> 
> Well, that is all I can think of. I am tring again to send the new 1.53 back to
> both of you. (none of the effort successful yesterday. Sometimes the network
> just decide to have problem!)
> 
> Don't hurry on updating this time, let's discuss what should we do and how to
> do them first.
> 
> Waiting for your comments.
> 
> 
> 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   *
***************************************************************************