Re: Compiler Companies in Australia

Steven Bosscher wrote:
>
> I don't want to go into a GCC-is-bad vs. GCC-is-good flame fest here,
> . . . the entire message is the usual unfounded GCC bashing
> which does not belong in this forum.


This should not become a flame war there is a place for GCC by
the same token it is also not the universal answer, specifically
my response was to the claim that said “. . . and it's
extremely difficult nowadays for a commercial
product to compete with something like gcc on the basis
of code quality.”


My comments are also, “Not the usual unfounded GCC bashing”


My earlier post had three points,


1) I disagree with the claim that commercial compiler
        offerings have difficulty competing with GCC on
        the basis of code quality.


2) GCC’s long historical roots make it difficult and
        expensive to bring it up to current commercial code
        generation requirements because of this lineage


3) There is an ever widening gap between GCC and
        accepted international standards. (ISO C for example)


I stand by my points


> > While GCC users still talk about the advantage of using it despite
> > the expected 20 to 30% hit is code size against well written
> > assembly code, commercial compiler vendors routinely produce
> > compilers that produce code as tight or tighter than very good
> > disciplined assembly programers.
>
> I'd be interested to hear about the research you might have done to
> make this kind of claim. What compilers have you compared, on what
> platforms? What did the numbers look like? If you check out e.g.
> the CSiBE (http://www.inf.u-szeged.hu/csibe/) numbers for i686, and
> you compare Intel CC 8.1 to GCC mainline at -Os, you'll see that the
> icc generated code is 14% larger than what GCC produces. At -O3 the
> icc binaries are 12% smaller, but the gcc ones run slightly faster.


How does GCC compare to well written hand coded assembler?
We have developed commercial compilers for about 25 years and
regularly run benchmarks on our own and other compilers that
leads us to similar conclusions found by others.


At the end of this message is a copy of a post by "Paul Curtis" from
the MSP430group supporting the TI MSP430 a 16 bit processor
that should be well suited to a GCC port. GCC’s code generation
did not do well (last of three).


> What do you mean, "language actually conforming to a standard"? Are
> you saying GCC front ends do not conform to the standards? . . . and GNU C is close to C99 conformance
> (see e.g. http://gcc.gnu.org/c99status.html).


There is no mention in this url of GCC having actually been tested
for conformance or in plans to do so. We once used language
conformance defects lists to identify the GCC lineage of an unknown
C compiler.


> What kind of new data types do you mean.


The Fract and Accum fixed point data types of ISO/IEC DTR 18037.
The same document outlines support for named and user defined
address space and direct processor register access. Features that are
in current commercial compilers.




> What restrictions?


GCC is easily ported to a new architecture from a core of software
that has been developed of many years. There is a price for this
portability in terms of code generation and feature support. The
structure of the compiler limits code generation by historical code
generation technology and compiler structure. The compromises
of many different CPU targets have inevitably meant that GCC
compilers generate code for a subset of the target processors
instruction set. This can be statically tested with a histogram plot
of instruction set usage on generated code.


w..




========"Paul Curtis" message about GCC================
>
Subject: RE: [msp430] Re: which C-compiler produces the smallest code size?
Date: Wed, 15 Sep 2004 09:41:04 +0100
From: "Paul Curtis" <plc@rowley.co.uk>
Reply-To: msp430@yahoogroups.com
To: <msp430@yahoogroups.com>
>
Hi Andreas,
>
> > Actually, if you use some real benchmarks such as MiBench or the TI
> > benchmarksm GCC produces the worst code of the lot... In
> one case, on
> > an MSP430F149, it won't fit an application into flash,
> whereas all other
> > compilers do.
>
> This is contrary to my experience. Can you give numbers?
>
Ok, let's put this "GCC produces the smallest code and is a good
compiler" myth to bed, shall we?
>
At http://www.rowley.co.uk/msp430/mibench.zip is the Susan benchmark
from MiBench at http://www.eecs.umich.edu/mibench/. MiBench is an image
processing benchmark and uses fixed-point math almost exclusively.
>
I compiled this for MSP430 using GCC, CrossWorks, and EW430.
>
                                GCC IAR RAL
                                            EW430 XWorks
                          ------ ------ ------
Code size: 29,998 16,732 16,198
Const ssize: 15,286 15,801 15,770
                          ------ ------ ------
                          45,284 32,553 31,968
>
The interesting thing here is CODE SIZE not CONST SIZE (which is a
fixed-size array). The code produced by CrossWorks and by IAR is half
the size of GCC. HALF THE SIZE! 30K vs 16K. ...and GCC produces small
code...
>
So, is GCC a good compiler? No, in this case, far from it. If
someboduy can get anywhere near the code size of EW430 or CrossWorks
using GCC, just let me know what settings to use and I'll post again, or
you can post. Even considering a non-optimized floating point library,
it doesn't take up 14K of code.
>
GCC Environment: I used -O1 which generates the smallest code, and
compiled for an F149 with multiplier; I had to supply dummy exp and sqrt
functions for GCC, I don't know how to get them linked in (-lm didn't
help). So, if sqrt and exp *were* added, the GCC sizes would be even
worse...

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