Self-modifying code: Difference between revisions

Revision as of 00:04, 25 January 2004

Revision as of 23:46, 27 January 2004

Line 48:

In some cases self-modifying code executes slower 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.

The cache invalidation issue on modern processors usually means that self-modifying code would still be faster only when the modification will occur rarely., Suchsuch as in the case of a state switching ininside an inner loop.

This conciderationconsideration is not unique to processors with code cache, since on any processor rewriting the code never does comecomes for free.

Self-modifying code was used in the early days of computers in order to save memory space, which was limited. It was also used to implement [[subroutine]] calls and returns when the instruction set only provided simple branching or skipping instructions to vary the flow of control (this is still relevant in certain ultra-[[RISC]] architectures, at least theoretically, e.g. one such system has a sole branching instruction with three operands: subtract-and-branch-if-negative).