![]() | This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||||||||||||||
|
Is a thunk and/or a trampoline (computers) also a kind of self-modifying code? -- DavidCary 03:01, 18 August 2005 (UTC)
have never written any self modifying code, but example of state-dependent loop doesn't look quite right? Maybe a misplaced curly-bracket? --(AG)
I suggest removing the entire Synthesis section, along with Massalin, Haeberli, and Karsh, on notability grounds. Marc W. Abel 15:12, 26 April 2006 (UTC)
It seems to me that the Javascript code example is not self-modifying. The action variable is merely a function pointer that points to two anonymous functions in the course of its life. All the code from this example could be put in read-only memory and it would execute without problems. Where am I wrong? Sarrazip 02:17, 19 December 2006 (UTC)
I agree with Sarrazip. In addition, I think the placement of the Javascript example does not go under the section of "Interaction of cache and self-modifying code".
I have removed the Javascript code example, since no one has objected for several months. Sarrazip 03:05, 21 May 2007 (UTC)
Possibly Obj-C code in addition to LISP? It's the only object oriented superset of ANSI C that I know of that really implements it as a base feature. [1] -- Electrostatic1 08:51, 15 May 2007 (UTC)
I think there should be a section on self-modifying code for machine learning along the lines of Jürgen Schmidhuber's work on meta-learning: http://www.idsia.ch/~juergen/metalearner.html Algorithms 20:54, 4 June 2007 (UTC)
This appears to be a dead link. Which makes me sad. I was really looking forward to seeing a self-modifying kernel! Guess it's time to whip out Google.
66.93.224.21 11:24, 5 June 2007 (UTC)
- I replaced it with something found on google.
Many years ago, I had to write a piece of code which was reentrant - because of a number of constraints imposed by my interrupt handling methods - but also needed to be self-modifying. To explain: an input was N, the number of a record in a file, and the assembler supplied only one type of TRAP instruction - with a constant. An earlier generation of the application used a TRAP instruction (it was on a PDP-11) thus:
:READ_N: ; R5 points to (unsigned) record number N (assumed <=255 and non-zero) : MOVB 2(R5),10$ ; Modify the TRAP instruction :10$: TRAP 0 ; Read "something" : RETURN
and I needed to retain the mechanism, but make also to make it reentrant.
The solution was simple: have a "virgin copy" of the code available (but never called directly). When it was needed, it was copied it to the top of the stack, together with "cleanup code", where the copy was modified, and executed; finally, the cleanup wiped the stack of the defiled code. All I can say is that it worked.
My simple statement about self-modifying code is this: in bootstrap code, it's fine - but elsewhere: DON'T EVEN THINK ABOUT DOING IT! (Especially where reentrancy is a prerequisite ...) Hair Commodore 18:57, 16 September 2007 (UTC)
Maybe I'm being nit-picky, but I don't think a just-in-time compiler falls into the category of self-modifying code, any more than any other compiler would. It generates some code, and then transfers control to it. It doesn't really alter its own behavior. And in the same vein, I don't think that uncompressing some otherwise static code and then running it qualifies as self-modifying, either. I would reserve the term for code that modifies its own behavior at it is running. Maybe it's a rather vague concept, though. Deepmath ( talk) 11:02, 15 July 2008 (UTC)
Bestsss ( talk) 12:43, 18 December 2008 (UTC)
Under the heading "Henry Massalin's Synthesis kernel" it is claimed that
Such a language and compiler [based on Massalin's techniques] could allow development of extremely fast operating systems and applications.
This sounds like pure speculation to me. —Preceding unsigned comment added by 62.73.248.37 ( talk) 20:10, 28 March 2009 (UTC)
I think there should be reference to the article about monkey patching and vica versa. Monkey patching is a structured and formalised way to do self-modifying code in a an interpreted language. At least Monkey patching could be listed in "See also". What do you think? -- Jarl ( talk) 06:12, 1 May 2009 (UTC)
Lisp has self-modifying code unlike any of the other languages, in fact, a running lisp programming modifies itself the whole time. I would say that Lisp is unique in how it modifies its own code because Lisp has no boundary between data and code, data is stored in Linked lists in lisp, instructions are data with the head being the operation and the tail a list to operate on. Just 'dumping' data in the main runtime is interpreted as executing it accordingly that pattern. In that sense, unlike JavaScript or Perl, Lisp doesn't modify its own syntax or evaluates a string as if it were an expression. Lisp has no syntax, S-expressions are just a convention to encode linked lists, but anything that encode linked lists can create isomorph programs to those in S-expressions.
Therefore, if it's okay with you people I'd like to add a section on Lisp families because they treat self-modifying code in a unique way. Rajakhr ( talk) 22:23, 23 January 2010 (UTC)
Quote from the frist line: "In computer science, self-modifying code is code that alters its own instructions while it is executing - usually to reduce the instruction path length and improve performance or simply to reduce otherwise repetitively similar code, thus simplifying maintenance."
How does self modifying code simplify maintenance? It seems like it actually makes maintenance harder since it is usually more difficult to figure out what the hell is going on. —Preceding unsigned comment added by 129.65.117.57 ( talk) 23:39, 21 February 2010 (UTC)
The paragraph claiming that late binding as "can be regarded as self-modifying code" is pure, unadultereated, farcical bullshit. It is completely at odds with any useful definition of self-modifying code; that is, if virtual functions are self-modifying, *everything is*. Not only is the paragraph wrong, but it's also completely unsupported by actual citations and references to literature. I will remove it shortly if nobody objects. —Preceding unsigned comment added by Quotemstr ( talk • contribs) 20:35, 17 May 2010 (UTC)
The article fails to explain the relation between self-modifying code and "von Neumann" computer architecture. I think any hardware that can allow self-modifying code to run in at least one operating system is identically equal to a "modified von Neumann architecture" computer? Is that right? 82.131.210.163 ( talk) 17:43, 24 April 2012 (UTC)
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) Jimw338 ( talk) 21:35, 14 March 2013 (UTC)
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:
Hello fellow Wikipedians,
I have just added archive links to one external link on
Self-modifying code. Please take a moment to review
my edit. If necessary, add {{
cbignore}}
after the link to keep me from modifying it. Alternatively, you can add {{
nobots|deny=InternetArchiveBot}}
to keep me off the page altogether. I made the following changes:
When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{ Sourcecheck}}).
An editor has reviewed this edit and fixed any errors that were found.
Cheers.— cyberbot II Talk to my owner:Online 02:57, 28 February 2016 (UTC)
This appears to just be a possible subset or alias of self-modifying code. Ethanpet113 ( talk) 07:47, 18 November 2018 (UTC)
Is Massalin's Synthesis kernel really relevant here? I propose removing it. Peter Flass ( talk) 16:26, 11 January 2019 (UTC)
![]() | This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||||||||||||||
|
Is a thunk and/or a trampoline (computers) also a kind of self-modifying code? -- DavidCary 03:01, 18 August 2005 (UTC)
have never written any self modifying code, but example of state-dependent loop doesn't look quite right? Maybe a misplaced curly-bracket? --(AG)
I suggest removing the entire Synthesis section, along with Massalin, Haeberli, and Karsh, on notability grounds. Marc W. Abel 15:12, 26 April 2006 (UTC)
It seems to me that the Javascript code example is not self-modifying. The action variable is merely a function pointer that points to two anonymous functions in the course of its life. All the code from this example could be put in read-only memory and it would execute without problems. Where am I wrong? Sarrazip 02:17, 19 December 2006 (UTC)
I agree with Sarrazip. In addition, I think the placement of the Javascript example does not go under the section of "Interaction of cache and self-modifying code".
I have removed the Javascript code example, since no one has objected for several months. Sarrazip 03:05, 21 May 2007 (UTC)
Possibly Obj-C code in addition to LISP? It's the only object oriented superset of ANSI C that I know of that really implements it as a base feature. [1] -- Electrostatic1 08:51, 15 May 2007 (UTC)
I think there should be a section on self-modifying code for machine learning along the lines of Jürgen Schmidhuber's work on meta-learning: http://www.idsia.ch/~juergen/metalearner.html Algorithms 20:54, 4 June 2007 (UTC)
This appears to be a dead link. Which makes me sad. I was really looking forward to seeing a self-modifying kernel! Guess it's time to whip out Google.
66.93.224.21 11:24, 5 June 2007 (UTC)
- I replaced it with something found on google.
Many years ago, I had to write a piece of code which was reentrant - because of a number of constraints imposed by my interrupt handling methods - but also needed to be self-modifying. To explain: an input was N, the number of a record in a file, and the assembler supplied only one type of TRAP instruction - with a constant. An earlier generation of the application used a TRAP instruction (it was on a PDP-11) thus:
:READ_N: ; R5 points to (unsigned) record number N (assumed <=255 and non-zero) : MOVB 2(R5),10$ ; Modify the TRAP instruction :10$: TRAP 0 ; Read "something" : RETURN
and I needed to retain the mechanism, but make also to make it reentrant.
The solution was simple: have a "virgin copy" of the code available (but never called directly). When it was needed, it was copied it to the top of the stack, together with "cleanup code", where the copy was modified, and executed; finally, the cleanup wiped the stack of the defiled code. All I can say is that it worked.
My simple statement about self-modifying code is this: in bootstrap code, it's fine - but elsewhere: DON'T EVEN THINK ABOUT DOING IT! (Especially where reentrancy is a prerequisite ...) Hair Commodore 18:57, 16 September 2007 (UTC)
Maybe I'm being nit-picky, but I don't think a just-in-time compiler falls into the category of self-modifying code, any more than any other compiler would. It generates some code, and then transfers control to it. It doesn't really alter its own behavior. And in the same vein, I don't think that uncompressing some otherwise static code and then running it qualifies as self-modifying, either. I would reserve the term for code that modifies its own behavior at it is running. Maybe it's a rather vague concept, though. Deepmath ( talk) 11:02, 15 July 2008 (UTC)
Bestsss ( talk) 12:43, 18 December 2008 (UTC)
Under the heading "Henry Massalin's Synthesis kernel" it is claimed that
Such a language and compiler [based on Massalin's techniques] could allow development of extremely fast operating systems and applications.
This sounds like pure speculation to me. —Preceding unsigned comment added by 62.73.248.37 ( talk) 20:10, 28 March 2009 (UTC)
I think there should be reference to the article about monkey patching and vica versa. Monkey patching is a structured and formalised way to do self-modifying code in a an interpreted language. At least Monkey patching could be listed in "See also". What do you think? -- Jarl ( talk) 06:12, 1 May 2009 (UTC)
Lisp has self-modifying code unlike any of the other languages, in fact, a running lisp programming modifies itself the whole time. I would say that Lisp is unique in how it modifies its own code because Lisp has no boundary between data and code, data is stored in Linked lists in lisp, instructions are data with the head being the operation and the tail a list to operate on. Just 'dumping' data in the main runtime is interpreted as executing it accordingly that pattern. In that sense, unlike JavaScript or Perl, Lisp doesn't modify its own syntax or evaluates a string as if it were an expression. Lisp has no syntax, S-expressions are just a convention to encode linked lists, but anything that encode linked lists can create isomorph programs to those in S-expressions.
Therefore, if it's okay with you people I'd like to add a section on Lisp families because they treat self-modifying code in a unique way. Rajakhr ( talk) 22:23, 23 January 2010 (UTC)
Quote from the frist line: "In computer science, self-modifying code is code that alters its own instructions while it is executing - usually to reduce the instruction path length and improve performance or simply to reduce otherwise repetitively similar code, thus simplifying maintenance."
How does self modifying code simplify maintenance? It seems like it actually makes maintenance harder since it is usually more difficult to figure out what the hell is going on. —Preceding unsigned comment added by 129.65.117.57 ( talk) 23:39, 21 February 2010 (UTC)
The paragraph claiming that late binding as "can be regarded as self-modifying code" is pure, unadultereated, farcical bullshit. It is completely at odds with any useful definition of self-modifying code; that is, if virtual functions are self-modifying, *everything is*. Not only is the paragraph wrong, but it's also completely unsupported by actual citations and references to literature. I will remove it shortly if nobody objects. —Preceding unsigned comment added by Quotemstr ( talk • contribs) 20:35, 17 May 2010 (UTC)
The article fails to explain the relation between self-modifying code and "von Neumann" computer architecture. I think any hardware that can allow self-modifying code to run in at least one operating system is identically equal to a "modified von Neumann architecture" computer? Is that right? 82.131.210.163 ( talk) 17:43, 24 April 2012 (UTC)
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) Jimw338 ( talk) 21:35, 14 March 2013 (UTC)
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:
Hello fellow Wikipedians,
I have just added archive links to one external link on
Self-modifying code. Please take a moment to review
my edit. If necessary, add {{
cbignore}}
after the link to keep me from modifying it. Alternatively, you can add {{
nobots|deny=InternetArchiveBot}}
to keep me off the page altogether. I made the following changes:
When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{ Sourcecheck}}).
An editor has reviewed this edit and fixed any errors that were found.
Cheers.— cyberbot II Talk to my owner:Online 02:57, 28 February 2016 (UTC)
This appears to just be a possible subset or alias of self-modifying code. Ethanpet113 ( talk) 07:47, 18 November 2018 (UTC)
Is Massalin's Synthesis kernel really relevant here? I propose removing it. Peter Flass ( talk) 16:26, 11 January 2019 (UTC)