Pros and Cons of GNU toolchain

In article , ratemonotonic writes

It depends.

On your target. What you are making. What if any standards you have to work to. What if any product liability there is.

Anything that comes with : a) Hardware support after sale. b) Active mailing list. d) Good documentation. e) Tools that can be replaced with similar tools is a BIG advantage. f) Finally, I'd prefer tool chain that comes with less patches;) from kernel to libraries.

ali

I've been using nothing but Gnu tools for embedded work for 10 years (ARM, H8, MSP430, NIOS2). Couldn't be happier with them.

in your experience is GNU tools easyly replaceble by other commercial tool ?

If you design your code with this in mind in the first place, then - yes. The FreeRTOS.org code compiles with GCC, Keil/Keil, IAR, Keil/RVDS, Rowley (GCC with different project management and IDE), Raisonance (GCC with different project management and IDE).

..... not to mention all the non-ARM compilers.

Yep. Me too. The only exceptions are when clients use micros that aren't supported by GCC.

I've been lucky. :)

I came pretty close to chosing a Mitsubishi M16C part a few years ago (for which you couldn't even find commercial tools hosted on Linux), but the Hitachi H8/300 solution turned out to be a little cheaper (and has a much nicer memory model).

Some previous comments on this:

this:

Thanks a lot ! reading the comments and the links I have a lot more confidence in using GNU tools. FreeRTOS is a great site !

Well! it depends, if you stick to genuine GNU thing then chances are vital to get replacement of required tools. But if someone want you to buy proprietary software with GNU suit then its different story;)

ali

In theory you can fix that.

Maybe even in practice if you can find a supported one that is not too distant architecturally.

I "could", but I *do* have a life (family, etc ;-) I figure that if the device mfg want their micro to thrive, or the community thinks it should, then it will happen.

Although it's been done with some "interesting" architectures, GCC may not be easily portable to some micro-controller architectures. It is

At 50 years of age, I've learned that I really don't have time to do *everything* myself ;-)

... snip ...

You're quick. It took me longer. :-)

It seems to port well to CPUs with 16-bit address spaces like the 6812 and the MSP430. It helps that those CPUs handle

It deals pretty well with CISC architectures like the IA32,

Sad but true.

Damn! I have just four days to learn *something*.

Peter

One of the key points is that the gcc model works well when you have lots of similar registers. It's not the RISC style cpu that is the particular requirement, but multiple symmetric registers a characteristic commonly associated with RISC. For example, the 68k is a CISC architecture, but it has many RISCy features, such as multiple registers.

And the i386 target is an exceptional case for gcc - it is not a natural fit for gcc's models, but generates good code as a result of a huge effort in optimising the compiler for the i386.

David , Could you expand on 'similar registers' I dont understand. Rate

On the 68k, for example, there are eight data registers D0 .. D7, all of which can be used in exactly the same way at any time. Similarly, address registers A0 .. A6 are identical. ABI and compiler conventions use specific registers for specific purposes, but this is not enforced by the cpu, and the compiler has a free choice. Compare this to a true CISC processor like the i386, whose data registers A, B, C and D have different purposes and different instructions.