Self-modifying code
The method is frequently used for conditionally invoking test/debugging code without requiring additional computational overhead for every input/output cycle.Suppose a DOS script (or "batch") file MENU.BAT contains the following:[4][nb 1] Upon initiation of MENU.BAT from the command line, SHOWMENU presents an on-screen menu, with possible help information, example usages and so forth.[6] In the early days of computers, self-modifying code was often used to reduce use of limited memory, or improve performance, or both.[9] Self-modifying code can be used for various purposes: Pseudocode example: Self-modifying code, in this case, would simply be a matter of rewriting the loop like this: Note that two-state replacement of the opcode can be easily written as 'xor var at address with the value "opcodeOf(Inc) xor opcodeOf(dec)"'.Self-modifying code was used to hide copy protection instructions in 1980s disk-based programs for systems such as IBM PC compatibles and Apple II.They avoid the danger of catastrophic self-rewrites by making sure that self-modifications will survive only if they are useful according to a user-given fitness, error or reward function.[14] The Linux kernel notably makes wide use of self-modifying code; it does so to be able to distribute a single binary image for each major architecture (e.g. IA-32, x86-64, 32-bit ARM, ARM64...) while adapting the kernel code in memory during boot depending on the specific CPU model detected, e.g. to be able to take advantage of new CPU instructions or to work around hardware bugs.[15][16] To a lesser extent, the DR-DOS kernel also optimizes speed-critical sections of itself at loadtime depending on the underlying processor generation.Generating code for specific tasks allows the Synthesis kernel to (as a JIT interpreter might) apply a number of optimizations such as constant folding or common subexpression elimination.Paul Haeberli and Bruce Karsh have objected to the "marginalization" of self-modifying code, and optimization in general, in favor of reduced development costs.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.PC processors must handle self-modifying code correctly for backwards compatibility reasons but they are far from efficient at doing so.[citation needed] Because of the security implications of self-modifying code, all of the major operating systems are careful to remove such vulnerabilities as they become known.One mechanism for preventing malicious code modification is an operating system feature called W^X (for "write xor execute").[citation needed] Other systems provide a 'back door' of sorts, allowing multiple mappings of a page of memory to have different permissions.