Content deleted Content added
m explain what W^X means |
try'd to unPOV abit page + example and discc of asm style selfmod'ing |
||
Line 1:
In [[computer programming]], '''self-modifying code''' is code that modifies itself. This is straightforward to write when using [[assembly language]] and is also supported by some high level language interpreters such as [[SNOBOL4]] or the [[Lisp programming language]]. It is more difficult to implement on compilers but compilers such as [[Clipper programming language|Clipper]] and [[Spitbol]] make a fair attempt at it. Batch programming [[scripting programming language|script]]s often involve self modifying code as well.
Self-modifying code often 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. Use of self-modifying code is not recomended when a viable alternative exists, because such code can be difficult to understand and maintain.▼
==Assembly style self-modifying code:==
▲
The cache invalidation issue on modern processors, usualy means, that self modifing code would still be faster, only when the modification will occure seldomly. Such as in the case of a state switching in a inner loop. Consider the following pseudo-code exaple:
repeat N times {
if STATE is 1
increase A by one
else
decrease A by one
do something with A
}
Self modifying code in this case would simply be a matter of rewriting the loop like this:
repeat N times {
l0:
increase A by one
do something with A
}
when STATE has to switch {
replace [[opcode]] at address 'l0' with [[opcode]] to decrease
}
Note that 2-state replacement of the [[opcode]], can be easly written as
'xor var at address with the value "opcodeOf(Inc) xor opcodeOf(dec)"'
Choosing this sollution will have to depend ofcourse on the value of 'N' and the frequency of state changing.
This concideration is not unique to processors with code cache, since on any processor, rewriting the code never comes for free.
Some claim that use of self-modifying code is not recomended when a viable alternative exists, because such code can be difficult to understand and maintain.
Others, simply view self-modifying code as something one would be doing while editing code (in the above example, replacing a line, or keyword), only done in run-time.
The other kind of self-modifying code, is runtime code generation, or specialisation of an algorithm in runtime or loadtime (which is popular in the ___domain of real-time graphics), or the patching of subrouting address calling, as done usually at load time of [[dynamic libraries]]. Wherther this is regarded 'self-modifying code' or not is a case or terminology.
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).
Line 32 ⟶ 70:
(*A means "the ___location to which A points")
==TODO== an example and discussion of 'high-level' self-modifying code such as in LISP.
| |||