Re: LPC900/80C51 Compiler Toolchain

In news:46813e27$0$8383$8404b019@xxxxxxxxxxxxxxx timestamped Tue, 26
Jun 2007 18:53:30 +0200, David Brown
<david@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> posted:
"wilco.dijkstra@xxxxxxxxxxxx wrote:
> On 26 Jun, 14:23, "Michael N. Moran" <mnmo...@xxxxxxxxxxxxx> wrote:
>> wilco.dijks...@xxxxxxxxxxxx wrote:
>>> On 25 Jun, 15:50, "Michael N. Moran" <mnmo...@xxxxxxxxxxxxx> wrote:
[..]
>>> I'd be surprised if the number of paid contributors is larger than the
>>> unpaid ones, or are you counting employees of companies whose main
>>> business is not open source?
>> Why wouldn't I count those whose main business is not
>> open source? Many have an interest in having their products
>> supported by GCC, and so they invest.
>
> The companies that hire fulltime staff to work on GCC are often just
> supporting their own products (eg. a backend for their proprietary
> CPU) and don't improve competing targets or GCC as a whole. Few large
> companies hire fulltime staff to improve the core of GCC, especially
> if they already have their in-house compiler. If resources are
> constrained, which is going to win?
>

Companies with a particular interest in the performance of gcc for a
given backend will support improvements to that backend, and to gcc as a
whole, as that's what benefits them. You are correct that they have
little interest in improving other backends, but front-end improvements
help them too.

>>> Big businesses have their reasons
>>> for contributing, but most have their own commercial compilers already
>>> - and that is where much of the effort goes.
>> Or perhaps they have found that having their own compiler is
>> unjustified when they could instead simply invest in the
>> community and have a comparable or better product by drawing
>> on a larger expertise.
>
> That is true for smaller companies who cannot afford to put a full
> compiler team in place. I know GCC is very popular with startups.
> However when you dig deeper many would create their own compiler if
> they could afford it as they are not that happy with the code quality
> they get. I do not believe that if you want comparable quality to
> commercial compilers that GCC would ultimately be a cheaper option.
>"

Less than five years ago, one of the main companies in the Symbian consortium
sent a recruitment advertisement for a short term contract which
interested me. I had applied but by the time someone with technical
knowledge has spoken with me, he has revealed that upon reconsideration it was
so difficult to find a suitable person that the notion of a short term
contract has been replaced with a longer term job. This did not suit
me as I would (and did) go to a planned better position which could
not begin until a number of months later. So I never worked on the job
of the advertisement nor the real job which replaced it. However, I
have been told during the technical conversation that the job would
entail replacing parts of the Symbian consortium's own inhouse C++
compiler with parts of the GNU C++ compiler's (at least the
frontend). Recruitment advertisements of the Symbian consortium's
which I looked at tended to offer rates of pay of approximately a few
hundred pounds sterling (approximately a few hundred dollars) a day or
a week or a month (I do not remember which, but even at a few
hundred pounds sterling a month it is not a very low rate of pay). I
do not remember if the rate of pay for this job was supposed to be
comparable.


"I'm sure Altera, Xilinx, and Atmel, amongst others, appreciate you
referring to them as "startups" or implying they have gone for the
cheapo option"

They have gone for what would naively seem to be a cheap option.

"because they are unwilling or incapable of "digging deeper".

Of course, they may perhaps have actively chosen to work on gcc ports on
the basis of past successes,"

In fairness, all of the compilers for Atmel AVRs except for GCC and
perhaps except for the Pascal compiler are apparently significantly
better than GCC. Atmel actively provided favoritism to a compiler
vendor to provide a good compiler for Atmel AVRs and eventually became
supportive to GCC for Atmel AVRs (even when GCC was one of the worst
compilers for these targets) and went much further by actively porting
GCC for AVR32s by itself before the first AVR32 was released. People
in Atmel may realize that no matter what price which is not gratis,
many people will prefer to spend money on an Internet connection and a
bigger chip to naively avoid paying for a cross compiler.

" expected future successes, value for their
investment in time and money, customer pressure, and supported source
code (such as a linux port to the architecture in question). In
particular, it is extremely unlikely that both Altera and Xilinx would
have made such total commitments to their gcc ports (there are, as far
as I know, no non-gcc compilers for their soft processors) if they
thought that a non-gcc compiler (in-house or external) would be
significantly better. Their competitiveness runs too deep to miss out
on such an opportunity - especially if, as you claim, it would be
cheaper overall."

I do not believe this. Altera and Xilinx could vastly improve items
essential to their businesses (e.g. their synthesis backends) in order
to be competitive but they do not. Third parties could write their own
compilers for NiosII and MicroBlaze if they wanted to.


"[..]

[..] No one who knows
what they are doing compiles with -O0 on any compiler, gcc or otherwise.

[..]"

Symbian runs on ARMs. The Symbian person I mentioned above seemed to
think that machine code is the lowest level anyone can go (in fairness,
in that job it probably would not have been possible to go any
lower). An out of date webpage written after I spoke to him is
WWW.Symbian.com/developer/techlib/v9.2docs/doc_source/faqsdk/faq_1026.html
which is clearly written by someone who did not (or who wrote for
people who do not) know how to type
info gcc "Invoking GCC" "Optimize Options"
as
WWW.Symbian.com/developer/techlib/v9.2docs/doc_source/faqsdk/faq_1026.html
contains:
"[..]
Created: 04/05/2004 Modified: 10/17/2005
[..]

[..]

Question:
I'm porting some code from standard C++ to Symbian OS and I'm using the newer GCC 3.x, which has some really good optimisation options. Can I use this for Symbian OS ?

Answer:
[..]

The short answer is 'No' - you can't use any GCC version beyond 2.9.
[..]

Now, the reasons why Symbian chose not to use anything other than -o0 is because that GCC 2.9x wouldn't handle some ARM optimisations very well, in many cases. Moreover, -o0 doesn't mean it is less optimised than -o2 for example; the 1-2-3 switches denote different kinds of optimisation (one is for speed, the other is for space, etc.)

Maybe if you really want to optimise some functions, you could compile them to assembler source first. In particular for number-crunching function that you may have written, you should consider compiling the source to assembler first and optimize by hand the few critical paths to gain the improvements you require."

Regards,
Colin Paul Gloster
.

Relevant Pages

  • Re: Whats the story with the "end of XP"?
    ... Support gives them access to the larger body ... The same compiler suite may be "best" in both ... In the case of ByteCraft compilers, you are truly expert in your field, you work closely and rapidly with customers if there are any issues, and you have top class testing and quality control. ... understanding the inner workings of a relatively simple compiler like GCC ...
    (comp.arch.embedded)
  • [RFC][PATCH-2.6] Clean up and merge compiler-*.h
    ... the kernel headers in include/linux to include/linux-abi. ... * Common definitions for all gcc versions go here. ... -/* Some compiler specific definitions are overwritten here ...
    (Linux-Kernel)
  • Lib X11 compile problem /Xlib.h:3573: error: syntax error before "_X_SENTINEL"
    ... checking for gcc... ... checking for C compiler default output file name... ... checking how to recognise dependent libraries... ...
    (comp.os.linux.x)
  • make error compiling sysbench for MySQL
    ... checking for gcc... ... checking for C compiler default output file name... ... checking libaio.h usability... ... checking libaio.h presence... ...
    (linux.redhat)
  • Newbie packages question
    ... checking for gcc... ... checking for C compiler default output file name... ... checking if the linker is GNU ld... ... checking how to recognise dependent libraries... ...
    (Debian-User)
Loading