Talk:Self-modifying code

From Wikipedia, the free encyclopedia

Contents

[edit] TODO

  1. an example and discussion of 'high-level' self-modifying code such as in LISP.
  2. examples and discussion of traditional uses of self-modifying code, such as in graphic Blitting units, specialisation of algorithms (like sort with embedding a cmp), and in interpreter kernels.


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'll check the brackets, actually state depedant loops are a sort of self-modifying code I've coded a few times on 8bit machines, when state transition is not freq, esp if altering just the arg of an opcode, thus using a faster instruction (eg, on the 6502). Code-generation is 'still' relevant and useful, eg 'compiled bitmaps' during the 90's, and specific rendering code today.Oyd11 00:42, 13 June 2006 (UTC)

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)

  • Futurist Programming should probably be the new link, although the original author of this document should probably check as they would know whether this is the correct article.

[edit] Javascript example: really self-modifying?

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)

[edit] Obj-C

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)

[edit] Self-modifying code in self-referential machine learning systems

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)

[edit] Dead link

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.

[edit] Reentrant self-modifying code is possible

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 instrunction - 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 instruntion
: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)

I've corrected the above code: the error was in the byte addressed - the low byte of a TRAP instruction was to be altered, not the high byte. (It's a long time since I've used a PDP-11 at assembler level - sorry!) Hair Commodore 20:16, 22 September 2007 (UTC)