Hello Community,
Recently I was going through some code and has this doubt.
My Pseudocode
============
CPSID I - Disable interrupts
Do critical work
CPSIE I - Enable interrupts
Do non critical work.
After I enabled interrupts and if there is pending interrupt , Does the exception handler will execute right after CPSIE I instruction ? What happens to the instructions that are already there in pipeline ? I am looking for CM0/CM0+ behavior.
Regards.
Vijay.
Robert McNamara - Thanks for the valuable information. While i was going through Memory barriers programming guide for Cortex - M (https://static.docs.arm.com/dai0321/a/DAI0321A_programming_guide_memory_barriers_for_m_profile.pdf) I found something surprising. In section 4.7, it is mentioned that
"If an interrupt was already in the pending state, the processor accepts the interrupt after the “CPSIE I” is executed. However, additional instructions can be executed before the processor enters the exception handler: • for Cortex-M3 or Cortex-M4, the processor can execute up to TWO additional instructions before entering the interrupt service routine • for Cortex-M0, the processor can execute up to ONE additional instruction before entering the interrupt service routine."
So, I was wondering in which case processor can execute ONE additional instruction. Do you have any info related to this ?
Regards,
What is the relevance if the cpu executes no,one or two instructions?
Although it may not be appropriate (in general) to expose super-low-level details of the pipelining to the programmer, in this particular case, your question can be posed to Arm too, as they have decided to spread the indirect signs of that relevance across a few pages and some diagrams, expounding the method of fixing the exact point of recognition. But even that act must have been motivated by the requirements of the application developers, in which case the question is suggestive (perhaps rightfully so; coming from an RTOS developer himself/herself) of a practice, of relying on such a behaviour, that should be avoided.
The document says:
To prevent a program error, application code that relies on immediate recognition of the interrupt must have the memory barrier instructions added.
What types of apps cannot do without such immediate recognition? Perhaps RTOS? Or drivers of some sensitive devices? Or tightly-packed, highly-efficient code sequences with CPSIE/D that overlap with interrupt processing, and such an overlap must be avoided?
This behaviour brings to mind MIPS' branch delay slot.
--
My guess: the decision to execute an additional instruction, before branching to the ISR, depends on the exact point in time when the cpu sees the interrupt (denoted as "CPU pipeline accept the request" in the diagrams) relative to the stage in which the CPSIE instruction is at that point. If it is 'late', then the pipeline must have already partially processed the subsequent instruction, and there is no harm in delaying the recognition of this asynchronous interrupt until after that additional instruction is retired.
a.surati - Thanks for sharing your knowledge. Your guess seems to be acceptable answer to the question.
a.surati said:Perhaps RTOS? Or drivers of some sensitive devices? Or tightly-packed, highly-efficient code sequences with CPSIE/D that overlap with interrupt processing, and such an overlap must be avoided?
A design which relies heavily on such low-level behavior is prone to fail sooner or later.
For test reason this information is ok, but I would not trust any product being designed like this.
The demo scene does such (tag: Atari ST, border opening), but no RTOS.
The only real use case I see is the "enable; isb; disable" snippet, to allow interrupts at well defined points.