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:

1.1 Arm Compiler 6 Toolchain. The Arm Compiler 6.15 toolchain includes the following: armclang: Compiler and integrated assembler based on LLVM and Clang technology. Armasm: Legacy assembler for armasm-syntax assembly code. Use the armclang integrated assembler for all new assembly files. Make ARCH=arm CROSSCOMPILE=arm-linux-gnueabihf-Replace arm-linux-gnueabihf- with arm-linux-gnueabi- if your are not using a hardfloat toolchain. Another option is to install the Sourcery toolchain from Code Sourcery (now in Mentor Graphics).

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:

Documentation – Arm Developer. Arm Toolchain STM32: Install CodeSourcery ARM G Lite toolchain. During the installation, set the PATH variable for all users when prompted. CodeSourcery - Optimized free Linux GCC toolchain for ARM; paid/supported versions are also available. (The same folk who currently shepherd the GCC release cycle.) ELDK - the Embedded Linux Development Kit from DENX Software Engineering (the people behind U-Boot). See ELDK for DaVinci quick start guide as well.

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:

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.

resulting executable size	number of source files	BET -j1	BET -j2	linaro -j1	linaro -j2	cs -j1	cs -j2
p1	12kB	29	12s	8s	48s	27,5s	12s	8s
p2	17kB	23	19s	12s	51,5s	30,5s	19,5s	12s
p3

Codesourcery Arm Toolchain