Subject: Re: Happy new year! & 1.71

From: Yan Mi <[email-masked]>
Date: Sat, 4 Jan 1997 09:08:32 +0800 (EAT)

On Fri, 3 Jan 1997, Guansong Zhang wrote:

> Hi, every one, please make comments on this letter.
> 
> In-Reply-To: Zheng Gengbin <[email-masked]>
>         "Re: Happy new year! & 1.71" (Jan  3,  2:55pm)
> X-Mailer: Z-Mail (3.2.1 6apr95 MediaMail)
> 
> On Jan 3,  2:55pm, Zheng Gengbin wrote:
> > Subject: Re: Happy new year! & 1.71
> >
> > 	By testing the kernels' program , I met some new bugs in our
> > frontEnd , but I think the most severe problem is transG , it seems core
> > dump at every example . We are about to do some work on it , I'd like
> > to know your plan of improving the transG , so we will not duplicate our
> > work .
> >
> 
> Please don't work on transG temporarily, I think we need a plan to improve it.
> 
> In fact, I think we should have a more clear plan for the compiler development,
> not only transG. As I said in previous mail, transBD and transG are names
> reflect only the translating dependence, they are not suitable for different
> phase in compiler process. I suggest that the compiler be divided into two
> phases, (we can obtain these two by improving transBD and transG, we'd better
> rename these two module.):
> 
> a) Format transformation:
> 
> In this phase, we will do work like in transBD, change the format of the source
> program to some form (though this form is not easily determined at once, we may
> finally reach one as we work going on.),  which is much easier to be handled in
> later phase, while remains the semantics of the original HPF program.
> 
> b) Node program generation:
> 
> Only in this part, the run-time support is taken into consideration. Like the
> work in transG. We will first do things easy, which we have clear thought, then
> more complicated ones like irregular computation.
> 
> Though this may affect the effecency of the compiler, I think the advantage of
> the strategy is obvious. And most important of all, we can work on different
> part at the same time even before a complete knowledge how we are going to deal
> each particular language component.
> 
> Once the overall plane is made, we can discuss different kinds of problems
> remained in the two phases, and work on them seperately. So every one, please
> make comments on this letter as much as you can.
> 
> 
> Guansong
> 
> 
> 

Hi,
	What we will do to improve the performance of transG has no 
conflict with  your  plan. Our emphasis is put on the second phrase : node
program generation. At first , we won't modify your code . Your 
work considered the most common cases ,and we'll consider some special cases
that can be optimized at compile time. Only after our code run smoothly 
will  we combine our work with yours .
Yanmi

---

From: Du_Zhi_hui <[email-masked]>
Date: Sun, 5 Jan 1997 10:12:19 +0800 (EAT)

Hi Zhang guansong:

	Separating our compiler into two phases is reasonable. This make our 
compiler look more clear in high level.
	All transformations which do not chang the semantic of HPF source file 
should belong to phase one,just as you said, this phase only changes the 
format of HPF source file to make it easy to generate node program in the 
second phase.The transformed file should be HPF file.
	The second phase is the kernel of our compiler,I think it 
includes not only the transformation from FORALL statement to DO LOOP,but 
also INDEPEND DO to DO LOOP and many other changes which do not appear in 
the transformation map of Prof Li's "Compilation Strategy I of an HPF 
Compiler".
	We now focus on FORALL transformation ,in fact some traditional and 
classical methods for serial program should also be considered if we want 
our our compiler to be a real compiler.I think this work should be done 
on both HPF source file and node program.
	I agree that we should have a good plan on our future 
work,Perhaps you midunderstand our meaning ,To improve tranG , we must 
first understand transG and find the key problem and bottleneck of 
transG,Please do not worry that we will do the same work just as yours,I 
think what we do now  will be helpful for our cooperation.If we do not 
dive into transG,how can we discuss with you about transG?
	I'd like to discuss with you more detail problem and general idea about 
transG and our compiler.
	Thanks for giving us your idea and welcome to your new idea.

==========================================================
Du Zhihui    (010)62751798 (o)
             (010)62754032-203(h)
PRC    BeiJing           |   PRC    BeiJing
100871 Peking University |   100871 Peking University
Computer Department      |   Building 39
AI Lab                   |   Room     203