I have some C macros that disable and enable interrupts so that I can define critical sections of code. I want to ensure that the optimizer complies with the operations and does not move them or remove them.
#define ARM_INT_KEY_TYPE unsigned int
#define ARM_INT_LOCK(key_) ({ \
asm("MRS %0,cpsr" : "=r" (key_)); \
asm("MSR cpsr_c,#(0x1F | 0x80 | 0x40)"); \
})
#define ARM_INT_UNLOCK(key_) asm("MSR cpsr_c,%0" : : "r" (key_))
The usage is as follows:
int init_i2c(p_device_i2c dev){
// Interrupts are enabled
doSomething();
ARM_INT_KEY_TYPE key;
ARM_INT_LOCK(key);
// Interrupts are disabled
pMX27_GPIO i2c_clk = (pMX27_GPIO)(GPIO_BASE_ADDR | I2C_CLK_PORT);
pMX27_GPIO i2c_sda = (pMX27_GPIO)(GPIO_BASE_ADDR | I2C_DATA_PORT);
i2c_clk->GIUS &= ~(1 << I2C_CLK_PIN); // I2C Signals
i2c_sda->GIUS &= ~(1 << I2C_DATA_PIN); // I2C Signals
ARM_INT_UNLOCK(key);
// Interrupts ON again
// Wait for stable
ARM_delay_clocks(5000);
i2c_stop(dev);
The code works as expected with optimization turned off but I suspect that there may be problems with optimization turned ON.
Will adding volatile to the asm statements do the trick?
#define ARM_INT_UNLOCK(key_) asm volatile ("MSR cpsr_c,%0" : : "r" (key_))
Use -O0 to disable them and use -S to output assembly. -O3 is the highest level of optimization. Starting with gcc 4.8 the optimization level -Og is available. It enables optimizations that do not interfere with debugging and is the recommended default for the standard edit-compile-debug cycle.
Defining Compiler Optimizations. An optimization is the process of transforming a piece of code into another functionally equivalent piece of code for the purpose of improving one or more of its characteristics. The two most important characteristics are the speed and size of the code.
In computing, an optimizing compiler is a compiler that tries to minimize or maximize some attributes of an executable computer program. Common requirements are to minimize a program's execution time, memory footprint, storage size, and power consumption (the last three being popular for portable computers).
Yes, asm volatile
is the correct way to write this macro. You can easily check the behavior by stepping through this code on debugger and watching the order of operations at the assembly level. Or, you can just visually inspect the disassembly output for your function.
Here's some useful gcc documentation on inline asm
http://www.ibiblio.org/gferg/ldp/GCC-Inline-Assembly-HOWTO.html#ss5.4
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With