Dear all:
In "ARM® Architecture Reference Manual ARMv8", B2.6.5 Concurrent modification and execution of instructions ,
it says some instructions, such as " B, BL, NOP, BRK, SVC, HVC, and SMC " dont need to be explicitly synchronized to instruction cache, while all other instruction need.
I can understand the latter, but no the case of "B, BL, NOP, BRK, SVC, HVC, and SMC ", can some body explain why?
Shen
Modern CPUs use many forms of caching, inline transformation and prediction in order to enable high speed execution. In order to execute newly written data as instructions, it is necessary to clean the data to the point-of-unification, and to invalidate the respective instruction caching entries.
Before the data is written, we have a guarantee that the old instructions will be executed. After the data is written and the cache maintenance is performed, we have a guarantee that the new instructions will be executed. The section you highlight deals with what guarantees exist if execution is attempted from the location after the write takes place but before the maintenance is performed, i.e. what happens when there is concurrent modification and execution.
Under concurrent modification and execution (CMODX) it is possible that various internal structures might disagree about what type of instruction resides at a particular location, as such, the general rule is that the locations must be treated as containing unknown instructions until the maintenance is complete. For the given list of instructions, the architecture requires that the CPU always executes either the old or the new instruction (never a strange mix of the two), and as such they can be used for safely modifying code that is being concurrently executed (e.g. by another CPU), this set, as you list, contains common instructions used for patching code, e.g. branches, breakpoints, supervisor calls etc. As an example use case, a JIT might write a new procedure to memory where it knows no CPU can be executing from, perform the appropriate maintenance on this, and then subsequently patch it in by inserting an appropriate CMODX safe branch which itself might lie in the current path of execution of another CPU; at this point is not know whether any other CPU can see this branch, but it is guaranteed to either see it or not in its entirety; maintenance is then performed on the branch to guarantee that it is visible.
hth
Simon.
Dear Simon:
Thank you for your answer.
But it seems you are answering "why we need it be like this", instead of "how can we make it happen".
So is there any special character of these instructions, such as their encoding, that make the other core either see it or not in its entirety?
These instructions, just like all others, are of the same 32-bit size, if they can be seen entirely, why can not other instrcutions?