From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,d901a50a5adfec3c X-Google-Attributes: gid103376,public From: "Dean F. Sutherland" Subject: Re: Fortran or Ada? Date: 1998/09/24 Message-ID: <360A5E7A.FBDFACB4@cs.cmu.edu>#1/1 X-Deja-AN: 394389655 Content-Transfer-Encoding: 7bit References: <98092310454016@psavax.pwfl.com> <6uboki$8qh$2@toralf.uib.no> <6ud2i4$sp4@gcsin3.geccs.gecm.com> To: John McCabe Content-Type: text/plain; charset=us-ascii Organization: Carnegie Mellon Univ. -- Computer Science Dept. Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 1998-09-24T00:00:00+00:00 List-Id: See http://www.adahome.com/Ammo/Stories/Tartan-Realtime.html for details. In later years we also supported C++ for the TI c3x/c4x DSPs. We found that Ada's more restricted semantics allowed us to do a much better job of optimization with less effort than we could for C++. It's not that the optimizations we did would have been _impossible_ in C++, but rather that normal C++ usage encourages things that are extremely difficult to analyze successfully. Most notably lots of aliasing that is usually benign -- but very hard to prove that it is so. We also built a capability for cross-module optimization of calls to pure functions and functions with no side-effects, with transitive analysis when needed. This was possible because A) the compiler could successfully prove the lack of side-effects in Ada (almost never possible in typical C++ code) and B) the compiler and program librarian could collaboratively keep track of the extra body dependencies introduced in the process (generally not possible in C++ either). All in all, I'd much rather be optimizing for Ada than for C++. The language deliberately makes lots of things easier. Dean F. Sutherland dfsuther@cs.cmu.edu ex-Tartan, ex-TI compiler optimization and code generation group John McCabe wrote: > > gisle@lunde.ii.uib.no (Gisle S{lensminde) wrote: > > <..snip..> > > >An example of this is the aliasing ( &variable ) in C. Because all > >variables can be pointed to, it is much harder to "optimize away" a > >variable. Ada is not as bad as C in this respect, and the strong typing > >should in fact make some optimization tecniques easier, > > I read an interesting article in one of Tartan's (now TI I think) > bulletins on the subject of optimising Ada Vs. C. It explained how Ada > code could be optimised better because of the strict rules on e.g. > function side effects, and how the library system (was it in Ada 83?) > could be used to allow optimisation (e.g. inlining of subroutines etc) > across compilation units in some cases. > > >but the total effort spent to make good Ada compilers is far less then > >the effort of making good Fortran compilers. > > Can you quantify that? > -- > Best Regards > John McCabe > > ===================================================================== > Not necessarily my company or service providers opinions. > =====================================================================