Editing Self-modifying code (section)

==Interaction of cache and self-modifying code==
On architectures without coupled data and instruction cache (for example, some [[SPARC]], ARM, and [[MIPS architecture|MIPS]] cores) the cache synchronization must be explicitly performed by the modifying code (flush data cache and invalidate instruction cache for the modified memory area).

In some cases short sections of self-modifying code execute more slowly on modern processors. This is because a modern processor will usually try to keep blocks of code in its cache memory. Each time the program rewrites a part of itself, the rewritten part must be loaded into the cache again, which results in a slight delay, if the modified [[codelet]] shares the same cache line with the modifying code, as is the case when the modified memory address is located within a few bytes to the one of the modifying code.

The cache invalidation issue on modern processors usually means that self-modifying code would still be faster only when the modification will occur rarely, such as in the case of a state switching inside an inner loop.{{Citation needed|date=March 2008}}

Most modern processors load the machine code before they execute it, which means that if an instruction that is too near the [[instruction pointer]] is modified, the processor will not notice, but instead execute the code as it was ''before'' it was modified. See [[prefetch input queue]] (PIQ). PC processors must handle self-modifying code correctly for backwards compatibility reasons but they are far from efficient at doing so.{{Citation needed|date=March 2008}}