What happens to the Instructions already in pipeline when interrupt occurs ?

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.

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.