we made some simple tests with STM32F100 Value Line Eval Board:
//------------------------------------------------------------------------------ // Variables static unsigned char sDstBuf[1024]; // 1KiB static unsigned char sSrcBuf[sizeof(sDstBuf)];
printf("Copying words from misaligned src to aligned dst buffer... "); memset(sDstBuf, 0xcd, sizeof(sDstBuf));
with optimize Level 3, optimize for time this takes 120usec
with optimize Level 0 155usec
almost the same if memcpy is used: memcpy(sDstBuf, (const void *)0xcd, sizeof(sDstBuf));
It runs into hard fault, if optimize Level >=1 and optimise for time is not set.
I think this is a compiler error..
We ran into this before with MDK 4.60, now we use 4.70A
Werner
Just got answer from Keil:
This isn't actually a compiler fault, as unless the integer pointer is declared as packed, it must be suitably aligned. It just happens to be fortuitous that at -O0 it generates safe code.
I was not aware of this. I also can't remember seeing the key word packed in any of the Cortex M3 Software Examples from ST / TI (Luminary) or NXP..
thank you all again also for exhorting to dig deeper into the machine / assembly fundamentals. With 8051 uControllers which I did before this was relatively easy. With the nicely available librarys and examples for Luminary, which was my starting point some years ago, it was tempting to just make programs and develop applications and products which fortunately worked so far without much trouble.
The 8051 is an 8-bit processor. With a processor that only does 8-bit memory accesses, a 16-bit read is two 8-bit accesses anyway.
The x86 is one of the few architectures that does handle unaligned accesses silently because the memory controller can hide it. So all the way back the MS-DOS programs could do whatever they wanted. As soon as they got their hands on a Sun workstation, they started to look surprised and ask "What is a bus error" when their "correct" code suddenly didn't function.
You normally don't see examples with packed pointers or structures for the simple reason that the big majority of all code written makes sure that no data is ever unaligned. And since the way to describe packed data differs between compilers, portable code that needs to access large data at odd addresses often contain "manual" code to perform multiple reads and merge the data into the full size - the compilers are normally intelligent enough to spot this kind of code and make use of whatever special instructions the processor may have for handling unaligned code.
With ARM, it will depend on specific chip (and potentially specific memory region) if the hardware will manage unaligned accesses or not. Same with support for exceptions if trying to access non-existing memory. The core interacts with the memory controller(s) and different chips may integrate different memory controller features.
But having the hardware (or the compiler) silently hide the issue with unaligned data will just make developers write sometimes very inefficient programs without knowing about it. Better to have the majority of the code run at max speed, and only have special "big data" packed, since it is so large amounts of data that packing it represents huge space savings - while still normally have few parts of the code accessing it and often quite seldom too.
IBM decided in their OS to trap unaligned data and silently have the exception handler solve the issue and then return - resulted in programs now and then run _extremely_ (like 100+ times) slower than normal. Was a bug in the program loader that sometimes loaded a program to an odd address - so suddenly almost all memory accesses were unaligned, despite the compiler having done the best to make sure it should be aligned. After that OOPS, IBM realized that hiding the issue isn't really practical - better have programs fail and the developer to fix source code specifically for unaligned accesses. Then the developer will know exactly where extra costs are introduced.