Subject: Re: Back to square one

From: [email-masked] (Arthur Veen)
Date: Thu, 16 Jul 92 22:32:53 +0200

I would like to endorse Alan Karp's suggestion
(later endorsed by James Cownie and others) not to include
any FORALL construct in HPF at all.

As [email-masked] said:

> Stopping at the point of adding NOTHING to the base language is
> very clean, clear, and simple.

Once you allow yourself to add extensions that affect
the semantics the sky is the limit. As a consequence
the discussions on a block-FORALL have so far been inconclusive,
and I don't see it converging in time for the next meeting.

The examples I have seen that support FORALL fall into two
classes depending on whether changing a DO in a FORALL does 
or does not change the semantics of the loop. 
In the latter case the FORALL simply asserts to the
compiler that there are no loop-carried dependencies. 
This information can be perfectly conveyed by a directive.

The discussion centers on those cases where changing a DO 
in a FORALL *does* change the 
semantics of the program. These examples can easily be rewritten
by making explicit copies of the arrays appearing in
the right-hand sides (or am I missing something ?).

Even for these cases the FORALL does not score high on my main criteria:

PORTABILITY
	As already pointed out by others FORALL is a real loser in this
	respect

CLARITY
	Of course, clarity is a matter of taste, but to me the
	explicit copies are much clearer than the implicit COPY-IN
	semantics of the FORALL.
	Compare for instance Richard Shapiro's example:

	> FORALL(I=1:NCARDS) DECK(I) = DECK(MOD(SEED2+SEED1*I,NCARDS)+1)

	with his own rewrite:

	>  DO I = 1,NCARDS
	>		TEMP(I) = DECK(MOD(SEED2+SEED1*I,NCARDS)+1)
	>  ENDDO
	>  DECK = TEMP

	(By the way: the keyword "forall" seems ill-conceived to me: 
	 it does not convey anything about the COPY-IN semantics)

EFFICIENCY
	This seems to be main motive of the FORALL advocates.
	It seems to me that the sophisticated compiler that is
	needed for any effective HPF implementation can easily 
	recognize (if that is advantageous) the arrays that the programmer
	uses to store its temporary copies and thus generate the same
	code as if the FORALL was included.

--arthur

                 Arthur H. Veen
			Technical Director PREPARE

       Parallel Computing   ACE
       Postbus 16775        van Eeghenstraat 100
       1001 RG  Amsterdam   1071 GL  Amsterdam
       The Netherlands      The Netherlands
phone: +31-20-623 3274      +31-20-664 6416
Fax:                        +31-20-675 0389
E-mail:[email-masked]    [email-masked]