Sorry, but you totally missed your target since your post does not contain anything about flexibility.


One more totally missed thrust. Lack of competence in C by the people who ask "why doesn't this work" is irrelevant to the ability of a compiler to support different cores or different architectures, or how hard it is to switch between different compiler vendors.


I think I have closer to 20 compilers installed. I have never seen this as a problem. One for a family of small PIC processors, one for a family of larger PIC processors, one for Atmel AVR, three for ARM (RVCT, gcc, Keil MDK), three for 16-bit x86 (Borland, Paradigm, MSC), three for 32-bit x86 (VC, MinGW, Cygwin gcc), one for ppc, ... And besides the different compilers, it isn't uncommon that I have more than one version of them too, since released products are normally locked to a specific compiler version.

The fact here is that after you have worked with a number of compilers, you will notice that it is way easier to move between different compilers (same vendor-different architectures, different vendors-same architecture, different vendors-different architectures) than it is to move betewen different architectures. And that it normally doesn't matter much if moving between two vendors when switching architecture or using a compiler that has support for both architectures. Any specific knowledge about gcc for ARM doesn't help much when you use gcc for PPC or gcc for AVR or gcc for x86, so in the end it is normally better to shop around for a compiler people think is very good than to select a compiler just because I have worked with other variantes in the "compiler family" or from the same vendor.


I'm not much helped knowing any bug list for WinAVR (gcc) if switching to ppc_8xx-gcc. The front-end is the same, but the important part of the compiler is normally the back-end. In the end, the two compilers are like night-and-day. And if you do suffer from bugs, you are way more likely to find the bugs in the backend than in the common code shared between the different variants.


Long time ago, I had to report a number of compiler bugs with the Borland and Microsoft compilers. I hate the Microchip compiler that can't even handle standard C constructs. The ancient Microsoft C compiler could be tricked into failing to compile sometimes because of bad register allocation strategies but then we are talking about a 20-25 year old compiler. I don't know much about the WinAVR compiler since I quickly decided to only use assembler for any AVR project.

But in the end, I have hardly ever had need to worry about problems with the compilers I use. The bugs are normally in the supplied GUI, and it is so easy to use Code::Blocks, Crimson or similar when editing the sources and use commandline compilation.

The big thing is to know C, and to know the target hardware. Differences between two compilers is more like differences between two chips in the same family, i.e. a very trivial problem to handle. I don't see it as important that SDCC supports multiple architectures. I would still jump around when selecting compiler based on the requirements for a specific project. gcc also has support for a multitude of architectures and I use gcc a lot for some platforms. For other platforms, I go for other compilers because I think they are better suited. That their command-line parameters are different or they require a new set of environment variables for their library and header directories or that their #pragmas or chip extensions differ a bit doesn't really matter in the end. It represents so tiny part of the project.

In the end, the linker configuration files are often way harder to handle than the differences with the compiler, since all vendors invents their own "clever" ways of scatter-load your binary. But if vendor A has way better compiler or RTL than vendor B for a specific architecture, then that will be the deciding factor - not the amount of work to create the linker configuration files.