Hi all! I am experiencing the following problem:
sizeof(EDA.stPARAM) returns 0x80 with CA.exe V2.41 which in my opinion is the correct result, but with CA.exe V2.50a it returns 0x82. Can somebody explain this behaviour to me? Code sample is included below:
file eda_st.inc:
struct {
byte ubFree_0000h[16] ;/* 000h-00Fh: */
byte ubFree_0010h[16] ;/* 010h-01Fh: */
byte ubFree_0020h[16] ;/* 020h-02Fh: */
byte ubFree_0030h[16] ;/* 030h-03Fh: */
byte ubFree_0040h[16] ;/* 040h-04Fh: */
byte ubFree_0050h[16] ;/* 050h-05Fh: */
byte ubFree_0060h[16] ;/* 060h-06Fh: */
byte ubFree_0070h[16] ;/* 070h-07Fh: */
}stPARAM;
byte VER_HWVers ;/* 000h: */
byte ubFree_0000h[127] ;/* 001h-07fh: */
}stABGLEICH;
---------------------- file eda_usr.h:
typedef struct {
#include "eda_st.inc" // struct mit Parametern
} EDA_sttyDAT;
extern EDA_sttyDAT EDA;
---------------------- file eda_usr.c:
#define TAR_RAMCOPY 0x40001000
EDA_sttyDAT EDA __at(TAR_RAMCOPY);// RAM-Kopie
Sorry to "sort of hijack" this thread, but...
On the subject of the __packed qualifier, has anyone else noticed the overhead that this appears to incur in the Keil ARM compiler ?
I haven't had time to do extensive testing, but my initial impression is that all accesses to members of __packed structures appear to be made using function calls. This may not be an issue in many cases, but might be worth experimenting with if time and/or space are critical.
Regards
David.
Yes, __packed do require a lot of extra code, since the compiler has to generate code - or call helper functions - to read the data as 8-bit entitires and then build any 16-bit, 32-bit or 64-bit variables from these individually read bytes.
That is the reason _why_ compilers normally align all data, and why linkers also knows how to add padding to maintain align.
Some processors - such as x86 - have a memory controller that supports "hiding" of non-aligned access. The memory controller can do two 32-bit reands, sift through the data and return a single 32-bit unaligned value to the processor core. The only cost being the potential pipeline stall while waiting for an extra memory access.
Most ARM processors have very stupid memory controllers. They tend to issue an exception or return bogus data for nonaligned data. The Keil compiler does not have any idea about exactly how stupid the memory controller is for a specific chip. The behaviour may even differ between different memory areas, i.e. unaligned access to special function registers for a serial port may give different behavour than unaligned access to the flash or the RAM.
In short - the compiler just have to add "safe" code. And safe code is code that reads the data one byte at a time. And such code is larger - a lot larger - than normal native memory accesses.