HPJava array element access

<h1>Accessing array elements</h1>

The mechanism for subscripting distributed arrays in HPJava is
complicated by the fact that only <i>local</i> elements are supposed to
be directly accessible.  One cannot simply use a global integer
subscript in a distributed dimension of an array, because in general
that might refer to an element held by some other process.

<p>

The language incorporates a special syntactic entity called a
<i>location</i>.  A location is a particular element of a particular
distributed range.  The <tt>n</tt>th location (starting from zero) of
range <tt>x</tt> is designated <tt>x[n]</tt>.  In a normal subscripting
operation, any subscript in a distributed dimension of an array <i>must
be a location in the range associated with that dimension of the
array</i>.  This constraint alone doesn't guarantee that the location
(and thus array element) is locally resident.  To ensure this, we
insist that the location used as a subscript must be a <i>named
subscript</i> scoped by an <tt>at</tt> or <tt>overall</tt> construct.

<p>

In
<font color=Blue>
<pre>
    Range x = new BlockRange(N, p.dim(0)) ;
    Range y = new BlockRange(N, p.dim(1)) ;

    float [[]] d = new float [[x]] ;

    d [0] = 27 ;          // Illegal!

    d [x [0]] = 27 ;      // Illegal!

    at(i = x [0])
      d [i] = 27 ;        // OK

    at(j = y [0])
      d [j] = 27 ;        // Illegal!
</pre>
</font>
the first assignment is illegal because an integer subscript cannot be
used in a distributed array dimension.  The second assignment is still
illegal, because the subscript is not a <i>named</i> location.  The
third assignment is OK: the <tt>at</tt> construct scopes a named
location.  The body of the construct is only executed by processors
that hold the specified location.  The final assignment is illegal
again, because <tt>j</tt> is not a location in the range, <tt>x</tt>, of
<tt>d</tt>.

<p>

Locations have a peculiar status in the language.  They can
<i>only</i> be named through <tt>overall</tt> or <tt>at</tt>
constructs.  This implies that location values cannot be stored in
ordinary Java variables or passed as arguments to user-defined
methods.  It is sometimes convenient to regard locations as having
class <tt>Location</tt>, but really they live somewhere outside the
normal type system - essentially a symbolic convenience.  Locations
are not ``first class'' entities of the language.  Their status is
comparable with, say, the <tt>FORALL</tt> indices, or the alignment
dummies, of HPF.

<p>

<b>Next:</b>
<a href="subgroups.html">Subgroups</a>

