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,4b12a5cee4778f63 X-Google-Attributes: gid103376,public From: Tucker Taft Subject: Re: GNAT & GCC performace (bad news) Date: 1999/12/07 Message-ID: <384D4A80.DBAA4E67@averstar.com>#1/1 X-Deja-AN: 557788105 Content-Transfer-Encoding: 7bit Sender: news@inmet.camb.inmet.com (USENET news) X-Nntp-Posting-Host: houdini.burl.averstar.com References: <38473D90.68D8F47@acenet.com.au> <1999Dec3.103807.1@eisner> <82fgh2$mt3$1@nnrp1.deja.com> <1999Dec6.073729.1@eisner> <82hn65$a5o$1@nnrp1.deja.com> X-Accept-Language: en Content-Type: text/plain; charset=us-ascii Organization: AverStar (formerly Intermetrics) Burlington, MA USA Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 1999-12-07T00:00:00+00:00 List-Id: Robert Dewar wrote: >... > However, it is fundamentally flawed in terms of achieving the > best possible efficiency, and surely this approach would never > be chosen except for the pragmatic considerations of the > previous paragraph. Actually, we have been pretty pleased with using optimized ANSI C as an intermediate. However, we put in a lot of effort to generate "good" C, and to preserve as much information as possible in the generated C, to allow the C compiler to do further code optimization. > > Why? > ... > One very significant area is nested procedures. There are > compilation approaches which generate extremely efficient code > for nested procedures, but since C has not nested procedures, > the Ada front end must "fake" the access to nested procedures. > This means typically that you end up having to address local > variables in an inefficient manner that may well disrupt the > register allocation phase of the target C compiler. There are > basically two ways of faking nested procedures, either by > using address vectors (which tend to force locals into memory) > or my representing the locals as fields of a record (and many > compilers will not treat such fields nearly as efficiently as > stand alone local variables). For nested procedures, we pass a record, but only the variables that are actually "up-level" referenced end up as fields in the record, so this minimizes the effect. > ... > Nevertheless, I think in practice you will find that the hybrid > approach is often disappointing. Indeed Tuck mentioned to me > that Intermetrics had been disappointed in at least one C > compiler that they were using as a back end. We haven't had any real code quality concerns recently, for what it is worth. With our current translation approach, our belief is that we would not do any better by connecting into the C back end directly, bypassing the C front end. In fact, the C front end includes some high-level loop-oriented optimizations, so the code has the potential of being better than if we joined up directly to the back end. Of course, if the back end were Ada specific, then there is the potential for more Ada-specific optimizations, but we trade that off against the advantage of sharing technology with the C compiler suite, thereby reducing the amount of Ada-specific technology that needs to be developed, maintained, enhanced, etc. There are certainly tradeoffs, but we are pretty happy with the C-based compilers we have, as well as with the ones that connect directly into backends. > ... > Robert Dewar > Ada Core Technologies -- -Tucker Taft stt@averstar.com http://www.averstar.com/~stt/ Technical Director, Distributed IT Solutions (www.averstar.com/tools) AverStar (formerly Intermetrics, Inc.) Burlington, MA USA