Why isb instruction required in below code

Kernel
1

Hi,
This question is related to portCPU_IRQ_DISABLE and portCPU_IRQ_ENABLE
macro in below file

Do we really require “isb” instruction

Use of “DSB” is understood as we want cpu to complete CPSID i first and then process any further instruction.
but not getting why pipeline need flushed ?

Any input will be of great help .

Regards
igen

2

Did you find something?

3

hi pompa,
We didn’t found anything.
It is just that we want to improve our code performance. In our code sequence we are using above macros ,so while reviewing the code this doubt came that is it really required to flush the pipeline .If yes then why we need it ?

We are looking answer as to why we need isb ?

4

Hi @negis I’m looking into this, will provide an update soon. Thanks

5

Hi @negis, Memory barriers are not needed after CPS instruction. As described in ARM Architecture Reference Manual ARMv7-A and ARMv7-R edition, section Program Status Registers (PSRs):

Writes to the CPSR have side-effects on various aspects of processor operation. All of these side-effects, except for those on memory accesses associated with fetching instructions, are synchronous to the CPSR write. This means they are guaranteed:

* not to be visible to earlier instructions in the execution stream

* to be visible to later instructions in the execution stream.

A DSB instruction is needed when a memory mapped register has been updated.

I’ll create a PR soon to remove the memory barriers. Would it be possible for you validate the changes on your target?

Thanks

6

I’m not convinced… have you checked with the barrier app note Application Note 321 ARM Cortex-M Programming Guide to Memory Barrier Instructions ? In chapter 3.3 there is something at least about cpsie that suggests something else - admittedly, I don’t have the time to look into it in detail, but I believe I have seen those barrier usage in many many code bases. Of course they may have all copied from one another, however I would be very hesitant to remove code if that potentially entails very hard to track and rare failure conditions unless I am 100% sure it is safe - in particular if we talk about a single machine instruction here that costs 4 cycles at worst. Just my 0.02.

1 Like
7

@RAc Thanks for the detailed explanation. Application Note 321 is for Cortex-M processors and it is architecture requirement to have a context synchronisation event (isb) after cpsie where as cpsid self synchronising.

On Cortex-M, there are two special registers are available PRIMASK and FAULTMASK which are updated by the CPS based on the argument. However, on Cortex-R, mask bits I, F are part of the CPSR register which is updated by the CPS based on the argument. As described in ARM Architecture Reference Manual ARMv7-A and ARMv7-R edition, section Program Status Registers (PSRs):, having memory barriers after CPS is not a architecture requirement for Cortex-R.

From the above document,

An ISB instruction flushes the pipeline in the processor, so that all instructions that come after the ISB instruction in
program order are fetched from cache or memory only after the ISB instruction has completed

The cost of using ISB is not only the number of cycles it needs, but also the potential impact on performance due to pipeline flush.

1 Like
8

Thanks for bringing your expertise here. I’m not sure if the above is in reference to the newly updated memory protection port or the original Cortex-R port. There was some confusion over when and where barrier and cache operations were needed at the time of writing the original port - even in conversation with the vendors - so I recall in at least one place we defaulted to some additional instructions that may not have been necessary. As I recall that was at the start of the context switch code though…anyway.

9

First of all thanks to all of you .
Devraj explanation is inline to what we are thinking ,but removing such a low level code may produce some unseen issue in future, when as told by Richard that things were not architecturally clear while writing the port
We have decided to go ahead with what is existing and try to do some other workaround.
As you guys are subject-matter expert ,you can have the final call.