Anyone Working on a Port to Keil/ARM Compiler 6.4 (ARMCLANG?)

ppotts wrote on Wednesday, May 25, 2016:

Keil/ARM dropped an updated MDK that comes with a version of ARMCLANG:

C:\Keil_v5\ARM\ARMCLANG\bin>armclang --version
Product: MDK-ARM Standard Cortex-M only 5.20
Component: ARM Compiler 6.4
Tool: armclang [5c29cb00]

Target: unspecified-arm-none-unspecified

I would love to use this compiler for my project as it has support for a much more modern version of C++, a lot better static analysis, more warnings, compiles faster, does the dishes and mops the floor, etc.

However, it supports a different syntax for inline assembly, and Keil’s docs don’t describe it well.

I’m not sure I’m up to the task of porting FreeRTOS myself. I’m willing to try, but if it is going to be extremely hairy I’ll probably have to give up and use the old compiler.

My target is a SAM4E16E (Cortex-M4) chip. FreeRTOS is working great for me with the older ARMCC compiler.

Is anyone else using this new compiler? Anyone else attempting a port?

One possibility that occurred to me: could I build FreeRTOS as a static library, with the old compiler, and drop it into a project built with ARMCLANG?

Maybe not, as that won’t help with functions that are really macros.

Any suggestions welcome.


Paul R. Potts

rtel wrote on Wednesday, May 25, 2016:

We have used CLANG before, and as it tries to support GCC syntax, had
success building and running the FreeRTOS GCC port with it BUT did find
we had to make one small modification to the port layer in order for
this to work.

The issue was related to the use of the attribute((naked))
qualifier, which didn’t work quite as advertised. It is supposed to
prevent any compiler prologue or epilogue code being generated, as per
GCC’s use of the qualifier. As I recall it removed most of the compiler
generated prologue, but left in some stack manipulation code. That was
some time ago though, and I believe that issue has since been fixed.

rtel wrote on Wednesday, May 25, 2016:

Forgot to mention the static library option - assuming CLANG complies
with the ARM EABI, which I would be surprised if it didn’t, then you
should be able to mix and match compilers used to build and then
subsequently link to static libraries. Again this is something we have
done ourselves, but not with CLANG.

ppotts wrote on Wednesday, May 25, 2016:

Thanks for the suggestions. I am pressing on with it – I have some changes to my portmacro.h that seem to compile. I should be able to test it all pretty soon.

ppotts wrote on Thursday, May 26, 2016:

I have good news – my whole project is up and running using armclang!

I did have trouble building the FreeRTOS source itself, so I built that as a library with the old compiler. That required setting “Enum Containers always int” and adding the compiler flag “–wchar32” in order to make a library that would link with the armclag-built code.

I have not been able to test everything yet but the basic tasks seem to be running with their expected timing, including interrupt handling with yielding from ISRs.

So far the only thing tricky I did was to make changes in portmacro.h.

#define portFORCE_INLINE __attribute__((always_inline))

Then using the GCC syntax for assembly, for example, in ulPortRaiseBASEPRI:

__asm( "mrs %[ulReturn_], basepri; msr basepri, %[ulNewBASEPRI_]; dsb; isb" : [ulReturn_] "=r" (ulReturn) : [ulNewBASEPRI_] "r" (ulNewBASEPRI) );

I have not tried attribute ((naked)) or looked at the generated assembly to see if it can be slimmed down. Right now I’m just happy it works so far.

I will be testing more so I’ll post updates if I come across anything strange.

I would like to get the FreeRTOS sources building with clang but I will have to look into that more later; there were problems with compiler intrinsics and other port-specific things.

rtel wrote on Thursday, May 26, 2016:

I wonder if ARM’s distribution is intended to build ARM compiler syntax.
The distribution we used was the ‘vanilla’ one, which was happy with
building GCC code (barring the one err mentioned in my previous post).