Self-modify in C(++) ?

[Buffy]

Originally Posted by Pyrotex

I did self-modifying code at Texas Instruments back in 75, but it was in assembly language. Totally easy. We were bound by 128K bytes of RAM

Yow! That was mainframe-worthy in those days! I was too young to actually get to do much of this except experimentally, and mostly in C, using the technique Q mentions above, but you've made my point: other than the curiosity factor, humongous amounts of RAM and virtual memory have killed the need to do "traditional" self-modifying code.

Fortran's Computed GOTO is actually arguably another "self modifying" code techique, much in derision even when it was in the vogue....

Originally Posted by Pyrotex

{sigh} I have wandered too far from my roots.

Don't get all misty eyed on us. The fact is that with the rapid movement of "fashionable" programming technology, *anyone* can become an expert in 6 months or less (right alex? ). Just go down to the book store and pick up a couple of J2EE and XML books and you'll be an expert in no time!

<? xml version=4.2 ?>
Buffy

[KickAssClown]

That is partisially true, I have to ask though. What do you mean by "other than the curiosity factor, humongous amounts of RAM and virtual memory have killed the need to do "traditional" self-modifying code."

It is my experience that suggest that this trend will begin reversing itself. To much the dismay of some game programers, the problem that arises from "humongous amounts of RAM and virtual memory" is that they have to shell out shite loads of cash to produce dispurportionate ammounts of content while getting less and less bang for their buck.

I didn't think to mention it before, but I think I will. I would suggest that people take a look at one of these two movies if you have the time to spare:

Spore, E3 2006, 20 minutes

Spore, 35 minute game play video

Spore, 1hr 2 minutes, full demo

I advocate all kinds of things, I most of all advocate taking what WORKS and applying it. I know that old method has been over taken by the new methods introduced through the various media, however I also know that the balance has (artificially) been spiked and will eventually return to a 50/50 spread of program/algorythm : Data.

I like the elegance of a program that grows and adapts. That helps me write it.

[Qfwfq]

Well, real-time applications will always be more sensitive to optimization but with today's web stuff, the answer is simply to spread the load on more and more servers. Sheesh, today's JavaKids don't even think twice before concatenating many little strings into one long one, when it's only gonna go into the out stream anyway.

Lately I've been having a break from such horrors but I don't know how long it's going to last. Who knows when I'll find myself flippin' through the pages of a Struts manual...

[Buffy]

You seem to be missing the distinction between "traditional self modifying code" where there's an existing code block that gets modified directly in order to conserve memory usage, versus "generating code on the fly" where the point is not really to modify existing code, but to have it evolve through expansion and contraction without any concern for how effiecient the code is. These are two completely different activities and utilize extremely different techniques: the former is pretty much programmed logically with a full understanding of all possible code paths necessary to avoid bugs; the latter involves allowing code to write it self in possibly highly unpredictable ways.

I agree that the latter is becoming very popular in gaming (this week's Economist even has an article about it!), but its very distinct from the old approach that is indeed moribund....alex's example from the Linux kernel is probably more showing off than anything else, but it does have a--fairly weak in my view--efficiency justification. Self-modifying code of this type is major bug-bait, and should be avoided.

Try Lisp. You'll like it!

(exec (steer (car blue v8) left (speed (accel +10)))))
Buffy

[KickAssClown]

Once again, I only gave an example of something that I could easily think of that was modern and related somewhat.

I am advocating the use of all techniques, old and new, anything that works, to develop true thinking systems. Ala the technogenic brain.

[CraigD]

Since the mid 1980s, most of my focus in computer programming has revolved around the M[UMPS] programming language. Because the language model for M makes it inherently interpreted (vs. compiled), and because it has simple commands for “assign the value of an expression to a symbol” (SET, abbreviated S) and “interpret an expression as M language commands” (XECUTE, abbreviated X), the language lends itself to self-modification. A trivial example – the following conventional program:

w “Hello world”,!
w “How are you?”
q

(WRITE, abbreviated W, is M’s “output to the current device/stream” command, QUIT or Q its “exit current execution frame”) Can be written in a self-modifying way as follows

s A=”w “”Hello world””,! s A=””w “”””How are you?””””,! s A=”””””””””””
f  q:A=””  x A

The symbol A is a program that contains a command to change its own value to another program (consecutive quotes are the quote image, that is, “””” is a literal expression for a single ASCII character 34d), which in turn changes its value to the zero-length string. The next line is a loop (FOR, abbreviated F, in M’s “repeat until QUIT command” structuring command. Commands with a colon and an expression appended are executed only when the expression evaluates as true, so q:A=”” is “quit if A is the zero-length string”) executed the program until it becomes the zero-length string.

Many commercial and “novelty” M programs take advantage of this self-modifying nature, most to allow mundane things such as an editor program supporting multiple terminal device protocols, end user selecting the behavior of application event, and custom report generation.

Finding opportunities to write “learning-like” self-modifying code are unusual, but easy to code in M. A self-referential puzzle game called, for reasons that mystify me “Where are the Cows?” (described in the 12/1996 issue of Scientific American) is such an example.

(see attached image) Starting with 2 pointers, or “pencils”, one in box 1, one in box 7, you may chose to follow the instructions printed in that box for one of the pencils. Some instructions instruct you to change the way you interpret future instructions. The object of the game is to get either pencil into the box marked “Goal”.

As published, it’s actually self-referential, not self modifying, but can easily be made self modifying by the addition of instructions such as “change the instructions in box ‘nn’ to ‘xxx’”

Here’s a M program to allow a user (an i/o stream) to play the game. The instruction in each box is written as executable M code, while information about the board is represented as non-executable symbols

F  R L Q:'$L(L)  S @($P(L," ")_"=$P(L,"" "",2,999)") ;load exec/data
X F CC=0:1 W "("_P(1)_","_P(2)_") " S I="Q|R|1|2" X X("I"),X("ICK") Q:'$L(I)  I I S C=I X R S CP=C ;main driver
X("I") N J F  R J," " I "|"_I_"|"[("|"_J_"|") S I=J Q  ;get keyboard input
X("ICK") X:'I X("ICK",I) ;check keyboard input
	X("ICK","R") S P(1)=1,P(2)=7,R="X B(P(C))",CC=-1 W ! ;reset
X("ICK","Q") S I="" ;quit
R X B(P(C))
P(1) 1
P(2) 7
B(1) S P(C)=B(P(C),$D(B(P(3-C),"C","r"))!$D(B(P(3-C),"C","g")))
B(1,0) 9
B(1,1) 2
B(7,"C","r")
B(9,"C","r")
B(25,"C","r")
B(26,"C","r")
B(40,"C","r")
B(50,"C","r")
B(60,"C","g")
B(61,"C","r")
B(2) S P(C)=B(P(C),$D(B(P(3-C),"C","g"))!$D(B(P(3-C),"T","green")))
B(2,0) 15
B(2,1) 7
B(1,"T","green")
B(2,"T","green")
B(5,"T","green")
B(25,"T","green")
B(40,"T","green")
B(65,"T","green")
B(5)  S P(C)=B(P(C),$D(B(P(3-C),"T","red"))!$D(B(P(3-C),"T","green")))
B(5,0) 2
B(5,1) 25
B(1,"T","red")
B(5,"T","red")
B(25,"T","red")
B(60,"T","red")
B(65,"T","red")
B(7) S P(C)=B(P(C),P(3-C)#2'=0)
B(7,0) 5
B(7,1) 26
B(9) S P(C)=B(P(C),CP'=C)
B(9,0) 35
B(9,1) 2
B(15) S P(C)=B(P(C),P(3-C)#5=0)
B(15,0) 40
B(15,1) 5
B(25) S P(C)=B(P(C),$D(B(P(3-C),"C","r"))!$D(B(P(3-C),"C","g")))
B(25,0) 50
B(25,1) 7
B(26) X B(26,"R") S P(C)=B(P(C),$T)
B(26,"R") N OP,OC,OR M OP=P,OC=C,OR=R N P,C,R M P=OP,C=OC,R=OR S C=3-C X R I $G(B(OP(C),0))=P(C)
B(26,0) 55
B(26,1) 61
B(35) S P(C)=B(P(C),$D(B(P(3-C),"T","word")))
B(35,0) 1
B(35,1) 40
B(2,"T","word")
B(5,"T","word")
B(35,"T","word")
B(40) S P(C)=B(P(C),0)
B(40,0) 60
B(40,1) 65
B(50) S P(C)=B(P(C),$D(B(P(3-C),"T","cows")))
B(50,0) 26
B(50,1) GOAL
B(50,"T","cows")
B(55) S I="1|LUGNUT" X X("I") S P(C)=B(P(C),I)
B(55,"LUGNUT") 7
B(55,1) 15
B(60) S R="X R(60) E  X B(P(C))",P(C)=B(P(C),1)
R(60) I $D(B(P(C),"C","r")) S P(C)=B(P(C),1)
B(60,1) 25
B(61) S P(3-C)=B(P(3-C),1),P(C)=B(P(C),1)
B(61,1) 1
B(65) S R="X B(P(C))",P(C)=B(P(C),1)
B(65,1) 75
B(75) S P(C)=B(P(C),$D(B(P(3-C),"T1","if")))
B(75,0) 50
B(75,1) 1
B(26,"T1","if")
B(61,"T1","if")
B(65,"T1","if")
B("goal")

x X

Here’s a sample of its output, playing the game to success

(1,7) 2 (1,26) 1 (2,26) 1 (15,26) 1 (40,26) 1 (60,26) 2 (60,55) 1 (25,55) 1 (7,55) 1 (26,55) 1 (61,55) 2 1 (61,15) 2 (61,40) 2 (61,65) 2 (61,75) 1 (1,1) 2 (1,9) 2 (1,35) 1 (9,35) 1 (35,35) 2 (35,40) 2 (35,60) 2 (35,25) 2 (35,7) 2 (35,26) 2 (35,61) 2 (35,1) 2 (35,9) 2 (35,2) 2 (35,15) 2 (35,5) 1 (40,5) 2 (40,25) 1 (65,25) 1 (75,25) 2 (75,50) 1 (50,50) 1 (GOAL,50) Q

I’ve flirted with self-modifying code, mostly in the form of standard interpreted languages such as M and BASIC, and a few home-spun languages, for several decades. The most difficult thing, in my experience, is finding a behavior/application that so lends itself to implantation in self-modifying code that it outweighs the weirdness and unpredictability of such code. You can actually write self-modifying code that does something, but what that something is, is difficult determine and describe.