To illustrate my problem, I just implemented demonstration code:
#include <stdint.h> uint64_t read(const uint32_t *wordStream) { uint32_t low = *wordStream++; uint64_t high = *wordStream++; high <<= 32; return high | low; }
This code reads (according to C) two unsigned 32 bit words. It assumes a little endian notation. Then it assembles these two words into a 64 bit value and returns it.
Unfortunately, the compiler assumes, that the first word is 64 bit aligned (by using the LDRD instruction which is only allowed on aligned 64 bit values):
; generated by Component: ARM Compiler 5.06 update 1 (build 61) Tool: armcc [4d35ad] ; commandline armcc [--thumb -c --asm -otestCode.o --cpu=SC300 testCode.c] THUMB REQUIRE8 PRESERVE8 AREA ||.text||, CODE, READONLY, ALIGN=1 read PROC LDRD r2,r1,[r0,#0] MOV r0,r2 BX lr ENDP ...
Where did I tell the compiler that the first word is aligned?
You may be right about the should part. It is not a compiler error. I didn't find any hint in the ARM or TRM about the necessity of 64 bit alignment for LDRD access. Unfortunately, there are processors in this family raising a security alert in this case.
I actually saw it (using an address ending on binary 100). Also, the derivates user manual didn't show any alignment requirement.
"In this case the compiler will generate code that will not fault." simply is wrong on my derivate. I'm sure that the code runs fine on almost all other derivates.
Still, I would like to have a solution for that derivate. If ARM/Keil doesn't want to provide it because most users don't need it, that's ok. There are software workarounds. But those are inconvenient.
A personal remark: You may have noticed that I used code different from the code usually posted along with problems of this kind. In contrast to those other postings, my code is formally correct. (No illicit casts.) Therefore I found your captialisation of "DOES" unnecessary and insulting.
Thanks for taking the time to think about my problem anyway.
Werner