Re: KEil bought by ARM

Chris Hills <chris@xxxxxxxxxxxx> writes:

> In article <87mzkrdzxj.fsf@xxxxxxxxxxxxxxxxxxxxxxx>, John Devereux
> <jdREMOVE@xxxxxxxxxxxxxxxxxx> writes
> >
> >Also, even if you accept that the commercial compilers are "better" at
> >code generation (I have not seen this):
> >
> >- gcc is getting better and better. Presumably there is a limit to how
> > good a commercial compiler can be, so any gap should be closing.
>
> It's not closing. Gcc is still about a decade behind. I get that figure
> independently from several compiler vendors and tool makers. In places
> Gcc is apparently an appalling mess.

Hmm, sounds like these all have a vested interest in saying that...

> It is certainly not a sensible choice for quite a few architectures.

Agreed, the PIC springs to mind. In fact all the older 8 bit parts
(those with very few registers).

> >- code space and MHz are getting cheaper and cheaper, so it makes less
> > and less difference anyway as time goes on.
>
> Not for embedded systems or the 8 bit market would have disappeared LONG
> ago.
>
> What is 50 cents sent difference on the MCU? well multiply it by 50K per
> hear and you get some idea! then there is the additional cost of the
> memory, the more complex PCB... the cost is on a size* pads* holes type
> equation. it all ads up and 1 dollar per board is 50,000 dollars per
> year.

Yes, for sufficient production quantities, even the smallest margin
becomes significant. Of course you can make the same arguments for C
vs assembler! We sell <1k boards per year, so it does not matter so
much. I imagine this is the case for many or most other developers
(since there are probably more "small" companies than big ones).

> The other problem is EMC... many want to run the MCU SLOWER not faster.
>
> >- It is getting easier and easier to justify using 32 bit parts (like
> > ARM) in new designs.
>
> YEs for some but there is a LONG way to go (if at all) before it will
> over take the 8 bit market.
>
> >I would expect the architecture of these parts
> > to more closely match gcc's abilities than, say, the 8051 where Keil
> > have been the leader.
>
> Yes Gcc can not hope to compete in the 8 and most 16 bit markets.

Actually avr-gcc is pretty good.

--

John Devereux
.

Relevant Pages

  • Re: Inexpensive ARM compilers
    ... >> commercial vs. GCC code generation has the commercial toolchains as ... then you find that the GNU compiler isn't at all bad. ... If GCC has reeled in some of the gap, I'm happy because the last two ...
    (comp.arch.embedded)
  • Re: [PATCH] Optimize generic get_unaligned / put_unaligned implementations.
    ... I worry about what impact that change might have on code generation. ... if gcc is good enough. ... It seems to assuming that the compiler will assume that members of packed ... structures can have arbitrary alignment, even if that alignment is obvious. ...
    (Linux-Kernel)
  • Re: GCC code quality, was Compiler Companies in Australia
    ... > I'm not sure what legacy part of GCC you think is holding it back. ... > I checked GCC 4.0 contains a pretty significant revamp of the internal ... All of these are evolving requiring new tools and code generation technology. ...
    (comp.compilers)
  • Re: Ray tracer
    ... Jon Harrop wrote: ... but it also runs a lot slower than your benchmark here. ... > Perhaps it is a bug in gcc 3.2, FP code generation maybe? ... GCC 3.2.2 has problems with this code. ...
    (comp.lang.scheme)
  • Re: cant prevent root lockout under Tru64/C2 security
    ... cost effective or even possible. ... and it's difficult if not impossible to bring gcc over ... > Contractual obligations, ... But getting gcc over to it to compile OpenSSH is non-trivial, ...
    (comp.security.ssh)