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

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

[Robert Dewar]

Mike misplaces the blame here. The issue is not "a strong standard", but
rather the question of whether the language should have checks or not, which
is a language related issue that has pretty much nothing to do with
standarization. The trouble is that once you say you want checks, you tend
to introduce notions of canonical order which clearly do not exist in
languages like Fortran and C that do not have the notion of checks built
into the language. It'
s basically a question of safety vs efficiency, nothing to to with
standardization.

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

[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

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

[magnesium.club.cc.cmu.edu!news.sei.cmu.edu!ae]

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.)

Art Evans
----------------------------------------------
Arthur Evans, Jr, PhD           Ada Consultant
461 Fairview Road
Pittsburgh PA  15238-1933
412-963-0839
ae@sei.cmu.edu

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

[Michael Feldman]

In article <1993Aug5.011633.4394@leeweyr.sccsi.com> bill@leeweyr.sccsi.com (Bil
l Lee) writes:

[stuff deleted]
>
>I know that Cray and Convex both have very good Ada compilers for
>their vector-architecture machines. I know that the Cray compiler
>has vectorizing capabilities every bit as good as their FORTRAN
>compiler.
>
>How about it, guys! Blow your own horn a little!! I, for one, would
>like to hear your success stories!

Me too! Are they cracking the non-DoD engineering world at all?
Are they trying?

Mike Feldman

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

[agate!library.ucla.edu!ddsw1!news.kei.com!sol.ctr.columbia.edu!math.ohio-]

In article <1993Aug4.174651.2765@seas.gwu.edu> mfeldman@seas.gwu.edu (Michael F
eldman) writes:
>In article <1993Aug4.090104.20732@sei.cmu.edu> ae@sei.cmu.edu (Arthur Evans) w
rites:
>>michael.hagerty@nitelog.com (Michael Hagerty) complains about the
>>inability to direct an Ada compiler to store arrays so as to be
>>compatible with Fortran.
>>
>>However, there is nothing that I can see to keep an Ada vendor from
>>introducing some of the functionality of Section M.3 of the 9X document
>>into an Ada-83 compiler by use of pragmas.  Go poke your favorite
>>vendor!
>>
>That's just why I brought it up a few days ago. I'm poking _all_ of them
>at once. IMHO they are just imitating each other anyway. They see only
>each other as the competition while the rest of the world leaves them
>behind.
>
>There are a lot of aspects of Ada that are not getting exploited because 
>the folks who do the compilers seem to do _only_ what the next contract's 
>customer wants. It's the Beltway Bandit vs. the entrepreneur mentality. 
>
>Another suggestion, unwelcome as it may be. Why don't these guys get
>together with the innovative hardware houses, and get Ada compilers out
>simultaneously with new machines, especially parallel ones? Somehow
>these guys always manage to get the Fortran and C dialects written; 
>with Ada, because of the common front-ends, all they need to do is 
>write code generators that really exploit the machines. The language
>constructs are there already.
>
>How 'bout a math library (OK, so it's vendor-dependent) that uses
>overloaded operators to REALLY do vector and matrix stuff on
>parallel (vector) machines? What are you waiting for? They've
>already written the implementations, in C and Fortran; all you
>need to do is interface 'em nicely to Ada specs.
>
>I heard a neat story the other week about an Ada compiler for some
>vector machine or other that took a loop like
>
> FOR I IN 1..10 LOOP
>  A(I) := B(I) + C(I);
> END LOOP;
>
>and vectorized it. Nice, eh? But they took
>
> FOR I IN Index LOOP      -- Index is a subtype 1..10
>   A(I) := B(I) + C(I);
> END LOOP;
>
>and compiled all the code as a straight loop. Didn't they ever hear
>of subtypes?
>
>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?
>Or do they compile it as an element-by-element loop? That can make
>a big performance difference, can't it?
>
>Sheesh. This is what Ada's high-level constructs (tasking of course, but
>also universal array/record assignment, operator overloading, etc.)
>were supposed to be ABOUT. NOT one more me-too compiler for Sun SPARC.
>
>Miike Feldman

I know that Cray and Convex both have very good Ada compilers for
their vector-architecture machines. I know that the Cray compiler
has vectorizing capabilities every bit as good as their FORTRAN
compiler.

How about it, guys! Blow your own horn a little!! I, for one, would
like to hear your success stories!

Regards,

Bill Lee

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

[agate!library.ucla.edu!ddsw1!news.kei.com!sol.ctr.columbia.edu!math.ohio-]

In article <1993Aug4.090104.20732@sei.cmu.edu> ae@sei.cmu.edu (Arthur Evans) wr
ites:
>michael.hagerty@nitelog.com (Michael Hagerty) complains about the
>inability to direct an Ada compiler to store arrays so as to be
>compatible with Fortran.
>
>However, there is nothing that I can see to keep an Ada vendor from
>introducing some of the functionality of Section M.3 of the 9X document
>into an Ada-83 compiler by use of pragmas.  Go poke your favorite
>vendor!
>
That's just why I brought it up a few days ago. I'm poking _all_ of them
at once. IMHO they are just imitating each other anyway. They see only
each other as the competition while the rest of the world leaves them
behind.

There are a lot of aspects of Ada that are not getting exploited because 
the folks who do the compilers seem to do _only_ what the next contract's 
customer wants. It's the Beltway Bandit vs. the entrepreneur mentality. 

Another suggestion, unwelcome as it may be. Why don't these guys get
together with the innovative hardware houses, and get Ada compilers out
simultaneously with new machines, especially parallel ones? Somehow
these guys always manage to get the Fortran and C dialects written; 
with Ada, because of the common front-ends, all they need to do is 
write code generators that really exploit the machines. The language
constructs are there already.

How 'bout a math library (OK, so it's vendor-dependent) that uses
overloaded operators to REALLY do vector and matrix stuff on
parallel (vector) machines? What are you waiting for? They've
already written the implementations, in C and Fortran; all you
need to do is interface 'em nicely to Ada specs.

I heard a neat story the other week about an Ada compiler for some
vector machine or other that took a loop like

 FOR I IN 1..10 LOOP
  A(I) := B(I) + C(I);
 END LOOP;

and vectorized it. Nice, eh? But they took

 FOR I IN Index LOOP      -- Index is a subtype 1..10
   A(I) := B(I) + C(I);
 END LOOP;

and compiled all the code as a straight loop. Didn't they ever hear
of subtypes?

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?
Or do they compile it as an element-by-element loop? That can make
a big performance difference, can't it?

Sheesh. This is what Ada's high-level constructs (tasking of course, but
also universal array/record assignment, operator overloading, etc.)
were supposed to be ABOUT. NOT one more me-too compiler for Sun SPARC.

Miike Feldman

storing arrays for Fortran (was: QUERY ABOUT MONITOR)

[magnesium.club.cc.cmu.edu!news.sei.cmu.edu!ae]

michael.hagerty@nitelog.com (Michael Hagerty) complains about the
inability to direct an Ada compiler to store arrays so as to be
compatible with Fortran.

Valid point, and the fact that this problem is addressed and solved
in Ada-9X isn't much help to you this year.

However, there is nothing that I can see to keep an Ada vendor from
introducing some of the functionality of Section M.3 of the 9X document
into an Ada-83 compiler by use of pragmas.  Go poke your favorite
vendor!

Art Evans
----------------------------------------------
Arthur Evans, Jr, PhD           Ada Consultant
461 Fairview Road
Pittsburgh PA  15238-1933
412-963-0839
ae@sei.cmu.edu