Re: And speaking of fast compilers...

sasdrf@unx.sas.com (Dave Frederick)
Mon, 16 Nov 1992 16:03:07 GMT

          From comp.compilers

Related articles
And speaking of fast compilers... pardo@cs.washington.edu (1992-11-12)
Re: And speaking of fast compilers... sasdrf@unx.sas.com (1992-11-16)
Re: And speaking of fast compilers... preston@dawn.cs.rice.edu (1992-11-17)
Re: And speaking of fast compilers... cheryl@gallant.apple.com (1992-11-17)
Re: And speaking of fast compilers... pardo@cs.washington.edu (1992-11-17)
Re: And speaking of fast compilers... pardo@cs.washington.edu (1992-11-23)
Re: And speaking of fast compilers... macrakis@osf.org (1992-11-24)
Re: And speaking of fast compilers... preston@miranda.cs.rice.edu (1992-12-03)
| List of all articles for this month |

Newsgroups: comp.compilers
From: sasdrf@unx.sas.com (Dave Frederick)
Organization: SAS Institute Inc.
Date: Mon, 16 Nov 1992 16:03:07 GMT
Keywords: performance, Ada, design, comment
References: 92-11-057

pardo@cs.washington.edu (David Keppel) writes:
|[comparing Ada compilers, compiler X was faster than compilers Y and Z
|even though X used C as an intermediate language.]


Not knowing any details of the compilers being used, but knowing a bit
about Ada from my previous job working on the global optimizer for an Ada
compiler (now there's an oxymoron :-), let me pose the following:


You say Compiler X is an Ada preprocessor for a C compiler. Has it passed
an Ada validation suite? Certainly, C does not perform the rigorous type
checking that Ada requires. Declaring i as a range (1..10) could make i
incompatible with an integer type. If the preprocessor simply checks
syntax, and then declares i as an integer in the C program, one loses
whatever power the Ada language offers. If C implements i as an integer,
but inserts code to test i at every assignment to determine if it is
within range, then the compile may be fast, but the runtime of the program
would be unendureable.


Most of the optimizations an Ada compiler performs are compile-time range
and bounds checking. If it can be determined during the compile that i
will always be in range, all assertion tests can safely be removed. If no
range errors are possible within the scope of an exception handler, this
code is dead and can be removed, as well. Similarly, if the compiler can
determine that a particular assignment will cause an exception, the
compiler can replace the assignment with a jump directly to the exception
handler. When performing such tests for all ranges, subranges, and array
indices, one can see how an explosion in compile time can occur.


One of the hot topics when I last worked on an Ada compiler was doing the
above range and bounds checking optimization across procedures in a
package. Interprocedural analysis is quite helpful for determining the
possibility of these errors on var parameters. Of course, with a 7000-line
package of page-sized procedures, we could be talking about 200-300
procedures on which to perform inter-procedural analysis. This could be a
week's worth of work.


Then again, perhaps the Brand X compiler was written in C, and Brand Y in
Ada. This could explain the difference, as well :-)


Dave Frederick sasdrf@unx.sas.com
[Compiling into C isn't any worse than compiling into assembler -- the Ada
compiler can do the same compile-time checking and emit run-time checking
either way. -John]
--


Post a followup to this message

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