Self-modifying code - Revision history

144.174.214.39: /* Application in low and high level languages */ switched creating to creation in {'''creation or modification of source code statements'''} for grammar reasons

2025-03-16T15:26:55Z

Application in low and high level languages: switched creating to creation in {'''creation or modification of source code statements'''} for grammar reasons

← Previous revision		Revision as of 15:26, 16 March 2025
Line 25:		Line 25:
	* '''overlay of existing instructions''' (or parts of instructions such as opcode, register, flags or addresses) or		* '''overlay of existing instructions''' (or parts of instructions such as opcode, register, flags or addresses) or
	* '''direct creation of whole instructions''' or sequences of instructions in memory		* '''direct creation of whole instructions''' or sequences of instructions in memory
	* '''~~creating~~ or modification of [[source code]] statements''' followed by a 'mini compile' or a dynamic interpretation (see [[eval]] statement)		* '''creation or modification of [[source code]] statements''' followed by a 'mini compile' or a dynamic interpretation (see [[eval]] statement)
	* '''creating an entire program dynamically''' and then executing it		* '''creating an entire program dynamically''' and then executing it

Kvng: WP:ADOPTYPO boolean -> Boolean

2024-11-14T00:15:04Z

WP:ADOPTYPO boolean -> Boolean

← Previous revision		Revision as of 00:15, 14 November 2024
Line 4:		Line 4:
	{{Use list-defined references\|date=December 2021}}		{{Use list-defined references\|date=December 2021}}
	{{Use American English\|date=January 2019}}		{{Use American English\|date=January 2019}}

	In [[computer science]], '''self-modifying code''' ('''SMC''' or '''SMoC''') is [[source code\|code]] that alters its own [[instruction (computer science)\|instruction]]s while it is [[execution (computing)\|executing]] – usually to reduce the [[instruction path length]] and improve [[computer performance\|performance]] or simply to reduce otherwise [[duplicate code\|repetitively similar code]], thus simplifying [[software maintenance\|maintenance]]. The term is usually only applied to code where the self-modification is intentional, not in situations where code accidentally modifies itself due to an error such as a [[buffer overflow]].		In [[computer science]], '''self-modifying code''' ('''SMC''' or '''SMoC''') is [[source code\|code]] that alters its own [[instruction (computer science)\|instruction]]s while it is [[execution (computing)\|executing]] – usually to reduce the [[instruction path length]] and improve [[computer performance\|performance]] or simply to reduce otherwise [[duplicate code\|repetitively similar code]], thus simplifying [[software maintenance\|maintenance]]. The term is usually only applied to code where the self-modification is intentional, not in situations where code accidentally modifies itself due to an error such as a [[buffer overflow]].

Line 139:		Line 140:

	===Specialization===		===Specialization===
	Suppose a set of statistics such as average, extrema, location of extrema, standard deviation, etc. are to be calculated for some large data set. In a general situation, there may be an option of associating weights with the data, so each x<sub>i</sub> is associated with a w<sub>i</sub> and rather than test for the presence of weights at every index value, there could be two versions of the calculation, one for use with weights and one not, with one test at the start. Now consider a further option, that each value may have associated with it a ~~boolean~~ to signify whether that value is to be skipped or not. This could be handled by producing four batches of code, one for each permutation and code bloat results. Alternatively, the weight and the skip arrays could be merged into a temporary array (with zero weights for values to be skipped), at the cost of processing and still there is bloat. However, with code modification, to the template for calculating the statistics could be added as appropriate the code for skipping unwanted values, and for applying weights. There would be no repeated testing of the options and the data array would be accessed once, as also would the weight and skip arrays, if involved.		Suppose a set of statistics such as average, extrema, location of extrema, standard deviation, etc. are to be calculated for some large data set. In a general situation, there may be an option of associating weights with the data, so each x<sub>i</sub> is associated with a w<sub>i</sub> and rather than test for the presence of weights at every index value, there could be two versions of the calculation, one for use with weights and one not, with one test at the start. Now consider a further option, that each value may have associated with it a Boolean to signify whether that value is to be skipped or not. This could be handled by producing four batches of code, one for each permutation and code bloat results. Alternatively, the weight and the skip arrays could be merged into a temporary array (with zero weights for values to be skipped), at the cost of processing and still there is bloat. However, with code modification, to the template for calculating the statistics could be added as appropriate the code for skipping unwanted values, and for applying weights. There would be no repeated testing of the options and the data array would be accessed once, as also would the weight and skip arrays, if involved.

	===Use as camouflage===		===Use as camouflage===

Dgpop: /* Use as camouflage */ minor copyediting

2024-07-09T17:15:22Z

Use as camouflage: minor copyediting

← Previous revision		Revision as of 17:15, 9 July 2024
Line 142:		Line 142:

	===Use as camouflage===		===Use as camouflage===
	Self-modifying code is more complex to analyze than standard code and can therefore be used as a protection against [[reverse engineering]] and [[software cracking]]. Self-modifying code was used to hide copy protection instructions in 1980s disk-based programs for ~~platforms~~ such as [[IBM ~~Personal~~ ~~Computer\|IBM PC~~]] and [[~~Apple II series\|~~Apple II]]. For example, on an IBM PC ~~(or [[IBM PC compatible\|compatible]])~~, the [[floppy disk]] drive access instruction <code>[[int 0x13]]</code> would not appear in the executable program's image but it would be written into the executable's memory image after the program started executing.		Self-modifying code is more complex to analyze than standard code and can therefore be used as a protection against [[reverse engineering]] and [[software cracking]]. Self-modifying code was used to hide copy protection instructions in 1980s disk-based programs for systems such as [[IBM PC compatible]]s and [[Apple II]]. For example, on an IBM PC, the [[floppy disk]] drive access instruction <code>[[int 0x13]]</code> would not appear in the executable program's image but it would be written into the executable's memory image after the program started executing.

	Self-modifying code is also sometimes used by programs that do not want to reveal their presence, such as [[computer virus]]es and some [[shellcode]]s. Viruses and shellcodes that use self-modifying code mostly do this in combination with [[polymorphic code]]. Modifying a piece of running code is also used in certain attacks, such as [[buffer overflow]]s.		Self-modifying code is also sometimes used by programs that do not want to reveal their presence, such as [[computer virus]]es and some [[shellcode]]s. Viruses and shellcodes that use self-modifying code mostly do this in combination with [[polymorphic code]]. Modifying a piece of running code is also used in certain attacks, such as [[buffer overflow]]s.

Onel5969: Disambiguating links to Mix (link changed to MIX (abstract machine)) using DisamAssist.

2024-01-09T10:07:55Z

Disambiguating links to Mix (link changed to MIX (abstract machine)) using DisamAssist.

← Previous revision		Revision as of 10:07, 9 January 2024
Line 95:		Line 95:

	==History==		==History==
	The [[IBM SSEC]], demonstrated in January 1948, had the ability to modify its instructions or otherwise treat them exactly like data. However, the capability was rarely used in practice.<ref name="Bashe-Buchholz-Hawkins-Ingram-Rochester_1981"/> In the early days of computers, self-modifying code was often used to reduce use of limited memory, or improve performance, or both. It was also sometimes used to implement subroutine calls and returns when the instruction set only provided simple branching or skipping instructions to vary the [[control flow]].<ref name="Miller_2006"/><ref name="Wenzl-Merzdovnik-Ullrich-Weippl_2019"/> This use is still relevant in certain ultra-[[Reduced instruction set computer\|RISC]] architectures, at least theoretically; see for example [[one-instruction set computer]]. [[Donald Knuth]]'s [[MIX]] architecture also used self-modifying code to implement subroutine calls.<ref name="Knuth_MMIX"/>		The [[IBM SSEC]], demonstrated in January 1948, had the ability to modify its instructions or otherwise treat them exactly like data. However, the capability was rarely used in practice.<ref name="Bashe-Buchholz-Hawkins-Ingram-Rochester_1981"/> In the early days of computers, self-modifying code was often used to reduce use of limited memory, or improve performance, or both. It was also sometimes used to implement subroutine calls and returns when the instruction set only provided simple branching or skipping instructions to vary the [[control flow]].<ref name="Miller_2006"/><ref name="Wenzl-Merzdovnik-Ullrich-Weippl_2019"/> This use is still relevant in certain ultra-[[Reduced instruction set computer\|RISC]] architectures, at least theoretically; see for example [[one-instruction set computer]]. [[Donald Knuth]]'s [[MIX (abstract machine)\|MIX]] architecture also used self-modifying code to implement subroutine calls.<ref name="Knuth_MMIX"/>

	==Usage==		==Usage==

Isaidnoway: Undid revision 1194399758 by 74.79.33.16 (talk) Reverting unexplained sourced content removal

2024-01-08T23:28:07Z

Undid revision 1194399758 by 74.79.33.16 (talk) Reverting unexplained sourced content removal

← Previous revision		Revision as of 23:28, 8 January 2024
Line 72:		Line 72:
	</syntaxhighlight>		</syntaxhighlight>
	[[Lisp macro]]s also allow runtime code generation without parsing a string containing program code.		[[Lisp macro]]s also allow runtime code generation without parsing a string containing program code.

			The Push programming language is a [[genetic programming]] system that is explicitly designed for creating self-modifying programs. While not a high level language, it is not as low level as assembly language.<ref name="Push"/>

	====Compound modification====		====Compound modification====

74.79.33.16: /* High-level languages */

2024-01-08T20:37:57Z

High-level languages

← Previous revision		Revision as of 20:37, 8 January 2024
Line 72:		Line 72:
	</syntaxhighlight>		</syntaxhighlight>
	[[Lisp macro]]s also allow runtime code generation without parsing a string containing program code.		[[Lisp macro]]s also allow runtime code generation without parsing a string containing program code.

	The Push programming language is a [[genetic programming]] system that is explicitly designed for creating self-modifying programs. While not a high level language, it is not as low level as assembly language.<ref name="Push"/>

	====Compound modification====		====Compound modification====

Matthiaspaul: Undid revision 1188102315 by Onel5969 (talk) Good faith, but the previous link target was the better one, and also WP:NOTBROKEN and MOS:NOPIPE

2023-12-26T22:40:59Z

Undid revision 1188102315 by Onel5969 (talk) Good faith, but the previous link target was the better one, and also WP:NOTBROKEN and MOS:NOPIPE

← Previous revision		Revision as of 22:40, 26 December 2023
Line 152:		Line 152:
	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 architecture family\|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.<ref name="linux_self_modifying_Paltsev">{{cite web \|author-last=Paltsev \|author-first=Evgeniy \|title=Self Modifying Code in Linux Kernel - What, Where and How \|date=2020-01-30 \|url=https://talk.telematika.org/2019/all/self_modifying_code_in_linux_kernel_-_what_where_and_how/ \|access-date=2022-11-27}}</ref><ref name="linux_self_modifying_altinstructions">{{cite web \|author-last=Wieczorkiewicz \|author-first=Pawel \|title=Linux Kernel Alternatives \|url=https://grsecurity.net/linux_kernel_alternatives \|access-date=2022-11-27}}</ref> To a lesser extent, the [[DR-DOS]] kernel also optimizes speed-critical sections of itself at loadtime depending on the underlying processor generation.<ref name="Caldera_1997_DOSSRC"/><ref name="Paul_1997_OD-A3"/><ref group="nb" name="NB_DR-DOS_386"/>		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 architecture family\|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.<ref name="linux_self_modifying_Paltsev">{{cite web \|author-last=Paltsev \|author-first=Evgeniy \|title=Self Modifying Code in Linux Kernel - What, Where and How \|date=2020-01-30 \|url=https://talk.telematika.org/2019/all/self_modifying_code_in_linux_kernel_-_what_where_and_how/ \|access-date=2022-11-27}}</ref><ref name="linux_self_modifying_altinstructions">{{cite web \|author-last=Wieczorkiewicz \|author-first=Pawel \|title=Linux Kernel Alternatives \|url=https://grsecurity.net/linux_kernel_alternatives \|access-date=2022-11-27}}</ref> To a lesser extent, the [[DR-DOS]] kernel also optimizes speed-critical sections of itself at loadtime depending on the underlying processor generation.<ref name="Caldera_1997_DOSSRC"/><ref name="Paul_1997_OD-A3"/><ref group="nb" name="NB_DR-DOS_386"/>

	Regardless, at a [[~~Meta (prefix)\|~~meta-level]], programs can still modify their own behavior by changing data stored elsewhere (see [[metaprogramming]]) or via use of [[type polymorphism\|polymorphism]].		Regardless, at a [[meta-level]], programs can still modify their own behavior by changing data stored elsewhere (see [[metaprogramming]]) or via use of [[type polymorphism\|polymorphism]].

	==={{anchor\|Synthesis}}Massalin's Synthesis kernel===		==={{anchor\|Synthesis}}Massalin's Synthesis kernel===

Onel5969: Disambiguating links to Meta (link changed to Meta (prefix)) using DisamAssist.

2023-12-03T10:07:50Z

Disambiguating links to Meta (link changed to Meta (prefix)) using DisamAssist.

← Previous revision		Revision as of 10:07, 3 December 2023
Line 152:		Line 152:
	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 architecture family\|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.<ref name="linux_self_modifying_Paltsev">{{cite web \|author-last=Paltsev \|author-first=Evgeniy \|title=Self Modifying Code in Linux Kernel - What, Where and How \|date=2020-01-30 \|url=https://talk.telematika.org/2019/all/self_modifying_code_in_linux_kernel_-_what_where_and_how/ \|access-date=2022-11-27}}</ref><ref name="linux_self_modifying_altinstructions">{{cite web \|author-last=Wieczorkiewicz \|author-first=Pawel \|title=Linux Kernel Alternatives \|url=https://grsecurity.net/linux_kernel_alternatives \|access-date=2022-11-27}}</ref> To a lesser extent, the [[DR-DOS]] kernel also optimizes speed-critical sections of itself at loadtime depending on the underlying processor generation.<ref name="Caldera_1997_DOSSRC"/><ref name="Paul_1997_OD-A3"/><ref group="nb" name="NB_DR-DOS_386"/>		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 architecture family\|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.<ref name="linux_self_modifying_Paltsev">{{cite web \|author-last=Paltsev \|author-first=Evgeniy \|title=Self Modifying Code in Linux Kernel - What, Where and How \|date=2020-01-30 \|url=https://talk.telematika.org/2019/all/self_modifying_code_in_linux_kernel_-_what_where_and_how/ \|access-date=2022-11-27}}</ref><ref name="linux_self_modifying_altinstructions">{{cite web \|author-last=Wieczorkiewicz \|author-first=Pawel \|title=Linux Kernel Alternatives \|url=https://grsecurity.net/linux_kernel_alternatives \|access-date=2022-11-27}}</ref> To a lesser extent, the [[DR-DOS]] kernel also optimizes speed-critical sections of itself at loadtime depending on the underlying processor generation.<ref name="Caldera_1997_DOSSRC"/><ref name="Paul_1997_OD-A3"/><ref group="nb" name="NB_DR-DOS_386"/>

	Regardless, at a [[meta-level]], programs can still modify their own behavior by changing data stored elsewhere (see [[metaprogramming]]) or via use of [[type polymorphism\|polymorphism]].		Regardless, at a [[Meta (prefix)\|meta-level]], programs can still modify their own behavior by changing data stored elsewhere (see [[metaprogramming]]) or via use of [[type polymorphism\|polymorphism]].

	==={{anchor\|Synthesis}}Massalin's Synthesis kernel===		==={{anchor\|Synthesis}}Massalin's Synthesis kernel===

Matthiaspaul: /* References */ CE

2023-11-27T22:27:58Z

References: CE

← Previous revision		Revision as of 22:27, 27 November 2023
Line 229:		Line 229:
	==References==		==References==
	{{Reflist\|refs=		{{Reflist\|refs=
	<ref name="Massalin_1992_Synthesis">{{Cite thesis \|author-first1=Calton \|author-last1=Pu \|author-link1=Calton Pu \|author-first2=Henry \|author-last2=Massalin \|author-link2=Henry Massalin \|author-first3=John \|author-last3=Ioannidis \|degree=PhD \|title=Synthesis: An Efficient Implementation of Fundamental Operating System Services \|publisher=Department of Computer Sciences, [[Columbia University]] \|location=New York~~, NY~~, USA \|id=UMI Order No. GAX92-32050 \|date=1992 \|url=https://www.scs.stanford.edu/nyu/04fa/sched/readings/synthesis.pdf \|access-date=2023-04-25}} [https://www.cs.columbia.edu/~library/TR-repository/reports/reports-1992/cucs-039-92.ps.gz]</ref>		<ref name="Massalin_1992_Synthesis">{{Cite thesis \|author-first1=Calton \|author-last1=Pu \|author-link1=Calton Pu \|author-first2=Henry \|author-last2=Massalin \|author-link2=Henry Massalin \|author-first3=John \|author-last3=Ioannidis \|degree=PhD \|title=Synthesis: An Efficient Implementation of Fundamental Operating System Services \|publisher=Department of Computer Sciences, [[Columbia University]] \|location=New York, USA \|id=UMI Order No. GAX92-32050 \|date=1992 \|url=https://www.scs.stanford.edu/nyu/04fa/sched/readings/synthesis.pdf \|access-date=2023-04-25}} [https://www.cs.columbia.edu/~library/TR-repository/reports/reports-1992/cucs-039-92.ps.gz]</ref>
	<ref name="Henson_2008">{{cite news \|title=KHB: Synthesis: An Efficient Implementation of Fundamental Operating Systems Services \|author-first=Valerie \|author-last=Henson \|author-link=Valerie Henson \|date=2008-02-20 \|work=LWN.net \|url=https://lwn.net/Articles/270081/ \|access-date=2022-05-19 \|url-status=live \|archive-url=https://web.archive.org/web/20210817175159/https://lwn.net/Articles/270081/ \|archive-date=2021-08-17}}</ref>		<ref name="Henson_2008">{{cite news \|title=KHB: Synthesis: An Efficient Implementation of Fundamental Operating Systems Services \|author-first=Valerie \|author-last=Henson \|author-link=Valerie Henson \|date=2008-02-20 \|work=LWN.net \|url=https://lwn.net/Articles/270081/ \|access-date=2022-05-19 \|url-status=live \|archive-url=https://web.archive.org/web/20210817175159/https://lwn.net/Articles/270081/ \|archive-date=2021-08-17}}</ref>
	<ref name="Haeberli_1994_GraficaObscura">{{cite web \|author-first1=Paul \|author-last1=Haeberli \|author-link1=Paul Haeberli \|author-first2=Bruce \|author-last2=Karsh \|title=Io Noi Boccioni - Background on Futurist Programming \|work=Grafica Obscura \|date=1994-02-03 \|url=https://www.graficaobscura.com/future/index.html \|access-date=2023-04-25}}</ref>		<ref name="Haeberli_1994_GraficaObscura">{{cite web \|author-first1=Paul \|author-last1=Haeberli \|author-link1=Paul Haeberli \|author-first2=Bruce \|author-last2=Karsh \|title=Io Noi Boccioni - Background on Futurist Programming \|work=Grafica Obscura \|date=1994-02-03 \|url=https://www.graficaobscura.com/future/index.html \|access-date=2023-04-25}}</ref>

Matthiaspaul: /* See also */ +link

2023-10-18T21:39:56Z

← Previous revision		Revision as of 22:40, 26 December 2023
Line 152:		Line 152:
	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 architecture family\|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.<ref name="linux_self_modifying_Paltsev">{{cite web \|author-last=Paltsev \|author-first=Evgeniy \|title=Self Modifying Code in Linux Kernel - What, Where and How \|date=2020-01-30 \|url=https://talk.telematika.org/2019/all/self_modifying_code_in_linux_kernel_-_what_where_and_how/ \|access-date=2022-11-27}}</ref><ref name="linux_self_modifying_altinstructions">{{cite web \|author-last=Wieczorkiewicz \|author-first=Pawel \|title=Linux Kernel Alternatives \|url=https://grsecurity.net/linux_kernel_alternatives \|access-date=2022-11-27}}</ref> To a lesser extent, the [[DR-DOS]] kernel also optimizes speed-critical sections of itself at loadtime depending on the underlying processor generation.<ref name="Caldera_1997_DOSSRC"/><ref name="Paul_1997_OD-A3"/><ref group="nb" name="NB_DR-DOS_386"/>		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 architecture family\|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.<ref name="linux_self_modifying_Paltsev">{{cite web \|author-last=Paltsev \|author-first=Evgeniy \|title=Self Modifying Code in Linux Kernel - What, Where and How \|date=2020-01-30 \|url=https://talk.telematika.org/2019/all/self_modifying_code_in_linux_kernel_-_what_where_and_how/ \|access-date=2022-11-27}}</ref><ref name="linux_self_modifying_altinstructions">{{cite web \|author-last=Wieczorkiewicz \|author-first=Pawel \|title=Linux Kernel Alternatives \|url=https://grsecurity.net/linux_kernel_alternatives \|access-date=2022-11-27}}</ref> To a lesser extent, the [[DR-DOS]] kernel also optimizes speed-critical sections of itself at loadtime depending on the underlying processor generation.<ref name="Caldera_1997_DOSSRC"/><ref name="Paul_1997_OD-A3"/><ref group="nb" name="NB_DR-DOS_386"/>

	Regardless, at a [[~~Meta (prefix)\|~~meta-level]], programs can still modify their own behavior by changing data stored elsewhere (see [[metaprogramming]]) or via use of [[type polymorphism\|polymorphism]].		Regardless, at a [[meta-level]], programs can still modify their own behavior by changing data stored elsewhere (see [[metaprogramming]]) or via use of [[type polymorphism\|polymorphism]].

	==={{anchor\|Synthesis}}Massalin's Synthesis kernel===		==={{anchor\|Synthesis}}Massalin's Synthesis kernel===

← Previous revision		Revision as of 10:07, 3 December 2023
Line 152:		Line 152:
	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 architecture family\|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.<ref name="linux_self_modifying_Paltsev">{{cite web \|author-last=Paltsev \|author-first=Evgeniy \|title=Self Modifying Code in Linux Kernel - What, Where and How \|date=2020-01-30 \|url=https://talk.telematika.org/2019/all/self_modifying_code_in_linux_kernel_-_what_where_and_how/ \|access-date=2022-11-27}}</ref><ref name="linux_self_modifying_altinstructions">{{cite web \|author-last=Wieczorkiewicz \|author-first=Pawel \|title=Linux Kernel Alternatives \|url=https://grsecurity.net/linux_kernel_alternatives \|access-date=2022-11-27}}</ref> To a lesser extent, the [[DR-DOS]] kernel also optimizes speed-critical sections of itself at loadtime depending on the underlying processor generation.<ref name="Caldera_1997_DOSSRC"/><ref name="Paul_1997_OD-A3"/><ref group="nb" name="NB_DR-DOS_386"/>		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 architecture family\|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.<ref name="linux_self_modifying_Paltsev">{{cite web \|author-last=Paltsev \|author-first=Evgeniy \|title=Self Modifying Code in Linux Kernel - What, Where and How \|date=2020-01-30 \|url=https://talk.telematika.org/2019/all/self_modifying_code_in_linux_kernel_-_what_where_and_how/ \|access-date=2022-11-27}}</ref><ref name="linux_self_modifying_altinstructions">{{cite web \|author-last=Wieczorkiewicz \|author-first=Pawel \|title=Linux Kernel Alternatives \|url=https://grsecurity.net/linux_kernel_alternatives \|access-date=2022-11-27}}</ref> To a lesser extent, the [[DR-DOS]] kernel also optimizes speed-critical sections of itself at loadtime depending on the underlying processor generation.<ref name="Caldera_1997_DOSSRC"/><ref name="Paul_1997_OD-A3"/><ref group="nb" name="NB_DR-DOS_386"/>

	Regardless, at a [[meta-level]], programs can still modify their own behavior by changing data stored elsewhere (see [[metaprogramming]]) or via use of [[type polymorphism\|polymorphism]].		Regardless, at a [[Meta (prefix)\|meta-level]], programs can still modify their own behavior by changing data stored elsewhere (see [[metaprogramming]]) or via use of [[type polymorphism\|polymorphism]].

	==={{anchor\|Synthesis}}Massalin's Synthesis kernel===		==={{anchor\|Synthesis}}Massalin's Synthesis kernel===

← Previous revision		Revision as of 22:27, 27 November 2023
Line 229:		Line 229:
	==References==		==References==
	{{Reflist\|refs=		{{Reflist\|refs=
	<ref name="Massalin_1992_Synthesis">{{Cite thesis \|author-first1=Calton \|author-last1=Pu \|author-link1=Calton Pu \|author-first2=Henry \|author-last2=Massalin \|author-link2=Henry Massalin \|author-first3=John \|author-last3=Ioannidis \|degree=PhD \|title=Synthesis: An Efficient Implementation of Fundamental Operating System Services \|publisher=Department of Computer Sciences, [[Columbia University]] \|location=New York~~, NY~~, USA \|id=UMI Order No. GAX92-32050 \|date=1992 \|url=https://www.scs.stanford.edu/nyu/04fa/sched/readings/synthesis.pdf \|access-date=2023-04-25}} [https://www.cs.columbia.edu/~library/TR-repository/reports/reports-1992/cucs-039-92.ps.gz]</ref>		<ref name="Massalin_1992_Synthesis">{{Cite thesis \|author-first1=Calton \|author-last1=Pu \|author-link1=Calton Pu \|author-first2=Henry \|author-last2=Massalin \|author-link2=Henry Massalin \|author-first3=John \|author-last3=Ioannidis \|degree=PhD \|title=Synthesis: An Efficient Implementation of Fundamental Operating System Services \|publisher=Department of Computer Sciences, [[Columbia University]] \|location=New York, USA \|id=UMI Order No. GAX92-32050 \|date=1992 \|url=https://www.scs.stanford.edu/nyu/04fa/sched/readings/synthesis.pdf \|access-date=2023-04-25}} [https://www.cs.columbia.edu/~library/TR-repository/reports/reports-1992/cucs-039-92.ps.gz]</ref>
	<ref name="Henson_2008">{{cite news \|title=KHB: Synthesis: An Efficient Implementation of Fundamental Operating Systems Services \|author-first=Valerie \|author-last=Henson \|author-link=Valerie Henson \|date=2008-02-20 \|work=LWN.net \|url=https://lwn.net/Articles/270081/ \|access-date=2022-05-19 \|url-status=live \|archive-url=https://web.archive.org/web/20210817175159/https://lwn.net/Articles/270081/ \|archive-date=2021-08-17}}</ref>		<ref name="Henson_2008">{{cite news \|title=KHB: Synthesis: An Efficient Implementation of Fundamental Operating Systems Services \|author-first=Valerie \|author-last=Henson \|author-link=Valerie Henson \|date=2008-02-20 \|work=LWN.net \|url=https://lwn.net/Articles/270081/ \|access-date=2022-05-19 \|url-status=live \|archive-url=https://web.archive.org/web/20210817175159/https://lwn.net/Articles/270081/ \|archive-date=2021-08-17}}</ref>
	<ref name="Haeberli_1994_GraficaObscura">{{cite web \|author-first1=Paul \|author-last1=Haeberli \|author-link1=Paul Haeberli \|author-first2=Bruce \|author-last2=Karsh \|title=Io Noi Boccioni - Background on Futurist Programming \|work=Grafica Obscura \|date=1994-02-03 \|url=https://www.graficaobscura.com/future/index.html \|access-date=2023-04-25}}</ref>		<ref name="Haeberli_1994_GraficaObscura">{{cite web \|author-first1=Paul \|author-last1=Haeberli \|author-link1=Paul Haeberli \|author-first2=Bruce \|author-last2=Karsh \|title=Io Noi Boccioni - Background on Futurist Programming \|work=Grafica Obscura \|date=1994-02-03 \|url=https://www.graficaobscura.com/future/index.html \|access-date=2023-04-25}}</ref>

← Previous revision		Revision as of 21:39, 18 October 2023
Line 202:		Line 202:
	* [[AARD code]]		* [[AARD code]]
	* [[Algorithmic efficiency]]		* [[Algorithmic efficiency]]
			* [[Data as code]]
	* [[eval]] statement		* [[eval]] statement
	* [[IBM 1130#Code modification\|IBM 1130]] (Example)		* [[IBM 1130#Code modification\|IBM 1130]] (Example)