why some instructions are not required to be  explicitly synchronized ?

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.

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.