Free ARM Compilers?

In case you're looking for a Windows-hosted version, let me add a third one:

This one has support for other languanges than C and C++ and was compiled with the MinGW environment instead of the more common CygWin. The benefit is that its smaller, faster and doesn't require the CygWin runtime DLL to work.

But all these differences are a matter of taste and mostly details.

Regards, Andras Tantos

Andras,

Thanks for responding. I had lost track of your site and was hoping you were paying attention here. Can you say briefly what is different between the 3.3.1 or the 3.4.0?

Yeah, DynDNS simple DELETED my account! Anyway, it's back online now and thanks for noting that...

The main difference between the 3.3 and 3.4 line of GCC is the new C++ parser code that got into 3.4. As usual, that fixes a lot of old issues and introduces a whole set of new ones. Most of the changes are around template handling and as such does not really make that much of a difference for embedded developers. The whole (overwhelming) list is here:

Regards, Andras Tantos

Yeah, DynDNS simple DELETED my account! Anyway, it's back online now and thanks for noting that...

The main difference between the 3.3 and 3.4 line of GCC is the new C++ parser code that got into 3.4. As usual, that fixes a lot of old issues and introduces a whole set of new ones. Most of the changes are around template handling and as such does not really make that much of a difference for embedded developers. The whole (overwhelming) list is here:

Regards, Andras Tantos

For ARM users, an important item on the list is the floating-point which got literally several times faster with the new hand-coded routines.

Karl Olsen

Do you have any figures for the actual floating point performance on, say, a

Andrew

I did some single-precision tests for + - * / with the Keil simulator (which assumes 0 waitstates).

Clocks for gcc-3.3.1, clocks for gcc-3.4.3, speedup:

__addsf3: 514 73 7.0x __subsf3: 511 74 6.9x __mulsf3: 428 49 8.7x __divsf3: 634 142 4.5x

If you are using newlib (and you do, if you use the

extern float __ieee754_sqrtf(float x); a = __ieee754_sqrtf(b);

is much faster than

#include a = sqrtf(b);

sqrtf() is a wrapper around __ieee754_sqrtf() and adds the C error handling (errno and matherr()) stuff. Many similar __ieee754_ math functions exist which remove the C error handling from the math functions. The unwrapped functions just return Inf and NaN as appropriate in error situations.

Karl Olsen

Karl

Thanks very much for the information and tip: that's an impressive improvement in the performance.

Andrew

Hello,

do you know where I can find machine codes by math function, exactl big integers ?

Thanks Michal snipped-for-privacy@seznam.cz

There are many. Google for "bignum library".

GMP is one of the most comprehensive and fastest.

That site no longer hosts anything as far as I can see. (Or are you just trolling for links to it?)

It used to be rickmans site if I am not mistaken, it was a good resource in the past, when gcc ARM builds were not so widespread.

There is GCC ARM Embedded:

...Which is my current favorite. It is maintained by ARM themselves and has no artificial limitations.

This is good too but last time I looked had restricted libraries unless you buy the for-pay version.

Haha I did not see the date on that!

Oh well...

I lost the gnuarm.com domain name and it costs a bunch of money now to reclaim it. The files were very stale though. I only put up the site and someone else managed the tools. He eventually decided winarm is better and went that route.

Is there anything to prevent someone who has paid for this to release it publicly? Doesn't the license allow that? I think what you are really paying for is the support, no?

I don't think you can release the binaries openly, but you can certainly release the source code (which CodeSourcery, now owned by Mentor, provide). To be useful, you would need to remove the license check code that CS adds to their paid-for versions (to check the validity of your license) - this check code is clearly written and under the GPL, and included with the sources (and obviously also with the binaries).

There will be additional restrictions on some of the target libraries, some of which is CS's own code and under their licensing (for unrestricted use on the target, but with restrictions on usage for development). You also don't get the source code to all of these libraries except with the most expensive options.

So you pay for support (by the folks that actually maintain the ARM port, and do a large amount of the gcc and gcc-arm development), additional libraries, debugging "sprites" (code interfacing the hardware to gdb and Eclipse), and the pre-packaging.

In addition, you pay for the knowledge that the binaries you are getting are well-testing, and have been run through third-party test suites like Plum Hall (but I believe you must pay a fair amount extra if want the results and certificates of such tests).

But you are certainly free to release the source of the toolchain itself, along with some of the libraries. There's not much point, however, since CodeSourcery makes a "lite" version for free containing exactly the same stuff plus pre-compiled binaries.

(Disclaimer - it's been a while since I looked at CodeSourcery's site or read their information, so it's possible that some of this is out of date.)

I was under the impression the free "lite" version was a release older than the paid for stuff.

I don't think so - but it may not be updated quite as often. But as I say, I haven't looked for a while.