GCC version: 5.4 2016q2p1 - an own build (the big endian patch included)
CPU core: ARM Cortex-R5
External device accessed via the parallel bus: FPGA
* The FPGA proper behavior is negatively influenced by the unexpected read access!
Optimization level: -O2 //another levels do behave in the same way
C snippet:
volatile struct tExtMemDev
{
unsigned short regA;
unsigned short regB;
unsigned short regC;
} __attribute__((packed)) T_EXT_MEM_DEV;
GCC version: 5.4 2016q2p1 - an own build (the big endian patch included)
CPU core: ARM Cortex-R5
External device accessed via the parallel bus: FPGA
* The FPGA proper behavior is negatively influenced by the unexpected read access!
Optimization level: -O2 //another levels do behave in the same way
C snippet:
volatile struct tExtMemDev _((packed) ) T_EXT_MEM_DEV;
{
unsigned short regA;
unsigned short regB;
unsigned short regC;
} __attribute_
T_EXT_MEM_DEV rxBuff __attribute__ ((section (.external_ device) ));
rxBuff.regA = 0xDEAD;
Generated Assembler:
* Scenario 1 - the struct WITH volatile keyword - the unexpected LOAD of the address for only write operation
* Incomplete - just the most important instructions:
02aa F06F0221 mvn r2, #33
02b0 F06F0352 mvn r3, #82
02a8 7923 ldrb r3, [r4, #4] @ zero_extendqisi2 //UNEXPECTED and UNWANTED read
02b4 7122 strb r2, [r4, #4]
02b6 7962 ldrb r2, [r4, #5] @ zero_extendqisi2 //UNEXPECTED and UNWANTED read
02b8 7163 strb r3, [r4, #5]
Scenario 2 - the struct WITHOUT volatile keyword - the proper behavior - only write operation
* The proper instructions generated - no LOAD operation.