Talk:Self-modifying code: Difference between revisions

Revision as of 15:48, 10 October 2015

Latest revision as of 12:00, 21 June 2025

(25 intermediate revisions by 18 users not shown)

Line 1:

{{WikiProject Computer sciencebanner shell|class=C |importance=Mid}}

{{WikiProject Computer science |importance=Mid}}

{{WikiProject Computing |software=y |software-importance=Low |importance=Low}}

}}

==TODO==

Line 10 ⟶ 13:

Is a [[thunk]] and/or a [[trampoline (computers)]] also a kind of self-modifying code?

--[[User:DavidCary|DavidCary]] 03:01, 18 August 2005 (UTC)

:Not unless the code is generated at run time - and, even there, unless existing code is overwritten, ''I'' wouldn't call it self-modifying code. (I.e., I think this article should apply only to cases where existing code is modified; I don't think the generation of ''new'' code at run time can reasonably be described as code doing "self-modification".) [[User:Guy Harris|Guy Harris]] ([[User talk:Guy Harris|talk]]) 08:10, 15 May 2022 (UTC)

-----

Line 69 ⟶ 74:

:Awww, go on, it's not all that bad. What is required is a calm attitude and appreciation of the actual environment. By using the stack working area, you ensure the avoidance of clashes in a quite proper way. This is what multi-stack designs are all about, and by writing in assembler (with proper commentary) you need not be constrained by the shibboleths of the prating orthodoxists of flabbier computer languages that constrain themselves and declare it good. In other words, I have misbehaved also, and declare it good. [[User:NickyMcLean|NickyMcLean]] ([[User talk:NickyMcLean|talk]]) 19:51, 18 December 2008 (UTC)

:I'd call that "run-time code generation", not "self-modifying code". Unfortunately, this page covers both topics; there is some overlap, in that code could generate other code at run time on top of existing code, which involves both run-time code generation and self-modifying code, but some self-modifying code doesn't involve particularly sophisticated code generation, and run-time code generation may generate ''new'' code into "empty" memory rather than replacing ''existing'' code. I'd classify what you did as the latter; the generated code is on the stack, the code you copied is just a template used by the code-generation process. [[User:Guy Harris|Guy Harris]] ([[User talk:Guy Harris|talk]]) 08:18, 15 May 2022 (UTC)

== JIT? ==

Line 125 ⟶ 131:

:I don't see "von Neumann" anywhere in the article, but I think that the relationship is that the [[von Neumann architecture]] envisaged a computer with a single memory space comprising both data and instructions. Self-modifying code would require that a program be able to treat a piece of memory as data and then reach it as an instruction, and would not be possible on a non-von Neumann computer with, for example, separate code and data spaces. (Who is King John?) [[User:Spike-from-NH|Spike-from-NH]] ([[User talk:Spike-from-NH|talk]]) 00:26, 25 April 2012 (UTC)

::I'm not sure what a "modified" von Neumann architecture is; a [[modified Harvard architecture]] could be one of at least three types:

::*an architecture with one address space for both instructions and data, but with separate instruction and data caches and separate buses between the CPU and the two caches, i.e. what the "modified Harvard architecture" page calls a "[[modified Harvard architecture#Split-cache (or almost-von-Neumann) architecture|split-cache architecture]]";

::*an architecture with separate address spaces for instructions and data, but with instructions that allow fetches from, or stores into, the instruction address space, i.e. what the "modified Harvard architecture" page calls a "[[modified Harvard architecture#Instruction-memory-as-data architecture|instruction-memory-as-data architecture]]";

::*an architecture like that of the [[Maxim Integrated]] MAXQ family of processors, which the "modified Harvard architecture" page calls a "[[modified Harvard architecture#Data-memory-as-instruction architecture|data-memory-as-instruction architecture]], and which is not exactly easy to explain (MAXQ is ''different'').

::The only one of those that I might call a "modified von Neumann architecture" would be the first of them, as, for the vast majority of operations, it is indistinguishable from an ''un''modified von Neumann architecture. The primary difference visible to most user-mode code is that, on ''some'' such architectures, stores must ensure that all caches, whether instruction, data, or unified, be updated or flushed (this is the case on [[x86]], for backwards compatibility with older processors without any caches or with only a unified cache) and, on others, a store is not guaranteed to flush instruction caches, and the architecture defines an instruction or instructions to force a flush, and attempts to execute the code being modified are not guaranteed to work correctly until after the instruction completes (this is the case on [[SPARC]], for example).

::In the case of x86, I think there ''might'' be instruction-pipeline issues that require some care when modifying code, dating all the way back to the [[8086]]; a case could perhaps be made that ''any'' architecture on which there is no guarantee that casually storing into the instruction stream will Just Work is a "modified von Neumann architecture", even if it's not a "modified Harvard architecture" in the sense of "it has, at some level, separate buses for fetching instructions and data, even though code and data are in the same address space and the same physical memory".

::So I don't see any way in which "any hardware that can allow self-modifying code to run in at least one operating system" is required to be "a "modified von Neumann architecture" computer" - no modification to the von Neumann architecture is necessary to support that. A particular architecture might be "modified" in the sense that it requires that care be taken when storing into code space, but an architecture could also require that no code need be taken, and require implementations to do whatever is necessary to make that be the case.

::I.e., being a von Neumann architecture in the address-space sense is sufficient; a "split-cache architecture" is a pure or modified von Neumann architecture in the address-space sense, and a modified Harvard architecture in the "bus between the CPU and the lowest level of caches" sense.

::Even the other flavors of modified Harvard architecture could conceivably support self-modifying code. [[User:Guy Harris|Guy Harris]] ([[User talk:Guy Harris|talk]]) 07:22, 15 May 2022 (UTC)

== Apple II copy-protection citation? ==

Line 130 ⟶ 145:

Does anyone know if there is a citation for the anecdote of using self-mod code as a copy protection technique on the Apple II? I remember reading about it somewhere 20 years ago when I was 'into' the Apple II in high school (back when "20 megabytes" was considered "really in-humanly humungously big" LOL) [[User:Jimw338|Jimw338]] ([[User talk:Jimw338|talk]]) 21:35, 14 March 2013 (UTC)

:Don't know about Apple II, but I hae one PC game that used self-mod as copy protection. One had to käy in sequence from The manual and If it was correct The software rewrote some instructiins so that The program would run. The reason I sound it was because I had copied disk and no manual. Used assembler debugger to check what was going on and found that self modifing codes. Bypassed IT and The game functioned like it should. [[Special:Contributions/217.140.200.97|217.140.200.97]] ([[User talk:217.140.200.97|talk]]) [[Special:Contributions/217.140.200.97|217.140.200.97]] ([[User talk:217.140.200.97|talk]]) 20:06, 9 April 2025 (UTC)

== Javascript example is definitely not self-modifying code. ==

== Really bad ==

This article is really bad, IMO. It seems to wander around without really declaring a purposeful path through a series of poorly illustrative examples. I'm not sure I truly understand what historically the term "self-modifying code" meant, but this article does little to remedy that. Some examples:

*distinctions are drawn for initialization and "on-the-fly" modifying of code, but it is really unclear why this is a meaningful distinction to be made

*a division between low-level and high-level languages is also embedded in the article

**this seems to imply that self-modifying code is somehow related to a choice of language, which seems at odds with generic computation theory

**the provided examples seem remote from an average reader

***the low-level examples seem to focus on arcana without grounding the examples in practical reality

****these examples seem teleological

****it's unclear whether the low-level examples are historical curiosities, or still have practical value

***the high-level examples seem to just be examples that it "can be done" in the language, leaving a practical example for the reader to intuit

****many of the listed languages aren't mainstream

*there seems to be some unstated assumption running through the article about the useful ___domain of applicability of self-modifying code

*there aren't "side-by-side" examples of self-modifying code and non-self-modifying code, allowing for an apples-to-apples comparison of techniques <small class="autosigned">—&nbsp;Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[Special:Contributions/70.247.175.126|70.247.175.126]] ([[User talk:70.247.175.126|talk]]) 05:56, 5 November 2015 (UTC)</small><!-- Template:Unsigned IP --> <!--Autosigned by SineBot-->

== External links modified ==

Hello fellow Wikipedians,

I have just added archive links to {{plural:1|one external link|1 external links}} on [[Self-modifying code]]. Please take a moment to review [https://en.wikipedia.org/w/index.php?diff=prev&oldid=707310055 my edit]. If necessary, add {{tlx|cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{tlx|nobots|deny{{=}}InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

*Added archive http://web.archive.org/web/20160105054118/http://public.carnet.hr/~jbrecak/sm.html to http://public.carnet.hr/~jbrecak/sm.html

When you have finished reviewing my changes, please set the ''checked'' parameter below to '''true''' or '''failed''' to let others know (documentation at {{tl|Sourcecheck}}).

I'm a programmer, let me explain:

{{sourcecheck|checked=true}}

By assigning a new function to a variable, the variable will point to the new function, not the old function itself was modified.

Cheers.—[[User:Cyberbot II|<sup style="color:green;font-family:Courier">cyberbot II</sup>]]<small><sub style="margin-left:-14.9ex;color:green;font-family:Comic Sans MS">[[User talk:Cyberbot II|<span style="color:green">Talk to my owner</span>]]:Online</sub></small> 02:57, 28 February 2016 (UTC)

I have two example, one in Javascript, one another in C/C++:

== Proposed merge with [[Out-of-order execution]] ==

Javascript:

This appears to just be a possible subset or alias of self-modifying code. [[User:Ethanpet113|Ethanpet113]] ([[User talk:Ethanpet113|talk]]) 07:47, 18 November 2018 (UTC)

<syntaxhighlight lang="javascript">

* '''Don't merge''' – ''Out-of-order execution'' appears ''nicely?'' self contained generally about pre-emptive execution, and has come to the fore with some recent exploits. I take Self-modifying code as a different subject though there may be arguably be a slight overlap. But in all events I wouldn't regard this merge as likely to produce a helpful result.[[User:Djm-leighpark|Djm-leighpark]] ([[User talk:Djm-leighpark|talk]]) 10:26, 18 November 2018 (UTC)

var greet= function () {

alert("hello!");

}

var temp = hello;

greet = function () {

alert("What's 'greet'?");

}

greet(); // display "What's 'greet'?", you may think it is self-modifying, but wait!

temp(); // display "hello!", if it was self-modifying, why it is not "What's 'greet'?"

</syntaxhighlight>

* '''Don't merge''' - absolutely not. OOE is a CPU's designers "modifying" a programmer's code whereas self-modifying code is a programmer's code modifying itself. Also, the former requires custom engineering in silicon and is more properly a subset of CPU design than any kind of subset of self-modifying code. [[User:Michaelmalak|Michaelmalak]] ([[User talk:Michaelmalak|talk]]) 17:59, 18 November 2018 (UTC)

Now, the similar code for C++ 14: Pointer assigning, it works just like javascript above

* '''Don't merge''' - Different topics. Code isn't self modified when executed out of order. ~[[User:Kvng|Kvng]] ([[User talk:Kvng|talk]]) 14:08, 21 November 2018 (UTC)

<syntaxhighlight lang="C++">

#include <iostream>

* '''Don't merge''' - Regarding out-of-order execution as similar to self-modifying code requires quite a twist of thinking. Like, at run time, code protected by an IF-test is executed on the assumption that the result of the IF will be the same as before, but, this time it will not be and the code should not have been executed, so the results of that execution are undone (except, ho ho, for the contents of on-chip memory caches) so that could be regarded as code modification, in that the results of the code are modified by being undone. Sortof... So, nope. Or possibly, that the apparent machine code, as executed by the microcode interpreter on the fly by the actual hardware (well, with its own programmable logic gates) involves activities that are not in direct correspondence to the static machine code and further, the mix changes on each iteration as well, so all this is dynamic code modification as the hardware churns through the microcode that implements the nominal machine code. Humm. Nothing like a piece of machine code modifying some other stretch of machine code, without reference to hardware running microcode. [[User:NickyMcLean|NickyMcLean]] ([[User talk:NickyMcLean|talk]]) 11:16, 22 November 2018 (UTC)

int main() {

*'''Closed as no consensus to merge''' - these are different concepts as used for different reasons. [[User:Ostrichyearning3|Ostrichyearning3]] ([[User talk:Ostrichyearning3|talk]]) 00:36, 25 November 2018 (UTC)

using namespace std;

== Massalin's Synthesis kernel ==

auto greet = [] {

cout << "hello!\n";

};

Is Massalin's Synthesis kernel really relevant here? I propose removing it. [[User:Peter Flass|Peter Flass]] ([[User talk:Peter Flass|talk]]) 16:26, 11 January 2019 (UTC)

auto temp = greet;

* '''Keep''' - surely it is an example of self-modifying code, and done by an operating system to itself? As distinct from an operating system modifying its various internal tables or linked-lists to activate or terminate a new task.[[User:NickyMcLean|NickyMcLean]] ([[User talk:NickyMcLean|talk]]) 08:49, 12 January 2019 (UTC)

== Reality check from Redmond. ==

greet = [] {

cout << "What's 'greet'?\n";

};

Article should mention that self-modifying code is essentially incompatible with '''digitally signed executables''' (which is a common practice and gradually becoming a de facto requirement within the Microsoft Windows OS ecosystem). [[Special:Contributions/94.21.160.52|94.21.160.52]] ([[User talk:94.21.160.52|talk]]) 23:06, 5 December 2024 (UTC)

greet();

temp();

== Disadvantages ==

return 0;

This does not seem to belong in the "Disadvantages" section: ''"Self-modifying code can be rewritten as code that tests a flag and branches to alternative sequences based on the outcome of the test, but self-modifying code typically runs faster."'' The statement that it can be rewritten doesn't seem to be a disadvantage, and the statement that it runs faster seems clearly to be an advantage.

}

</syntaxhighlight>

So, this could possibly be listed in "Advantages" as: ''"Self-modifying code typically runs faster than equivalent code that tests a flag and branches to alternative sequences based on the outcome of a test."'' - but seems a bit redundant with the existing "Fast paths can be established for a program's execution..." statement. Comments? [[User:Harris7|Harris7]] ([[User talk:Harris7|talk]]) 12:00, 21 June 2025 (UTC)

It's is modifying value of a pointer which point to a function, so it's normally modifying a variable. So, what is really self-modifying? Self-modifying is modifying the program structure itself in memory (RAM); when a program is opened, it entire mechine code will be load in a memory region in RAM, a self-modifier will modify that region instead of modifying variables. <small><span class="autosigned">—&nbsp;Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[User:Khải|Khải]] ([[User talk:Khải|talk]] • [[Special:Contributions/Khải|contribs]]) 15:47, 10 October 2015 (UTC)</span></small><!-- Template:Unsigned --> <!--Autosigned by SineBot-->