Subject: Re: triangular array access and assignment-only block foralls

From: [email-masked]
Date: Thu, 25 Jun 92 13:53:40 -0500

Andy, I noticed your mail didn't go to hpff-forall; hope you don't
mind me forwarding it

> Date: Thu, 25 Jun 92 08:47:48 CDT
> From: [email-masked] (Andy Meltzer)
> To: [email-masked]
> Subject: Re: triangular array access and assignment-only block foralls
> 
> I haven't been available to read the hpff mailings for a few weeks, but
> it strikes me that Chuck's statement goes to the heart of one of the
> things that we have to decide before we should go much further.
> 
> > Like Ken, I don't want nondeterminism in the HPF language.  The cases
> > that Rex calls "acceptable non-determinism" I would label as
> > "non-standard-conforming".  [Asbestos suit on]
> 
> I don't think there is much desire in HPF for non-determinism (I could be
> wrong, but I seem to be one of the people whose proposals come closest to
> it).  The issue is how far we go to ensure that the programmer cannot
> introduce non-determinism.  
> 
> Now, to put my two cents in:  I think that non-deterministic programs should
> be labelled "non-standard conforming" or even "erroneous", but I don't
> think that we should mandate any semantics which restricts the user from
> doing things that might cause these problems.  When we restrict the 
> semantics, we disable an enormous number of useful constructs.  
> 
> > Acceptable non-determinism in a block forall becomes more difficult
> > to describe in the presence of statements other than assignments.
> > CALLs are especially difficult to deal with.  (Rex Page)
> 
> I'd suggest that the only restriction of this sort that we want for FORALL 
> is one which states something like (using Marc's proposal for syntax):
> 
> 	"Any storage location which is updated by one forall-block 
> 	 (in a function, subroutine, or assignment) may not be 
> 	 updated or read by any other forall-block."
> 
> I think this is clear and it leaves a very powerful construct for the user.
> It also makes illegal all non-deterministic programs.  Its only drawback
> (albeit a major one) is that the compiler cannot enforce it.
> 
> BTW, this restriction removes the ambiguity in Chuck's IF example.  It 
> makes it "erroneous".
> 
> > 2. Which of the following statements should be allowed in a block FORALL?
> > 	(Let's assume that assignment makes the cut :-)
> > 	A) single-statement FORALL
> > 	B) block FORALL
> > 	C) array WHERE (i.e. current Fortran 90 WHERE)
> > 	D) scalar WHERE (i.e. Marc's proposal)
> > 	E) IF-THEN-ELSE with FORALL-invariant conditions
> > 	F) IF-THEN-ELSE, conditions can depend on FORALL indices
> > 	G) DO loop with FORALL-invariant bounds
> > 	H) DO loop, bounds can depend on FORALL indices
> > 	J) GOTO
> > 	K) STOP and PAUSE
> > 	L) I/O statements (OPEN, CLOSE, READ, WRITE, ...)
> > 	M) ALLOCATE and DEALLOCATE
> > 	N) CALL
> 
> Allowed: Everything except H, K.
> (only restricting K because I don't know how to do a good job at it)
> 
> 
> 
> 
> 						Andy Meltzer

---

From: [email-masked]
Date: Thu, 25 Jun 92 14:04:41 -0500

> ...

This sounds like a vote for "non-standard-conforming" - if we make
those programs "erroneous" then they have to be rejected (just like
subscripts out of bounds have to be detected).

> ...

Uh, wouldn't that restriction also make this non-standard-conforming?
	FORALL ( I = 2:N-1 )
	  A(I) = A(I) * 2		! S1
	  B(I) = A(I-1) + A(I+1)	! S2
	END FORALL
A(I) in S1 is read by S2 on different iterations...

Just pointing out we have to be careful in making these restrictions...

> (only restricting K because I don't know how to do a good job at it)

Does that mean you can do a good job on this?
	X = 0.0
	FORALL ( I = 1:N )
	  IF (A(I) = 0.0) THEN
	    GOTO 100
	  END IF
	END FORALL
	X = 1.0
100	PRINT X
While we're on the subject, what's printed?

	Chuck