Subject: FORALL Semantics

From: Glossa <[email-masked]>
Date: Mon, 15 Jun 92 09:38 GMT

FOR-ALL statement

   When you cannot check a condition why maintain it? We cannot in general check   th
at each element of a forall array assignment left-hand side array is only
   assigned once. So why try to assert it?

   And what about side effects on the right (or left) hand side. How do they 
   interact? 

   Why not state that the statement is executed for each combination of the
   for-all indices  and that any interleaving of the separate statement 
   executions gives an acceptable execution? In other words, the programmer
   cannot be sure of the effect unless he has written a program independent
   of which interleaving is chosen.  This subsumes both side effect and 
   multiple assignment issues. 

   Thanks for using STANDARD LaTeX in your excellent paper David!

Tom Lake

---

From: [email-masked]
Date: Mon, 15 Jun 92 12:35:51 -0500

> Date: Mon, 15 Jun 92 09:38 GMT
> From: Glossa <[email-masked]>
> Subject: FORALL Semantics
> 
> FOR-ALL statement
> 
> 

Why can't this condition be checked at run-time?  Inefficient check:
	FORALL (I = 1:N) A(F(I)) = B(I)
becomes
	DO J1 = 1, SIZEOF(A)
	  TEMP_A(J1) = .FALSE.
	ENDDO
	DO I = 1, N
	  TEMP_I = F(I)
	  IF ( TEMP_A(TEMP_I) ) THEN
	    PRINT *, 'ERROR - REASSIGNMENT TO A(',TEMP_A,') AT I=',I
	    STOP
	  ELSE
	    A(TEMP_I) = B(I)
	    TEMP_A(TEMP_I) = B(I)
	  ENDIF
	ENDDO
An efficient implementation would make one or more of the following
optimizations:
    1. Don't check LHS subscripts that can be proved independent
	in the compiler (for example A(I))
    2. Detect reassignments using parallel global combining operations
    3. Have a "no seat belt" mode without checking (analogous to
	turning off subscript bounds checks)

Also note that there are a lot of other conditions in Fortran that
can't be checked at compile or run-time - for example, aliasing of
function parameters is illegal *if it changes the computed value*.

>    And what about side effects on the right (or left) hand side. How do they 

This is indeed something that needs to be nailed down.  Part of the
answer can be found in the draft:

\item The evaluation of expressions within {\it array-element} or {\it
array-section} must neither affect nor be affected by the evaluation
of {\it expr}.

For reference, the BNF referred to is below
forall-stmt          is FORALL (forall-triplet-spec-list [ ,scalar-mask-expr ])
                          forall-assignment
forall-triplet-spec  is subscript-name = subscript : subscript [ : stride]
forall-assignment    is array-element = expr
                     or array-section = expr

This disallows side effects in the LHS from affecting the RHS.  It
also disallows RHS side effects from affecting the subscript
expressions in the LHS.  As written now, it says nothing about RHS
side effects interfering with RHS evaluations in other iterations (and
similarly for the LHS) - a hole you can drive finite-element programs
through.

Note that side effects will be more difficult to check than the
condition you object to above.

>    multiple assignment issues. 

This disallows the following
	FORALL (I = 2:N-1) A(I) = (A(I-1) + A(I) + A(I+1)) / 3
which has the same meaning (under the current proposal) as
	A(2:N-1) = (A(1:N-2) + A(2:N-1) + A(3:N)) / 3
Here, the array notation is more compact; for larger expressions, the
FORALL tends to be shorter and clearer.  Feedback from CM-2 users is
that they like the FORALL for expressing this style of computation;
HPF should learn from this kind of experience.

I also question your proposal on another ground - taking statements as
the basic unit of granularity.  Consider
	FORALL (I = 1:N-1) A(I) = F(I)
(Assume F is a user-defined function.)  Does your semantics mean that
F must be executed atomically?  Note that arbitrarily interleaving
copies of A(I) = F(I) is not the same as interleaving the statements
executed in F!

I don't mean to dismiss the general thrust of your message - that
FORALL needs a firm definition (at least, that's what I take your
point to be).  You are absolutely right that we haven't discussed many
important cases, and need to in the near future.  I think, however,
that the semantics you propose is too restricted.

>    Thanks for using STANDARD LaTeX in your excellent paper David!

I'll second that!

> Tom Lake

	Chuck Koelbel