As some of you probably noticed a new category appeared in Download section - Software > bleeding-edge-toolchain - with some pretty huge files names in a way that implies these are bare-metal compilers for chips with ARM cores... "On the market" we already have CodeSourcery (now known as Sourcery CodeBench), linaro, Yagarto, and - if you insist - there are also prehistoric GNUARM and WinARM packages, and probably some more which I don't know about (yet) - so why another one? You cannot even use a cool name for it, as Yet Another Gnu ARm TOolchain is already taken (;

Let's start with a bit of history. In the ancient times (which would be about 3-4 years ago [; ), when ARMs started to become really popular (with Cortex-M3 chips), the best choice for a toolchain was CodeSourcery - there were versions for Windows and Linux, package was updated regularly, developers from the company working on it were said to cooperate with ARM - full service, all you ever needed. Countless websites (including this one) recommend this toolchain as a good starting point.

But when first Cortex-M4 chips with integrated floating point unit appeared on the market a serious crack presented itself... When you enter arm-none-eabi-gcc -print-multi-lib in your shell you get something like that:

...\Sourcery_CodeBench_Lite_for_ARM_EABI\bin>arm-none-eabi-gcc -print-multi-lib
.;
thumb;@mthumb
armv6-m;@mthumb@march=armv6-m
thumb2;@mthumb@march=armv7@mfix-cortex-m3-ldrd

...\Sourcery_CodeBench_Lite_for_ARM_EABI\bin>arm-none-eabi-gcc --version
arm-none-eabi-gcc (Sourcery CodeBench Lite 2012.09-63) 4.7.2
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

To cut things short, it means that this toolchain includes standard libraries (like libm.a with math functions) only for "standard" ARM7 architecture (ARMv4, both ARM and THUMB mode), for Cortex-M0 (ARMv6-M, THUMB) and for Cortex-M3 (ARMv7-M, THUMB2). You could - of course - write code for Cortex-M4, with this toolchain, as ARMv7-ME is just an extension of ARMv7-M architecture, but you need to forget about using the FPU (Floating Point Unit) in most cases. If you're in a mood you could always use assembly language or use CMSIS functions, but basic stuff like:

float a = 1.0f;
float b = logf(a);

would use 100% software algorithms instead of FPU-goodness... Additionally in 2010 CodeSourcery was purchased by Mentor Graphics and support for free Lite version becomes almost non-existent. Suggestions about adding FPU support for ARMv7-ME architecture are dismissed with information that it (and many more) is available in the paid version...

Fortunately at the same time (2010) linaro organization is started, consisting of ARM and a few of its biggest partners, with purpose to develop and support open-source tools for new chips with ARM cores. It is pretty obvious that main target of linaro are application processors with ARM Cortex-A core and systems like Linux and Android, but at the end of 2011 first version of package named GNU Tools for ARM Embedded Processors was published. Since then updated versions appear 3-4 times a year and include the most recent version of the compiler, coming from the branch targeting embedded microcontrollers (at that time - /branches/ARM/embedded-4_6-branch, currently - /branches/ARM/embedded-4_7-branch). As opposed to CodeSourcery package, this one included wide collection of libraries:

...\GNU Tools ARM Embedded\4.7 2012q4\bin>arm-none-eabi-gcc -print-multi-lib
.;
thumb;@mthumb
fpu;@mfloat-abi=hard
armv6-m;@mthumb@march=armv6s-m
armv7-m;@mthumb@march=armv7-m
armv7e-m;@mthumb@march=armv7e-m
armv7-r/thumb;@mthumb@march=armv7-r
armv7e-m/softfp;@mthumb@march=armv7e-m@mfloat-abi=softfp@mfpu=fpv4-sp-d16
armv7e-m/fpu;@mthumb@march=armv7e-m@mfloat-abi=hard@mfpu=fpv4-sp-d16
armv7-r/thumb/softfp;@mthumb@march=armv7-r@mfloat-abi=softfp@mfpu=vfpv3-d16
armv7-r/thumb/fpu;@mthumb@march=armv7-r@mfloat-abi=hard@mfpu=vfpv3-d16

...\GNU Tools ARM Embedded\4.7 2012q4\bin>arm-none-eabi-gcc --version
arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors) 4.7.3 20121207
(release) [ARM/embedded-4_7-branch revision 194305]
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

As you see this package supports "classic" ARM7 (ARM, THUMB), Cortex-M (ARMv6-M, ARMv7-M, ARMv7-ME) and Cortex-R (ARMv7-R) - all of them with option to use hardware FPU.

Some of you probably stopped reading at this point and asked aloud "what more do you want?"... Everything would be perfect with linaro packages if not one tiny problem - for unknown reasons compilation of any project lasts 3-4 times longer than in CodeSourcery...

At the same time - with no relation to the above - I needed to do some projects in C++ and exceptions that you couldn't really disable (against the rule that "you don't pay for what you don't use") made me a bit annoyed. To completely get rid of them (because of memory size constraints in microcontrollers) you need to recompile the whole C and C++ standard library that is included in the compiler. (effects of a few compilations that I've done can be downloaded from Download > ARM > Various section - you can find there packages with just the libraries that have C++ exceptions disabled)

And lately, when working on another project, I needed to use new version of newlib library, because (with my help) it included a patch that drastically reduced stack use of fprintf() function. As the project was pretty huge, long compilation times started to really annoy me, so I decided to check whether utilization of 64-bit processor will significantly reduce the time of compilation.

Last experiment showed that use of 64-bit compiler doesn't change much when compared to 32-bit version (gain less than 10%), but the compilers "produced" by me were several times faster than original linaro, reaching CodeSourcery's "efficiency". That is how bleeding-edge-toolchain concept was born.

Main assumptions are as follows:

• based on linaro packages,
• compiled with most recent compiler, modern mingw-w64 compiler is used for Windows,
• basic components (compiler, newlib, gdb and binutils) come directly from projects' repositories, most recent revisions are used,
• remaining components (libraries required for toolchain compilation) are in the most recent stable versions (unless documentation recommends a specific version),
• disabled C++ exceptions (I'm working on availability of both versions, selected with .specs files),
• all compiler libraries include debugging symbols (they are not stripped),
• newlib library with enabled reent-small option and disabled support for 64-bit variables in printf()/sprintf() type functions.

What is the gain of using such toolchain? I've run some extremely boring test which compared compilation time of 6 different projects, comparing 3 toolchain packages in the most recent versions (bleeding-edge-toolchain-130207 [32-bit], linaro - GCC ARM Embedded 4.7-2012-q4-major, CodeSourcery - Sourcery CodeBench Lite 2012.09-63) for both sequential and for parallel (2 jobs) compilation. Results are presented in the table below.

* - compilation done with tup build system, original Makefiles of this project are not usable for parallel compilation,
** - compilation is impossible because of incompatibility of project and compiler libraries (different options related to reentrancy)
*** - fonts and bitmaps occupy about 100kB, the project has about 30kB of code

Results are an average of two compilations. Each compilation was preceded with full "cleaning" of the project (make clean). Number of source files takes into account only the files that were compiled (actually it's the number of resulting object files). Measurements were done with a script.

As a reward for these tests I allowed myself for a small commentary.

1. In theory CodeSourcery package has different version of compiler (4.7.2) than two others (4.7.3 prerelease).
2. p4 project does not fit this comparison well because of its 567 source files - most of the time is probably wasted by computer on spawning new processes of compiler, so results for all 3 packages are comparable.
3. Excluding p4 project mentioned above it can be said that compilation time when using bleeding-edge-toolchain is 2.5-4x shorter than with linaro.
4. bleeding-edge-toolchain results are almost identical to CodeSourcery's.
5. Close look at information available on linaro's website leads one to believe that the reason of long compilation may be use of really old system (Ubuntu-8.10) and tools for building it - probably for increased compatibility with older operating systems.

Because I've compiled the toolchain on 64-bit Linux system, I was unable to compile 32-bit version for Linux system, however the scripts included in each package will allow any user of such system to do the compilation on his/her own (; Maybe in future I'll be able to compile such version too - who knows, I'll keep trying (;

So if you are as annoyed by long compilation times as I am, you should download and start using bleeding-edge-toolchain (; Comments are welcome, as usual (;