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.
A high-end x86 processor may spend a million transistors just for analyzing relationsships between instructions, and then reordering them and then splitting off the instructions into multiple ALU, FP, etc.
Some day, we may get similar behaviour in larger embedded processors too, but even when it can be done it would be impossible to keep track of tight timing so we would most probably still have "dumb" sequential processors for the hard real-time controller tasks, and use a superscalar, multi-core processor as a "back-end" computation engine responsible for crunching and non-critical tasks.
How do you prove something correct, when you have an infinite number of combinations that your source code can be converted into instructions, and these instructions can be sliced and diced between concurrently working execution units? A tiny little asynchronous interrupt (not to mention an exception) will completely rearrange the execution sequence.
Most probably, we will get better languages for describing concurrent and sequential operations, where the language will help with critical sections and concurrency. Even our embedded platforms have come a long way from the hardware platforms originally in existence when C was invented.
A Linux kernel documentation:
www.kernel.org/.../volatile-considered-harmful.txt
Why the "volatile" type class should not be used
Just for your reference. (I read the above kernel documentation, but I think I don't really understand it.)