Subject: Re: About interface

From: Zheng Gengbin <[email-masked]>
Date: Tue, 29 Apr 1997 10:37:38 +0800 (EAT)

On Mon, 28 Apr 1997, Guansong Zhang wrote:

> Now, I seems to understand what the problem is. Let me describe it in this way,
> see if correct.
> 
> Translating call statement with interface, we need to create addtional
> processor array, and template in the main program. These processor array and
> template is corresponding to the one in subprograms.
> 
> Is this really a problem?
>

	This seems the only way we must follow . To deal with a function
call , we must first create new DAD for the array(copy dad)  or array 
section (set_array_triplet) . Then declare and create all processors and 
templates according to the subprogram interface , after this 
set_array_align or set_array_distribute the newly created dad to generate the 
correct data mapping . At last modify the call statement by adding dad as 
actual arguments . During the analyse of the interface , the data mapping
information is collected , and duplicated processor or tempplate names are 
to be avoided by generate the name according to their function names . 
	You can see to transform such a simple function call , a lot
of work is involved . 

> First, I think this is in part of trans0, it should not have anything to do
> with trans1. So you must be working on trans0, right?
> 

	Certainly .

> Second, in node program generation part, the out put do not have the same
> semantics meaning as its input. In fact, there is no processor and template
> definition.
> 
> The only thing give one such an idea is that there should be additional
> constructor such as pcrc_new_group_grid call for processor, pcrc_new_array_data
> for array dummy, and corresponding ones for template if needed.
> 
> But this should has nothing to do with the one in main program. You need to
> create new name for each of them, for example, using subprogram name as a
> prefix, we get
> 
> pcrc_grp_ff_p.
> 
> This processor group will be binded to the pcrc_grp_p ( if we have a processor
> P(4) in main program) by adlib, due to the same shape. This is a protocol we
> want to use currently.
> 
> In this way, the compiler may detect if corresponding data should be moved, as
> it do the work for forall statement.
> 
> Let me know if we understanding each other correctly. This is an important part
> of translating HPF subprogram in trans0, which I intend to do after May. But If
> you have time to do something on it, it is also fine.
> 
> I am more concerned with the trans1 part, we can not pass some program due to
> the little bug I mentioned previously. I hope you fix it first.
> 

	This part has been alreay fixed . I will give you the latest 
version . The problem is that the trans0 here is not stable , so I am
hesitate to give a new version .

> 
> 
> On Apr 28,  9:54am, Zheng Gengbin wrote:
> > Subject: Re: About interface
> > On Sun, 27 Apr 1997, Guansong Zhang wrote:
> >
> > > On Apr 27, 10:15am, Zheng Gengbin wrote:
> > > > Subject: About interface
> > > >
> > > > 	Now , I am  considering data mapping in subproblem interface .
> > > > It is clear that if there is an explicit interface for the called
> subprogram,
> > > > and that interface contains prescriptive or descriptive mapping
> > > > directives for a dummy argument ,the call should proceed as if the data
> > > > was copied to a temporary variable to match the mapping of the dummy
> > > > arguments as descibed .
> > > > 	The problem is when remap the dummy , some new Template and
> > > > Processors must be created as described in interface . This will make
> > > > the node program looks clumsy and sometimes the name will be duplicate .
> > > > This also cause two processor definition in a scope . But I don't think
> > > > this will cause problem .
> > > > 	I wonder if you have any idea about this .
> > > >
> > > >
> > > > Zheng
> > > >
> > > >
> > > >
> > > >-- End of excerpt from Zheng Gengbin
> > >
> > > I don't understand this well. Please give me an example.
> > >
> > > >From Adlib point of view, adding a same shape processor group would cause
> real
> > > problem. But from compiler point of view, this may change the semantics of
> the
> > > source program. So we should avoid this if possible.
> > >
> > > Guansong
> > >
> >
> > 	For example :
> >
> >         subroutine ff(b)
> >         integer b(10)
> > !HPF$   processors  p(4)
> > !HPF$   distribute b(block) onto p
> >         end
> >
> >         program main
> >         interface f
> >                 subroutine ff(b)
> >                 integer b(10)
> > !HPF$   processors  p(4)
> > !HPF$  distribute b(block) onto p
> >                 end subroutine
> >         end interface
> >
> >         integer a(2:20)
> >         call f(a(3:10))
> >         end
> >
> >
> > 	when we deal with the proc call statement , trans0 have create the
> > dad section for a(3:10) , next I want to do the data mapping for the dad
> > created according to the specification in the interface . here we have
> > another proccessors p(4) defined in the interface . So in order to
> > set_array_distribute the dad of a(3:10) ,, i must  first create the
> > processor declaration statement and the processor create statement .  It
> > is possible that the main scope also have a processor p declared .To make
> > things worse , if align and template appear in ther interface , I have to
> > create the template also , which make the node program complicated . ANd
> > this work must  be repeatedly done in the every entry of call .
> >
> >
> > Zheng
> >-- End of excerpt from Zheng Gengbin
> 
> 
>

---

From: Zheng Gengbin <[email-masked]>
Date: Tue, 29 Apr 1997 10:37:38 +0800 (EAT)

Certainly .