I spent the last two afternoons procrastinating from other work doing a deferred maintenance project, porting the labs for UK’s CPE287 Introduction to Embedded Systems from the “V5” armcc to the “V6” armclang compiler, since the most recent releases of Keil (the IDE we use in the class) have dropped support for the older compiler, and all our materials were written against V5. It has been a somewhat interesting porting exercise for a “same vendor, same platform” situation.
We have some slightly unusual circumstances: First, because the class starts in writing pure assembly, proceeds through manual bit manipulation in C, and eventually starts to write high-level software driver model code, we hit all the styles and interfaces. Secondly, we have an inexpensive textbook and supporting materials we rather like, but all the examples use the old style assembly syntax, which differs significantly from the more modern GCC/LLVM style, and for pedagogical consistency reasons we’d like to write our code in that style.
ARM/Keil have produced a document AN298 – Migrate ARM Compiler 5 to ARM Compiler 6 which covers most of the important details, but it was still a bit of a skilled process.
- For the time being, Keil with the V6 toolchain includes the older
armasmbinary, so separate pure-assembly .s sources written in the old syntax can still be ingested, you only have to port inline assembly.
- Keil’s debugger doesn’t appear to be able to keep source lines of inline assembly and the disassembly view synchronized for GCC-style inlined assembly the way it could with
armcc. Unfortunate, and a bit klutzy for setting breakpoints, but not a deal-breaker.
__ARMCC_VERSIONas 6something so various pieces of existing code have pre-processor directives that will decide to use the
armccstyle inline assembly instead of the gcc style ones. Particularly irritating, TI’s first party TivaWare library has this problem in both
sysctl.c, so I had to make a hacked version with the
#ifdefs swirled around appropriately. The code in TivaWare intended for IAR
ewarmis suitable for
armclang… as long as you remove some spare ewarm-specific pragmas embedded here and there for suppressing return value warnings; I ended up putting
-Wno-return-typein the extended compiler options for projects depending on those files.
armclangis much more aggressive about optimization by default than
armccwas. In particular, you could get away without marking variables used in busy wait loops or ISRs volatile in armcc, and armclang will happily optimize them out if you forget.
armclangis more vocal about implicit type conversion than
armcc, especially where it might affect signedness. This is triggered a lot by the
REGISTER_NAME &= ~0xMASKbit-specific addressing idiom. I sprinkled in lots of
ULsuffixes on literals to avoid the issue.
Long term we might try to get off of Keil, though my experiences with CodeComposerStudio have been sufficiently frustrating that I’m in no hurry to move to it for the TI TivaC boards we’ve been using, and while I like ST’s Cube environment, it would both be a major change of materials and a potential supply-chain nightmare (when is the last time you saw a legitimate major electronics vendor with STM32 parts in a stock status other than “Expected Date: Eventually”?)