Re: storing arrays for Fortran (was: QUERY ABOUT MONITOR)

[seas.gwu.edu!mfeldman@uunet.uu.net (Michael Feldman)]

In article <1993Aug5.092922.24986@sei.cmu.edu> ae@sei.cmu.edu (Arthur Evans) wr
ites:
>mfeldman@seas.gwu.edu (Michael Feldman) says that code like
>    FOR I IN 1..10 LOOP
>       A(I) := B(I) + C(I);
>    END LOOP;
>should be vectorized if the hardware supports it.  He adds:
>    How many compilers out there will compile an array assignment like
>       A := B;   -- who cares what the typedefs are
>    into a _minimum_ number of block-move instructions for that target?
>
>One problem here is a weakness in the design of Ada-83.  The rules in
>11.6 about when exceptions are raised and the status of data at that
>point conspire to preclude such optimizations.  This problem is
>addressed in 9X and is, as far as I can tell, solved properly.  (Consult
>your favorite language lawyer for details.)
>
The first example supports your case - the programmer has explicited coded
a loop. I don't see how the second case applies. One object is being copied
to another; making any reasonable assumptions about the types of A and B,
it's hard to see how an exception would hurt - if it were somehow raised
(oh, maybe A and B are variant records and A is constrained, and 
Constraint_Error is raised on the discriminants, say) then the copy
has not taken place. How is this different from a Constraint_Error on
an integer copy?

The second case is more intriguing, in light of your comment, because
the loop specifies an order of copying, so if an exception is raised
the copying might be partially completed. Could this have been finessed 
somehow by an Ada Interpretation that was as creative as the one that 
allowed rate-monotonic scheduling? (Example: "if the loop is vectorized,
it is erroneous to make any assumption about A if an exception is raised"
or some such thing.) Can you say succinctly how this is handled in 9X?

I'll bet that if the "market" push on this was as aggressive as the real-
time folks were on the scheduling issue, something could have been done.
But, yeah, you're right, Art. I stand corrected on this specific case.

It's also one of the problems with a strong standard - it has unintended 
and not always positive consequences. I guess the Fortranners don't have
this problem - no strong standard.

Mike Feldman