I am looking for opinions on how to create a code sequence that is written in "C" that must be performed as an uninterruptable sequence. I want to disable interrupts (globally) execute a code sequence and then re-enable interrupts. I am looking for your inputs as I don't see how to guarantee this from what I know about the "C" standard. I think the compiler is allowed to optimize the sequence so that the actual linear code could be placed outside my expected enable interrupt and disable interrupt sequence (start/end points). The compiler knows that the enable/disable of the interrupt is volatile and must be performed but it doesn't know that there is an architectural dependency to the code order I want. In other words it could be that part of my sequence gets optimized outside of where the interrupt is not globally disabled. As the opcode creation behavior is still correct but it is not from a system behavior point of view.
Outside of writing it in assembly has anyone experienced this and how did you end up handling it. Thanks in advance for your inputs.
"Alas the code sequence did look exactly like this."
I would be very interested to see the source code and the compiler's result.
Me too.
This is waaaaaaaay outside the scope of the 'C' Standard - therefore you are going to have to rely upon implementation-specific features.
Not necessarily. The standard mentions the so called sequence points. It is my understanding that those mandate a certain order of execution in a compiled program. The general problem does exist, however. Interrupts and multiple CPU's do need more support in the language standard. I expect a new version of the standard in the future to include this.
The compiler wasn't Keil, but I was looking for opinions. Perhaps Keil considers the enabling/disabling interrupts as a sequence point.
The disable and enable functions were inlined automatically to be:
BCLR IEN ; global interrupt disable BSET IEN ; global interrupt enable
The effect of using high optimization enabled the calls to be inlined thus eliminating the sequence points. Thus enabling/disabling interrupts in effect became simple reading/writing of memory locations from the compiler point of view with no dependency on the other variables (other than it was a volatile access). Enabling or disabling interrupts is not a FILE operation so no sequence point occurrence. The optimizer constraint was to make sure it was updated before hitting a sequence point. Unfortunately this resulted in undesirable behavior on my part. A volatile far pointer was being updated. But only part of the update was protected from interrupts and as luck would have it an interrupt occurred that used this pointer. A semaphore (mutex) was added in regards to this pointer to solve the issue (albeit we should have used one from the beginning).
Sorry, in my case I may have killed your Granny
The effect of using high optimization enabled the calls to be inlined thus eliminating the sequence points.
That would be a compiler bug, if I am not mistaken. It's not much consolation, though...
The compiler wasn't Keil, but I was looking for opinions.
Does the compiler by any chance have an optimization stage that works on the generated assembly code without regarding the C code? "Instruction reordering" or something similar?
A compiler normally has stages working on the instruction level. But these stages must know about side effects. And these stages should still have access to meta-data from the source-level processing.
But one problem with interrupts is that depending on where in the interrupt chain you perform your disable may affect if the disable is instant, or if there are one or more machine cycles after the disable instruction where you may still be hit by an interrupt.
When the processor has a machine instruction to turn off interrupts, it may have a pipeline where one or more following instructions may already have been affected by the previous interrupt enable state.
And when the disable is instead a write to an external interrupt controller, the internal busses in the processor may delay the write to the interrupt controller, allowing the processor to start new instructions.
Because of this, you really have to read the datasheets for the processor and may have to add one or more NOP instructions between the disable, and the critical code section. It is very hard to find information about the lag between disable and until you enter the safe zone. And it isn't easy to test either since it is almost impossible to trig an interrupt at the exact clock cycle that maximizes this delay in relation to the disable instruction.