Compile SDK11 with ARM Compiler Version 6

[Christopher]

I would like to use the latest ARM Compiler Version 6 (armclang) because I need some features of the C++11 language.

Is it possible to use the latest ARM Compiler Version 6 to compile the SDK 11 ? Which flags should we use to be compatible with all macros currently available for GCC and armcc ?

In future SDK releases, will this compiler be officially supported ?

[RK]

that would be very welcome. I have actually done this work some time ago, it was just too manual to keep up but I'm happy to share anything I still have if you want it. It's going to be a one-time pain thing to come up with a version of SVCALL which works, all my other testing with clang showed up no other issues than that although any use of __asm() probably needs auditing because inline assembler is treated quite differently from gcc, any other assembler in .s files, will be fine.

Segger Embedded Studio also has a clang option, so that's another product people are going to see a clang option and try it out.

clang is a nice compiler, it can do some very clever optimisations although it's better at making fast code than small code in my limited experience. These days with the wonderful amount of flash we get to play with it's less of an issue.

[Christopher]

@Nordic Any plan to officially support the ARM Compiler Version 6 for the next SDK releases ?

[Håkon Alseth]

I cannot comment if we're officially going to support the llvm toolchain in the future (AFAIK: It has not been discussed with management at this moment), but I am quite sure if we're going to support it in the future; it is not going to be for the next SDK release.

I can however comment on the status as-of nRF5 SDK v11:

One of the huge problems with our SDK + llvm/armclang is that the SVC handling is unreliable. This could be a problem on our side, or it can be a problem with the clang compiler. We're not sure at this moment.

For Nordic to support a new toolchain, we have to make sure that all the functionality that we provide, and use in our SDK, works with this new toolchain without compromises. At this moment; it does not do that.

Cheers, Håkon

[Christopher]

@hkn Thanks for your reply. I understand the reasons why this will take some time and effort.

For now GCC is the only alternative which supports some of the latest C++ features I like to work with when I develop embedded BLE applications, let's hope other compilers will support them too ;)

[RK]

It's a bit of both. the gcc optimiser doesn't require the definitions of naked ASM functions to say they do actually use the values of all parameters, it always sets the stack up and it always takes the return value and doesn't try to optimise. That's arguably wrong because you can specify which arguments are really used and probably should. If they changed that however, it would break so much code I can't imagine they ever will. So the ASM code for the SVC calls is kind of technically wrong, but it works with GCC and is unlikely to break.

clang works rather differently, so unless you specify exactly that all the arguments to an sd_ function are used, it can, and does, optimise away the ones which it believes aren't.

It's quite easy to write an sd_ function which works perfectly well in clang, under all cases of optimisation. However what's NOT easy, is writing ..