Forums

LPC900/80C51 Compiler Toolchain

Started by Unknown June 20, 2007
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