Disadvantages
Self-modifying code is harder to read and maintain because the instructions in the source program listing are not necessarily the instructions that will be executed. Self-modification that consists of substitution of function pointers might not be as cryptic, if it is clear that the names of functions to be called are placeholders for functions to be identified later.
Self-modifying code can be rewritten as code that tests a flag and branches to alternative sequences based on the outcome of the test. Self-modifying code avoids making such a test on every occasion, and typically runs faster.
On modern processors with an instruction pipeline, code that modifies itself frequently may run more slowly, if it modifies instructions that the processor has already read from memory into the pipeline. On some such processors, the only way to ensure that the modified instructions are executed correctly is to flush the pipeline and reread many instructions.
Self-modifying code cannot be used at all in some environments, such as the following:
- Application software running under an operating system with strict W^X security cannot execute instructions in pages it is allowed to write to—only the operating system is allowed to both write instructions to memory and later execute those instructions.
- Many Harvard architecture microcontrollers cannot execute instructions in read-write memory, but only instructions in memory that it cannot write to—ROM or non-self-programmable flash memory.
Read more about this topic: Self-modifying Code