Advertisement

coto

image

Biography has not been added

coto

's contributions
Articles
Comments
    • Hello. I have coded a lot for Nintendo DS things. Coming from the GCC world, volatile guarantees (in the given scope) such memory access will be treated as IO register (IO registers require data read/writes to be serialized, thus, ordered and unadultered. This guarantees the compiler does not get in the way and optimizes away the access to a given variable/memory address. volatile variable just tells the memory address the variable belongs to (according to the linker), it won't be optimized. That's all. And yeah, there is hardware registers in embedded platforms which expect r/2 accesses to be always 1:1, such as the hardware IPC registers (Inter Processor Communication), and if you normally access IPC and the compiler optimizes your code it may do tricky things like: (-O2 or similar in GCC) optimized code: #define IPC_REGION (0x04000000) //note the lacking typedef access type in here, the compiler will do with it whatever it pleases to ldr r0,=IPC_region ldr r1,_someStruct ldr r2,[_someStruct,#0x40] ldr r3,[_someStruct,#0x32] ldr r4,[_someStruct,#0x20] strb r2,[r0,#0x0] //unaligned writes to a word-only enabled register strh r3,[r0,#0x2] str r4,[r0,#0x4] (-O2 or similar in GCC, but stating volatile unsigned 32bit) optimized code: #define IPC_REGION ((volatile u32)0x04000000) ldr r0,=IPC_region ldr r1,_someStruct ldr r2,[_someStruct,#0x40] ldr r3,[_someStruct,#0x32] ldr r4,[_someStruct,#0x20] str r2,[r0,#0x0] //enforce writes to a u32-only enabled register str r3,[r0,#0x4] str r4,[r0,#0x8] So basically I tread volatile, as an enforcement rule that tells the GCC compiler to NOT optimize the code at all at a given memory address (or variable it points to), and all code that will go through that one will have to carefully follow the enforcement rule.