Self-modifying code: Difference between revisions

Revision as of 10:37, 5 September 2023

Revision as of 10:39, 5 September 2023

Line 107:

* Evolutionary computing systems such as [[neuroevolution]], [[genetic programming]] and other [[evolutionary algorithm]]s.

* Hiding of code to prevent [[reverse engineering]] (by use of a [[disassembler]] or [[debugger]]) or to evade detection by virus/spyware scanning software and the like.

* Filling 100% of memory (in some architectures) with a rolling pattern of repeating [[opcode]]s, to erase all programs and data, or to [[burn-in]] hardware or perform [[RAMMemory test|RAM tests]]s.<ref name="Wilkinson_1996"/>

* [[Executable compression|Compressing]] code to be decompressed and executed at runtime, e.g., when memory or disk space is limited.<ref name="Caldera_1997_DOSSRC"/><ref name="Paul_1997_OD-A3"/>

* Some very limited [[instruction set architecture|instruction sets]]s leave no option but to use self-modifying code to perform certain functions. For example, a [[one -instruction set computer]] (OISC) machine that uses only the subtract-and-branch-if-negative "instruction" cannot do an indirect copy (something like the equivalent of "*a = **b" in the [[C (programming language)|C language]]) without using self-modifying code.

* [[Booting]]. Early [[microcomputer]]s often used self-modifying code in their bootloaders. Since the bootloader was keyed in via the front panel at every power-on, it did not matter if the [[bootloader]] modified itself. However, even today many bootstrap loaders are [[self-relocating]], and a few are even self-modifying.<ref group="nb" name="NB_DR-DOS_707"/>

* Altering instructions for fault-tolerance.<ref name="Ortiz_2015"/>