From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.5-pre1
Date: 5 Aug 93 01:16:33 GMT
From: agate!library.ucla.edu!ddsw1!news.kei.com!sol.ctr.columbia.edu!math.ohio-
state.edu!cs.utexas.edu!swrinde!menudo.uh.edu!nuchat!leeweyr!bill@ucbvax.Berkel
ey.EDU  (Bill Lee)
Subject: Re: storing arrays for Fortran (was: QUERY ABOUT MONITOR)
Message-ID: <1993Aug5.011633.4394@leeweyr.sccsi.com>
List-Id: <comp.lang.ada>

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