Re: Ada vs. C performance, was Possible to write compiler to

Craig Burley <burley@gnu.ai.mit.edu>
12 Jan 1997 11:29:01 -0500

          From comp.compilers

Related articles
Ada vs. C performance, was Possible to write compiler to Java VM? robison@kai.com (Arch Robison) (1997-01-07)
Re: Ada vs. C performance, was Possible to write compiler to Dave_Koogler_at_CCISDAPPS1@ppc-191.putnaminv.com (1997-01-09)
Re: Ada vs. C performance, was Possible to write compiler to burley@gnu.ai.mit.edu (Craig Burley) (1997-01-12)
Re: Ada vs. C performance, was Possible to write compiler to toon@moene.indiv.nluug.nl (Toon Moene) (1997-01-14)
Re: Ada vs. C performance, was Possible to write compiler to cdg@nullstone.com (Christopher Glaeser) (1997-01-17)
| List of all articles for this month |

From: Craig Burley <burley@gnu.ai.mit.edu>
Newsgroups: comp.compilers
Date: 12 Jan 1997 11:29:01 -0500
Organization: Free Software Foundation, 545 Tech Square, Cambridge, MA 02139
References: 97-01-045 97-01-065
Keywords: C, Ada, performance, Fortran

Dave_Koogler_at_CCISDAPPS1@ppc-191.putnaminv.com writes:


      >[Do Ada compilers really generate better code than C compilers for
      > similar source code? -John]


      This is very easy to prove: the Gnat Ada compiler is built upon the
      same code generator as the Gnu C compiler. When an algorithm is
      expressed in a similar fashion in the two languages, the resulting
      code is almost identical.


However, as I've learned working on g77, C has a definite advantage in
that it is the main (sometimes only) language favored by the design,
implementation, and maintenance of the gcc back end.


Though I don't know any Ada examples, having not looked at that
language in ages, I know the gcc back end doesn't provide direct ways
to express some Fortran constructs (like the lack of aliasing in
writes through pointers with writes through other pointers or
externals). I suspect Ada would suffer some from this as well.


The good news is that we're beginning to teach the gcc back end about
these new constructs -- at least, for g77, we're in the
experimental/development phase for some of them.


A minor example, that I believe rarely amounts to much in practice, is
that the gcc back end has no "and" and "or" operations at the tree
level. It has C's && and &, but no way to express Fortran's "L1
.AND. L2" such that the back end could decide, based on analysis, to
implement this as, in C's language, "L1 & L2", "L1 && L2", "L2 && L1",
"L1", "L2", "1", or "0".


Basically, for the most part, C is more of a low-level imperative
language than either Fortran or Ada, so while it tends to allow a
programmer who knows the fastest way to code something on a given
architecture to explicitly code that way, getting better results than
more straightforward code written in Fortran, Ada, or even C, C also
tends to produce slower code than Fortran or Ada when the code is
written in a straightforward fashion. (There are classes of problems
where C does much better than Fortran, and probably others with other
heightened advantages/disadvantages, but I'm referring to the large
class of problems each language has basically decent facilities to
handle.)


And, the gcc back end still caters primarily to the code-generation
needs of C and its offspring (mainly C++), so inherent advantages of
other languages aren't being highlighted by the gcc technology at this
point as much as some of think they will be in the future.
--
James Craig Burley, Software Craftsperson burley@gnu.ai.mit.edu
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.