Subject: User-defined elemental procedures (>Cownie, >>>Merlin)

From: "Rex Page" <[email-masked]>
Date: Mon, 29 Jun 92 14:49:27 -0500

> > > For a function to be valid for use as an elemental function, it must 
> > > obey the following constraints:
> > >	1. Its arguments must have intent '(IN)'.
> > >	2. Local arrays cannot be SAVEd.
> > >	3. It cannot define any global variable.
> > >	4. Its arguments, result and local variables must not be distributed.
> > >	5. It can only reference a global variable if it is *not distributed*.

> I think John is trying to achieve two separate effects here (since
> he's away I think I can say this without fear of immediate
> contradiction !)

> 1) To insist that the functions are "mathematical" ...

> 2) To ensure that all data references made by the function can be
> achieved locally. (Rules four and five are trying to achieve this)

> ...

> Point 2) is "solely an implementation issue" :-). John wants it
> because he wants a run-time which doesn't require demand driven
> communication. It is easy to construct elemental functions which
> access non-local data.

>  ...

> It is actually unclear that there is any easy way of making the
> restrictions John wants visible in hpf, since "every array is create
> with an alignment to some template, and every template is created
> with some distribution onto some arrangement of processors."

This seems to leave the distribution of some arrays up to the processor.
It doesn't seem to require that the distribution will be the same for
all arrays where distribution is not specified.  A processor could,
for example, allocate local arrays locally, giving the effect John wants
when the function is being evaluated in elemental mode.

  - Rex Page

---

From: [email-masked] (James Cownie)
Date: Tue, 30 Jun 92 11:00:58 BST

>when the function is being evaluated in elemental mode.

Terminology
===========
"local" is very confusing in this discussion, as it refers in closely
related contexts both to scope ("local array") and to the mapping of
the data onto processors ("the array can be locally accessed").
I think we should keep "local" for the scoping property (since they
got there first), so does anyone have a good suggestion for the 
property of being in the processor's memory ? (poor suggestion : "resident").

Content
=======
The local arrays for elemental functions should certainly be allocated
resident, however the problem also arises with the global data (see
example in previous mail).

A solution which would meet John's objective (but is not permissible
under his restrictions) would be to insist that the global data
accessed by the elemental function was replicated, thus ensuring that
it is resident on all processors.

(maybe resident isn't so poor !)

--Jim
James Cownie 
Meiko Limited
650 Aztec West
Bristol BS12 4SD
England

Phone : +44 454 616171
FAX   : +44 454 618188
E-Mail: [email-masked] or [email-masked]