Re: forall and do loop

Richard Maine wrote:

glen herrmannsfeldt <gah@xxxxxxxxxxxxxxxx> wrote:

If I designed FORALL I would have allowed intermixing of evaluation
and assignment in any order, and left it to the programmer to be sure
that would work.

That amounts to restricting it to the cases trivial enough that most
compilers probably don't generate temporaries today anyway. So you'd get
the same effect as today on that subset of cases, and you'd just say
that the other cases were illegal. Anyway, that's how I'd translate the
above.

That is pretty close to what I meant. I think there are some cases
of indirect loads that the compiler wouldn't catch, though.

FORALL (I=1:N) X(I)=X(L(I))

the programmer might know that no X() from the right side are
modified, but the compiler likely wouldn't. (That all L() were
greater than N.)

I'm interpreting "left it to the programmer to be sure that would work"
as requiring the programmer to code in such a way that the same results
would be obtained for any order of evaluation and assignment. Otherwise,
I have no idea what you would mean (though that seems to happen a bit,
so it might be the case here as well).

I do find it interesting that array expressions are defined such
that the right side is fully evaluated before the left changes, for example:

A=A+A(N)

or worse:

M=M+M(M(N))

PL/I array operations are defined such that changes to array elements
are processed in array element order. That is,

A=A+A(N);

the new value of A(N) is used. That is convenient for serial processors
not using a temporary array, but is not convenient for parallel systems.

If I understand things correctly, that's at least close to the proposed
specification of DO CONCURRENT, but the DO allows things in addition to
just assignment, so it adds some capability to make up for the ones that
it drops.

I would hope you don't mean it in the sense of "here's a syntax, but the
standard doesn't say anything about what it means; it is up to the
programmer to know what a particular compiler means by it." Admitedly
there is precedence in that that's not too far off from how the standard
specifies VOLATILE. :-(

No, just that the order of processing of array elements is left
undetermined.

-- glen

.

Quantcast