LPC900/80C51 Compiler Toolchain

In news:1182835685.747074.263080@m36g2000hse.googlegroups.com
timestamped Mon, 25 Jun 2007 22:28:05 -0700,
wilco.dijkstra@ntlworld.com posted:
     "On 25 Jun, 15:50, "Michael N. Moran" <mnmo...@bellsouth.net> wrote:
     > wilco.dijks...@ntlworld.com wrote:
     > > And this is where I think commercial development has the
     > > advantage. Compiler vendors find and pay the best people
     > > to do whatever it takes to make the compiler as good as
     > > possible (with the idea that this large investment will
     > > pay itself off later). I don't see this kind of
     > > dedication in open source compilers, as developers
     > > usually don't get paid for their work and so don't
     > > attract the best people.
     >
     > This is non-sense. I think you'll find that most of the GCC
     > developers are being paid to work on GCC."

Even if all people to contribute to GCC are all being paid to do so,
Wilco Dijkstra's point still valid: a dedicated team being paid to
work in a fulltime manner to make a proprietary compiler will probably
try with quite good success to make a quite good compiler. (Exceptions
have existed.)

     ">
     > Just look at the GCC steering committee:
     >   <http://gcc.gnu.org/steering.html>
     >
     > Next, you may want to look at the list of contributers:
     >   <http://gcc.gnu.org/onlinedocs/gcc/Contributors.html> "

Many people who contribute to GCC are not listed on any of those webpages.
     
     "I'd be surprised if the number of paid contributors is larger than the
     unpaid ones,"

I expect that few of these people are unemployed. They may be paid to
do something, and they may deem GCC to be useful for performing some
of their jobs' duties so may choose to use some of their paid time to
contribute to GCC.

     " or are you counting employees of companies whose main
     business is not open source?"

Of course such employees are counted.

     " How many companies are there whose main
     business is developing or maintaining GCC? [..]"

I suspect very few.
     
     "> While GCC work *may* be done by anyone, serious
     > development and maintenance of this cornerstone of
     > Free Software is mostly done by paid skilled professionals,
     > whose employers understand the value of the GCC.
     
     If that was true I would expect GCC to be far better than it is today.
     >From what I've seen issues can take a long time to fix. [..]

     [..]"

Patches for AVR-GCC can take over a year to get through to the main
GCC repository, chiefly because the active maintainers of the time of
the AVR-GCC port did not have permission to write into the main GCC
repository and most people who did have permission did not care. As
mentioned by the lesser inactive of the two official AVR-GCC
maintainers of the time on
HTTP://lists.GNU.org/archive/html/avr-gcc-list/2006-09/msg00010.html
:"[..]

Generally, they (GCC peoples) don't bothered about AVR port. It's just
an 8-bits microcontroller. They are right. 

[..]"

Regards,
Colin Paul Gloster

Michael N. Moran wrote:
> Chris Hills wrote:
>> In article <FCQfi.7283$G9.2019@bignews6.bellsouth.net>,
>> Michael N. Moran <mnmoran@bellsouth.net> writes
>>> wilco.dijkstra@ntlworld.com wrote:
>>>> And this is where I think commercial development has
>>>> the advantage. Compiler vendors find and pay the best
>>>> people to do whatever it takes to make the compiler
>>>> as good as possible (with the idea that this large
>>>> investment will pay itself off later). I don't see
>>>> this kind of  dedication in open source compilers, as
>>>> developers usually don't get paid for their work and
>>>> so don't attract the best people.
>>>
>>> This is non-sense. I think you'll find that most of the
>>> GCC developers are being paid to work on GCC.
>>
>> Like Linux. Gcc is now commercial
> 
> Free-as-in-speech, not (necessarily) free-as-in-beer.
> Contrary to popular FUD, Free Software is not about
> preventing commerce.
> 

As an example, so that Chris can understand the principle involved, Code 
Sourcery sell gcc toolchains for the ARM and the ColdFire (and possibly 
others).  You have three options - free downloadable versions, paid 
subscription versions (which lead the free versions by about 6 months, 
and come with better hardware debugger support and integrated Eclipse 
setup), and professional subscription versions (which come with full 
support contracts).  Each is available in windows and linux versions, 
both as easily install binary and source.  So Code Sourcery makes money 
out of selling open source tools along with support contracts and added 
extras.  This money pays for their business, and it pays the salaries of 
their programmers - who work on gcc (and related tools).  Code Sourcery 
is the official maintainer of the ARM and ColdFire ports, and if you 
look at the changelogs of gcc you'll see their names scattered over wide 
ranges of gcc.

This gives the customer a wide choice of how they want to work, and how 
much they want to pay for it.  You get everything from free to 
top-quality commercial service, and you can choose from 
compile-from-source to gui install and IDE, and there is a solid and 
serious commercial company behind it all.

There are, of course, lots of other major companies backing gcc and 
paying developers (Intel, AMD, IBM, Atmel, Red Hat, Novel, etc., etc.) - 
Code Sourcery is just one example.

In news:7a70arEKh8fGFANC@phaedsys.demon.co.uk timestamped Mon, 25 Jun
2007 14:51:06 +0100, Chris Hills <chris@phaedsys.org> posted:
     "[..]
     
     [..]  AFAIK SDCC has no simulator/debugger"

SDCC does have its own simulator and debugger. They however were not
integrated very well by default with the C debugging information from
a version of SDCC (sic) from 2007: the debugger would show assembly
instructions near but away from the instructions which were really
being stepped through.

One of the compilers which is apparently supported very well by
the 8051 simulation and debugging facilities of BoxView IDE is SDCC:
WWW.DomainTec.com/BoxViewIDEDSP.html

wilco.dijkstra@ntlworld.com wrote:
> On 25 Jun, 15:50, "Michael N. Moran" <mnmo...@bellsouth.net> wrote:
>> I think you'll find that most of the GCC
>> developers are being paid to work on GCC.
>>
>> Just look at the GCC steering committee:
>>   <http://gcc.gnu.org/steering.html>
>>
>> Next, you may want to look at the list of contributers:
>>   <http://gcc.gnu.org/onlinedocs/gcc/Contributors.html>
> 
> 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.

> How many companies are there whose main
> business is developing or maintaining GCC? Do they pay competitive
> rates to hire top compiler experts? 

Do you have evidence to the contrary? I suppose
you could e-mail and ask them. However, my impression
is that the GCC maintainers are well respected. I have
been following the gcc@gcc.gnu.org mailing list for
years, and I can tell you that my perception is there
are plenty of compiler experts that guide and contribute
and plenty of others to do the more "mundane."

> 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.

>> While GCC work *may* be done by anyone, serious
>> development and maintenance of this cornerstone of
>> Free Software is mostly done by paid skilled professionals,
>> whose employers understand the value of the GCC.
> 
> If that was true I would expect GCC to be far better than it is today.

Apparently you've had a bad experience. My experience
has been much better. Are there bugs? Sure. Have I seen
bugs in commercial compilers? Sure. I have received a
*very* fast bug fix for GCC H8. Compiler's have bugs.

>>From what I've seen issues can take a long time to fix. I remember the
> __irq issue on ARM that went unfixed for quite a while (numerous
> people encountered that one), and I think the register allocator still
> has problems in generating many unnecessary move instructions since a
> change several years ago. In a commercial environment these would be
> "must fix before release" kind of bugs.

OK, GCC is not perfect. What compiler is? And yes, I
have used GCC for ARM, building the Linux kernel and
many user-space applications on two different ARM
platforms without issues.

> Other things like -O0 generating ridiculously inefficient code and
> emitting frame pointers when few compilers do so today do not instill
> a professional image. 

Uhhh... -O0 is turning all optimization off. Why would
you expect efficient code?

> I once read a paper that showed a 5% codesize
> improvement on ARM by changing a few defaults. Again, that was a few
> years ago, has it been implemented yet?

In the "words" of my son ... idk ;-)

>>> The ARM port of GCC for example was neglected for years
>>> (with Thumb not working at all) until ARM paid for it to
>>> be fixed and brought up to date with the latest
>>> architectures.
>> Demand drives GCC just like demand drives the commercial
>> compilers.
> 
> It would be good if GCC was developed more like a commercial compiler
> indeed. Maybe that is what will happen in the future, but I don't
> think it is anywhere near yet. GCC may have lots of fashionable
> optimizations but I'd prefer stuff to work reliably and efficiently
> first.

Unlike commercial compilers, GCC supports a huge number
of targets including 64,32,16 and 8 bit processors. Evolving
an infrastructure capable of doing this is time consuming, 
and as a result GCC *may* not always have the absolute best
code generation for any particular target, but the compiler
is passionately maintained and is constantly evolving.


-- 
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
Kennesaw, GA, USA 30144    http://mnmoran.org

"So often times it happens, that we live our lives in chains
  and we never even know we have the key."
The Eagles, "Already Gone"

The Beatles were wrong: 1 & 1 & 1 is 1

On 26 Jun, 14:23, "Michael N. Moran" <mnmo...@bellsouth.net> wrote:
> wilco.dijks...@ntlworld.com wrote:
> > On 25 Jun, 15:50, "Michael N. Moran" <mnmo...@bellsouth.net> wrote:
> >> I think you'll find that most of the GCC
> >> developers are being paid to work on GCC.
>
> >> Just look at the GCC steering committee:
> >>   <http://gcc.gnu.org/steering.html>
>
> >> Next, you may want to look at the list of contributers:
> >>   <http://gcc.gnu.org/onlinedocs/gcc/Contributors.html>
>
> > 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?

> > 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.

> >> While GCC work *may* be done by anyone, serious
> >> development and maintenance of this cornerstone of
> >> Free Software is mostly done by paid skilled professionals,
> >> whose employers understand the value of the GCC.
>
> > If that was true I would expect GCC to be far better than it is today.
>
> Apparently you've had a bad experience. My experience
> has been much better. Are there bugs? Sure. Have I seen
> bugs in commercial compilers? Sure. I have received a
> *very* fast bug fix for GCC H8. Compiler's have bugs.

I wouldn't call it a bad experience. I am simply used to the best
compilers as I've worked on them and improved myself. What I'm saying
is that GCC looks bad if you compare it to commercial compilers. A
while ago I wrote some optimised C code for a client and found that
GCC produced 40% larger code... If you don't care about this then you
can be perfectly happy with GCC.

> >>From what I've seen issues can take a long time to fix. I remember the
> > __irq issue on ARM that went unfixed for quite a while (numerous
> > people encountered that one), and I think the register allocator still
> > has problems in generating many unnecessary move instructions since a
> > change several years ago. In a commercial environment these would be
> > "must fix before release" kind of bugs.
>
> OK, GCC is not perfect. What compiler is? And yes, I
> have used GCC for ARM, building the Linux kernel and
> many user-space applications on two different ARM
> platforms without issues.

Sure, I'm not expecting it to be perfect or even as good as commercial
compilers. But open source advocates often claim that they can go in
and fix bugs much faster than in a commercial environment. This is
simply untrue in most cases - if anything, the timescales for bugfixes
in GCC are worse. Of course if you *pay* for a support contract then
your experience may be better.

> > Other things like -O0 generating ridiculously inefficient code and
> > emitting frame pointers when few compilers do so today do not instill
> > a professional image.
>
> Uhhh... -O0 is turning all optimization off. Why would
> you expect efficient code?

Turning off all optimizations achieves what exactly? Usually the goal
of -O0 is fast compilation and generate code that is easy to debug.
Turning off all optimizations does not achieve either goal. It may be
counter intuitive, but compiling optimised code is often faster than
compiling unoptimized code. When I debug code, I'd like to see local
variables in registers rather than being distracted by all the spill
code.

> > It would be good if GCC was developed more like a commercial compiler
> > indeed. Maybe that is what will happen in the future, but I don't
> > think it is anywhere near yet. GCC may have lots of fashionable
> > optimizations but I'd prefer stuff to work reliably and efficiently
> > first.
>
> Unlike commercial compilers, GCC supports a huge number
> of targets including 64,32,16 and 8 bit processors. Evolving
> an infrastructure capable of doing this is time consuming,
> and as a result GCC *may* not always have the absolute best
> code generation for any particular target, but the compiler
> is passionately maintained and is constantly evolving.

Agreed. I hope it does improve further.

Wilco

wilco.dijkstra@ntlworld.com wrote:
> On 26 Jun, 14:23, "Michael N. Moran" <mnmo...@bellsouth.net> wrote:
>> wilco.dijks...@ntlworld.com wrote:
>>> On 25 Jun, 15:50, "Michael N. Moran" <mnmo...@bellsouth.net> wrote:
>>>> I think you'll find that most of the GCC
>>>> developers are being paid to work on GCC.
>>>> Just look at the GCC steering committee:
>>>>   <http://gcc.gnu.org/steering.html>
>>>> Next, you may want to look at the list of contributers:
>>>>   <http://gcc.gnu.org/onlinedocs/gcc/Contributors.html>
>>> 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.
> 

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 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, 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.

<snip>

>>> Other things like -O0 generating ridiculously inefficient code and
>>> emitting frame pointers when few compilers do so today do not instill
>>> a professional image.
>> Uhhh... -O0 is turning all optimization off. Why would
>> you expect efficient code?
> 
> Turning off all optimizations achieves what exactly? Usually the goal
> of -O0 is fast compilation and generate code that is easy to debug.
> Turning off all optimizations does not achieve either goal. It may be
> counter intuitive, but compiling optimised code is often faster than
> compiling unoptimized code. When I debug code, I'd like to see local
> variables in registers rather than being distracted by all the spill
> code.
> 

The answer is quite simple - don't run with all optimisations turned off 
if you want some optimisations turned on.  Like you, I prefer some 
minimal optimisations, such as variables in registers, when looking at 
the generated code.  Normally I'd always use -O2 (or -Os, depending on 
the target), but for some debugging -O1 is convenient.  No one who knows 
what they are doing compiles with -O0 on any compiler, gcc or otherwise.

mvh.,

David

>>> It would be good if GCC was developed more like a commercial compiler
>>> indeed. Maybe that is what will happen in the future, but I don't
>>> think it is anywhere near yet. GCC may have lots of fashionable
>>> optimizations but I'd prefer stuff to work reliably and efficiently
>>> first.
>> Unlike commercial compilers, GCC supports a huge number
>> of targets including 64,32,16 and 8 bit processors. Evolving
>> an infrastructure capable of doing this is time consuming,
>> and as a result GCC *may* not always have the absolute best
>> code generation for any particular target, but the compiler
>> is passionately maintained and is constantly evolving.
> 
> Agreed. I hope it does improve further.
> 
> Wilco
> 

On Mon, 25 Jun 2007 22:28:05 -0700, wilco.dijkstra wrote:

> and
> emitting frame pointers when few compilers do so today do not instill
> a professional image. 

The embedded code I have written is mostly C code, and I very rarely look
at the assembler code. But that comment caught my attention because I
thought that almost all compilers, particularly 32-bit ones, use stack
frames and with frame pointers - or am I interpreting that comment
incorrectly?

Regards,

Paul.

On Mon, 25 Jun 2007 22:28:05 -0700, wilco.dijkstra wrote:

> Other things like -O0 generating ridiculously inefficient code 

I'm possibly showing my naivity here - I'm certainly not on expert on
these matters, but isn't there a step in the compilation process just
before optimisations (after tokenizing/parsing) that gets an internal
representation of the source code (RTL with the GCC?), and where that step
in the process is essentially a "dumb" part of the process, with the
really clever bit, the optimisations, occurring *after* this step?

If so, then a compiler writer surely is going to need access to this
unoptimised code at least for unit tests (or whatever gcc uses)? In which
case -O0 is how you get at it. Unoptimised code is always going to be
ridiculously inefficient, and you really wouldn't want to use it. Again
I'm not an expert on the compilation process, but the above is my
understanding as of now - please enlighten me :-)

Regards,

Paul.

Paul Taylor wrote:
> wilco.dijkstra wrote:
> 
>> and emitting frame pointers when few compilers do so today do not
>> instill a professional image.
> 
> The embedded code I have written is mostly C code, and I very
> rarely look at the assembler code. But that comment caught my
> attention because I thought that almost all compilers, particularly
> 32-bit ones, use stack frames and with frame pointers - or am I
> interpreting that comment incorrectly?

If the machine uses a stack, and the compiler keeps careful track
of the state of that stack, it can generate SP relative addresses. 
However this normally requires other restrictions on the generated
code.

-- 
 <http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
 <http://www.securityfocus.com/columnists/423>
 <http://www.aaxnet.com/editor/edit043.html>
                        cbfalconer at maineline dot net



-- 
Posted via a free Usenet account from http://www.teranews.com

wilco.dijkstra@ntlworld.com wrote:
> On 26 Jun, 14:23, "Michael N. Moran" <mnmo...@bellsouth.net> wrote:
>> Apparently you've had a bad experience. My experience
>> has been much better. Are there bugs? Sure. Have I seen
>> bugs in commercial compilers? Sure. I have received a
>> *very* fast bug fix for GCC H8. Compiler's have bugs.
> 
> I wouldn't call it a bad experience. I am simply used to the best
> compilers as I've worked on them and improved myself. What I'm saying
> is that GCC looks bad if you compare it to commercial compilers. A
> while ago I wrote some optimised C code for a client and found that
> GCC produced 40% larger code... 

I'm not sure what "optimized C code" is. Source that
is optimized for one compiler may be pessimized to another.
BTW, 40% is a bad experience. ;-)

>> Uhhh... -O0 is turning all optimization off. Why would
>> you expect efficient code?
> 
> Turning off all optimizations achieves what exactly? Usually the goal
> of -O0 is fast compilation and generate code that is easy to debug.

Yep.

> Turning off all optimizations does not achieve either goal. It may be
> counter intuitive, but compiling optimised code is often faster than
> compiling unoptimized code. 

Maybe.

> When I debug code, I'd like to see local
> variables in registers rather than being distracted by all the spill
> code.

If your debugging in assembler mode then I suppose that's
reasonable, but at the source code level it wouldn't be
an advantage.

>> Unlike commercial compilers, GCC supports a huge number
>> of targets including 64,32,16 and 8 bit proces
>>> It would be good if GCC was developed more like a commercial compiler
>>> indeed. Maybe that is what will happen in the future, but I don't
>>> think it is anywhere near yet. GCC may have lots of fashionable
>>> optimizations but I'd prefer stuff to work reliably and efficiently
>>> first.sors. Evolving
>> an infrastructure capable of doing this is time consuming,
>> and as a result GCC *may* not always have the absolute best
>> code generation for any particular target, but the compiler
>> is passionately maintained and is constantly evolving.
> 
> Agreed. I hope it does improve further.

Roger
> Wilco


-- 
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
Kennesaw, GA, USA 30144    http://mnmoran.org

"So often times it happens, that we live our lives in chains
  and we never even know we have the key."
The Eagles, "Already Gone"

The Beatles were wrong: 1 & 1 & 1 is 1