Re: LPC900/80C51 Compiler Toolchain

Chris Hills wrote:
In article <46b2d8bc$0$3196$8404b019@xxxxxxxxxxxxxxx>, David Brown <david@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> writes
ChrisQuayle wrote:
Chris Hills wrote:

OK then can some one PROVE how FOSS compilers are more advanced or *at least* as good as commercial ones?
serious disadvantage now. Tool development is such a labour intensive and skilled process, with shrinking market, that they have to charge high prices just to stay in business, never mind keep up with the state of the art. A highly unstable market, with thousands of devices and variants to support and guessing which will be successfull and sell volume. Not a business I would want to be in at all.


There are some situations where commercial developers have advantages over open source developers - it is often easier to get restricted information (advance information, or extra technical details) from the microcontroller manufacturers. Even for those manufacturers which directly support gcc ports, there can be restrictions with some PHB wanting to keep details secret, which therefore cannot end up in open source code.

This is true.... there is a lot if NDA type work that goes on for months before the release of parts. I have been involved in one or two.


Sometimes open source programmers can get access to this sort of information, sometimes not (for example, I'm sure that the Atmel employees involved in avr-gcc development have access to non-public information, and I know that a couple of msp430-gcc developers have NDAs for access to debugger details, which are implemented in a small closed-source program). There are also situations where the open source development is at least partly behind closed doors (with the source released when it is finished) - development companies with this approach have little problem getting advance information. But in general, it can be easier to get secret information if you stick to closed source development.

The Silicon company was working with the compiler company before even the registers were fully named (or mapped out)

There is also currently only one serious, powerful open source compiler system - gcc.

However it is not really suited to the smaller end of the market.


Correct - it is a better match for bigger devices (although the avr-gcc port is solid despite a few mis-matches with gcc's expectations of a processor, and the msp430 port is fine).

So for architectures that don't fit gcc's models, there are currently no top-quality open source alternatives (sdcc is, as far as I understand it, a perfectly reasonable compiler - but it is not a top-ranking 8-bit compiler in the same way that gcc is for many 32-bit targets).

It is missing some important features that make it unsuitable for a lot of development


I don't know enough details to comment here - I've never actually used an 8051.

The other thing that commercial developers can do that open source developers typically do not, is spend time and money on everything *around* the compiler - documentation, installation, IDEs, debuggers, dedicated support teams

Yes. Absolutely

to help you out when the software license locking system has lost its keys, etc.

What license locking? ?You assume much. II sell several commercial compilers that have no locking on them at all. Most Sw these days has activation/locking.


Most software these days does not have locking or activation. Many types of software have some sort of registration or require a license key or number during installation, but few have any sort of locking (by which I mean some sort of check or validation before each run). The tools used in embedded development (both for software and hardware development) are unusual in this respect, in that locking of some sort is very common for commercial tools.

Any serious embedded developer can tell you horror stories of fights with licenses, ranging from broken hardware dongles, lost licenses after hard disk crashes or changing network cards, confusions over licensing policies resulting in waste time and money, long waits for license codes, issues when transferring the software to another computer, and other such problems. Some commercial software suppliers do a good job of minimising these issues, others can be a real pain, and the inconvenience is part of the price you have to pay for commercial software.

These sorts of things take time and effort, and are often not the most interesting parts of the job - it's fine if you are paid to do it, but for many open source developers and their employers, margins are smaller and it's harder to find the time and money to spend on less essential parts.

So they only do the bits they like or make money on?


It depends on who they are, and how they work. A volunteer coder working in his free time is likely to work on things that interest him. Others might contribute changes that improve the software for their own use while being unable to justify the time or money needed to make changes that don't benefit them or their employer. But there are other developers who are paid to work on open source projects - they will work on whatever their employers tell them to work on, just like any other paid programmer.

There are many different models for making money out of open source development, with some similarities and some differences from models for making money out of commercial software. That leads to different priorities for what people spend their time and money on.


As I see it, there is plenty of place for both commercial and open source development tools (and both high-price and "cheap and cheerful" price commercial tools) at the moment.

I agree.

What is interesting is the changes for newer architectures - steadily more manufacturers are going straight for a gcc port for newer 32-bit architectures, rather than the more traditional approach of working closely with a commercial developer.

This is incorrect. They do work with the commercial compiler vendors. However they usually do a port of gcc so there is a free tool so there is a low risk/cost entry point to trying out the new silicon. It is nothing to do with a belief in FOSS.


I did not say it was anything to do with "belief in FOSS". As an example, the AVR32 is supported by a gcc port written by or for Atmel. I would be very surprised if this is because Atmel has altruistic beliefs about open source - it is a purely pragmatic economic decision. I presume (I have no insider information - this is all guesswork) they knew their chip was useless without a high quality compiler, so they looked at how they could get such a compiler quickly and cheaply (for them), providing a compiler that is solid and cheap for developers, and which would be a good match for the sorts of software they expect to be used on the devices. The answer is a gcc port.

That of course does not mean that Atmel did not work with commercial vendors as well - IAR apparently makes an AVR32 compiler, although Atmel's website does not mention it under "Tools and Software". Clearly it is in Atmel's interest for there to be alternative toolsets. But there is little doubt that gcc is the "official" toolset for the AVR32 in Atmel's eyes, not just a cheapo alternative for hobby users.


The development process for these ports is often not very open (they work behind closed doors, and release binaries and corresponding source files in lumps), making it somewhat of a middle road.

Absolutely. Also the gcc port is usually created but not supported. IT is just there as is so there is a free/low risk way of evaluating the new silicon.


Ask Atmel (who employee some key avr-gcc developers, and who continually develop the AVR32 compiler, including ready-to-install versions for several Linux distributions), or Xilinx or Altera (who continually develop their gcc ports for their soft processors) whether they view it as a cheap way for customers to evaluate their processors.

It's not just the compiler either - The gcc suite has an excellent set of binary utilities, linker, make and archiver / librarian etc, which blend together seemlessly in a unix environment to produce a really top class development suite. Again, miuch more than can be said for some of the commercial vendors. If you want a good laugh, have a look at the utilities associated with earlier versions of the IAR H8 compiler and the command line options. Even Keil C wasn't that brilliant in terms of added value and that's a compiler that i've used extensively and respect quite a lot, even if the code it produces looks horrendous at times.


Many commercial toolsets are now using open source utilities,

Some

as well they should
Why? Many used to make a nice side line income doing utilities.


Maybe they used to, but why would anyone want to pay extra for a "make" utility? Why would any commercial developer want to pay its staff to write an editor, or a scripting language, when there are perfectly good ones available freely, written by experts at that kind of programming (which is very different from the area of expertise of the compiler writers)?

- for most parts not directly related to code generation, common open source versions of the tools are far better than anything anyone else

This is not true... I have a customer who's use of a FOSS utility cost them over 10K GBP in time and effort sorting out the problem.


Perhaps I should have added a "generally" or "usually" in there somewhere - there is always going to be someone somewhere that has problems. I had a customer who wasted over 10K GBP as a result of stupid licensing complications with a commercial embedded development toolkit - I don't expect you to suddenly think open source tools are always the better choice as a result of that single sample point.

makes. A good example is the Quartus design suite for Altera FPGAs - the compilation and routing parts are all closed source from Altera, but the glue that holds it together is cygwin, tcl, and perl - all open source versions. Their soft cpu is generated with closed-source programs, using tcl and perl, with Eclipse for the IDE and gcc for compilation.

Seems a sensible mix but note Altera is a HW company... to them software is simply a marketing tool.


Altera (and Xilinx, and others) spend more money on software development than hardware development. Software is the key to FPGA development - squeeze 10% more out of the chips by an improved placement algorithm, and you've gained 10% over your competition for *all* your customers, and *all* your devices, at zero cost per part. So Altera spends a huge amount of time and money getting its programmers to do what they do best - making software for FPGA development. It does not waste any time or money on making "glue" software to hold it together - they use what is freely available.

All the people who you mention who have "embraced" open source are HW companies who are selling HW and value Sw as a free give away.....


I was specifically giving examples of hardware companies which develop and support open source software.

There are some companies that make money directly from selling nothing but open source software, but most see open source as a way to make money in some other way - selling support, selling other software alongside the open source software, selling hardware, selling subscriptions for early-release versions of the software, selling pre-packaged software, and that sort of thing.

Open source values the programmer at Zero and I have seen nothing to change this view. In it act it is getting worse.


The programmers who develop open source software for a living, along with their employers, would be surprised to hear that.

There are certainly some areas where commercial software is becoming less competitive in the face of open source, and therefore some programmers will be out of work or have to change the way they make their living. But it's just like any other sort of competition - for the most part, the end-users get more choices and lower prices, while top-dog suppliers are no longer able to charge such huge margins. And just like any other sort of competition, it has its risks and casualties - too vicious competition can lead to a drop in quality due to price wars, and the middle-men often suffer or are made obsolete - that may be a good thing or a bad thing (obviously for you, as a reseller of commercial software, it's a bad thing - for end users, it can be good due to lower prices, or bad due to the loss of useful resources).
.

Relevant Pages

  • Re: Open64 Not Setting World on Fire: Why?
    ... Then you go on explaining how Pathscale may ... The point is that you don't make money buy selling the compiler itself ... I'm not trying to impugn the Open Source movement. ...
    (comp.lang.fortran)
  • Re: Inside an FBI Computer Forensics Lab
    ... properly reproduce or validate a piece of hardware. ... open source tools and well established procedures and methods are used ... like me could trivially design a black box which satisfied every ... possible to create a compiler that will recognizes your code during ...
    (alt.privacy)
  • Re: OT: efforts, emo crap...
    ... You cannot expect everybody to understand open source. ... for now, they want me to go to college, I guess this works. ... Liberate something which is only proprietory now. ... The Seed7 compiler now compiles to a C program which is ...
    (comp.lang.misc)
  • Re: LPC900/80C51 Compiler Toolchain
    ... There are some situations where commercial developers have advantages over open source developers - it is often easier to get restricted information from the microcontroller manufacturers. ... Even for those manufacturers which directly support gcc ports, there can be restrictions with some PHB wanting to keep details secret, which therefore cannot end up in open source code. ... no top-quality open source alternatives (sdcc is, as far as I understand it, a perfectly reasonable compiler - but it is not a top-ranking 8-bit compiler in the same way that gcc is for many 32-bit targets). ... Also the gcc port is usually created but not supported. ...
    (comp.arch.embedded)
  • RE: Micro$oft warns of undetectable spyware security risk ...
    ... Contrast this with a closed compiler ... The number of open source advocates who understand driver/kernel/os ... interest (remember they are likely not being paid to review all this ... bank building and vault available to everyone is going to make the bank ...
    (comp.os.vms)