From owner-hpff-interpret  Mon Sep 30 20:28:18 1996
Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id UAA11703 for hpff-interpret-out; Mon, 30 Sep 1996 20:28:18 -0500 (CDT)
Received: from VNET.IBM.COM (vnet.ibm.com [199.171.26.4]) by cs.rice.edu (8.7.1/8.7.1) with SMTP id UAA11695 for <hpff-interpret@cs.rice.edu>; Mon, 30 Sep 1996 20:28:10 -0500 (CDT)
Received: from TOROLAB by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 5951;
   Mon, 30 Sep 96 21:28:18 EDT
Received: by TOROLAB (XAGENTA 4.0) id 1258; Mon, 30 Sep 1996 17:43:41 -0400 
Received: by twinpeaks.torolab.ibm.com (AIX 3.2/UCB 5.64/4.03)
          id AA18848; Mon, 30 Sep 1996 17:43:56 -0400
From: <zongaro@vnet.ibm.com> (Henry Zongaro)
Message-Id: <9609302143.AA18848@twinpeaks.torolab.ibm.com>
Subject: hpff-interpret: Re: hpff: TEMPLATE scoping
To: norton@nrlmry.navy.mil
Date: Mon, 30 Sep 1996 17:43:54 -0400 (EDT)
Cc: hpff-interpret@cs.rice.edu (HPPF Interpretations)
In-Reply-To: <199609231851.LAA06450@norton.nrlmry.navy.mil> from "norton@nrlmry.navy.mil" at Sep 23, 96 11:51:28 am
X-Mailer: ELM [version 2.4 PL24alpha3]
Content-Type: text
Sender: owner-hpff-interpret
Precedence: bulk

---------------------------------------------------------------------------
hpff-interpret@cs.rice.edu is a mailing list for corrections,
clarifications, and interpretations related to High Performance Fortran.
Instructions for adding or deleting yourself from this list appear at the
bottom of this message.
---------------------------------------------------------------------------

Hi Dave,

     I've copied the hpff-interpret mailing list on this, because I thought
that was the more appropriate place.

> I have been experimenting with TEMPLATEs a bit lately and have found
> that when used in MODULEs, I would like to be able to limit their
> scoping to just the module.  Has there been any discussion of
> templates having the ability to use PRIVATE or PUBLIC in the future?

     The private attribute does apply to templates (and processors
arrangements, for that matter), but can't be applied directly to an individual
template.  To make a template in a module private, you have to do something
like this:

      module mod
        private
!hpf$   template t(100)
!hpf$   distribute t(block)
        integer, public :: a(100)
!hpf$   align a(i) with t(i)
      end module mod

This means you have to explicitly specify the public attribute for all
entities that you want to be public in the module.

>
> Also -
> Array alignment in subroutines seems to be pretty well addressed for
> the codes that I am working on.  Dummy arrays I declare with:
>
> !HPF$ DISTRIBUTE *(aaaaaaaaaaaa) :: yyy
> !HPF$ DISTRIBUTE *(bbbbbbbbbbbb) :: zzz
>
> and locals I can declare with:
>
> !HPF$ ALIGN WITH yyy ::
> !HPF$ ALIGN WITH zzz ::
>
> and presumably somewhere higher up in the call tree the relationship
> between different distributions is described so as to maximize
> alignment of arrays.
>
> MODULEs seem to introduce an interesting situation.  Currently, I am
> using them only to replace COMMON blocks.  It seems that there is not
> a way to explicitly tell the compiler about the alignment relationship
> between arrays in the module and arrays in the routines that USE the
> module.  Even TEMPLATEs, if you could limit their scoping via PRIVATE,
> would only implicitly address this.  Have I missed something?  Is
> there any preferred method for addressing alignment of arrays in COMMON
> block type MODULEs with arrays in subroutines?

     This is an interesting problem.  If I understand correctly, you are doing
things like this:

      subroutine sub(arg)
        common /com/ carr
        integer :: arg(:), carr(100)
!hpf$   distribute arg(block)
!hpf$   align carr(i) with arg(2*i+1)
      end subroutine sub

and you are finding that you can't do this:

      module mod
        integer :: carr(100)
      end module mod

      subroutine sub(arg)
        use mod
        integer :: arg(:)
!hpf$   distribute arg(block)
!hpf$   align carr(i) with arg(2*i+1)
      end subroutine sub

     Since the mapping of data in common and modules is basically fixed
throughout the execution of the program, couldn't you turn the alignments
around in most situations so that the array in the module is distributed, and
the argument to the subroutine is aligned with the array from the module,
rather than the other way around?

     My apologies if I've misunderstood what you are trying to do.

Thanks,

Henry
---------------------------------------------------------------------------
To (un)subscribe to this list, send mail to
hpff-interpret-request@cs.rice.edu.
Leave the subject line blank, and in the body put the line
(un)subscribe <email-address>
---------------------------------------------------------------------------