AI and Self Modifying Code

[google] "self-modifying code"

-me

You should check out CoreWars :)

There is a windows Interpretter called WinCore

A program can't change itself. This is because it is running and depends on itself to run the program. When a file is saved it completly wipes the file and then saves over it so the program would glitch. So what you need is another copy of the program and a source. Then a file that rights the new programs.

The program will send a command to the source saying that it needs to change itself and the source will activate the writing program to write over your copy then the copy will send a string saying it is updated and working and it will turn on the second copy and auto enter all values in the first so whatever it's other function is won't be restarted. Then the first will be deactivated and rewriten. Then this will send a string to the source telling it that it is ready to take control back over the program.

C# can generate its own code procedurally, compile it, and run it all without restarting the main app.

And there's nothing stopping you from generating native code on the fly in any other language with direct access to memory, but you'd have to do a lot more work yourself.

Quote:

Original post by tjweb92 A program can't change itself. This is because it is running and depends on itself to run the program. When a file is saved it completly wipes the file and then saves over it so the program would glitch. So what you need is another copy of the program and a source. Then a file that rights the new programs. The program will send a command to the source saying that it needs to change itself and the source will activate the writing program to write over your copy then the copy will send a string saying it is updated and working and it will turn on the second copy and auto enter all values in the first so whatever it's other function is won't be restarted. Then the first will be deactivated and rewriten. Then this will send a string to the source telling it that it is ready to take control back over the program.

You're completely wrong. Machine code can be changed in memory, and it's not impossible (though not easy) to save it back to the file. The reason saving the changes is difficult is twofold, with neither part being the reason you stated. First, windows loads executables by mapping the file to memory, which causes it to be locked as long as it remains open. Luckily, ntdll.dll exports a function that allows you to unmap the executable, but it must be used with caution because simply calling the funciton in a standard executable would cause the code to be unloaded as well, so special measures must be taken in the code to prevent that from happening. The second problem is that executables are not stored on disk in the same layout they are stored in memory, so there would need to be a transformation function to adjust addresses, padding, etc.

In C or C++, making a self-modifying executable would be extremely difficult and would require non-standard extensions to the languages. In machine code/assembly, it's possible but not easy, and in higher level languages such as Common Lisp, the only hard part is saving the changes (and that might not be too hard depending on the implementation).

Code which changes its behaviour over time, is NOT the same as self-modifying code, which literally modifies itself. An AI algorithm could gradually change its behaviour without needing to modify itself.

Self modifying code was used historically to save a bit of space occasionally in assembly language, and as an obfuscation method.

There is no case for self modifying code any more.

Almost as bad, is code-writing-code - of which you could argue, one example is a compiler. But some applications do create code from other code, this code generation is considered a more reasonable technique.

So it might be feasible even, to have an application which outputs source code for a new (modified) version of itself, feeds it into the compiler then chains that. However, it would be very weird :)

Mark

Quote:

Original post by markr [...]So it might be feasible even, to have an application which outputs source code for a new (modified) version of itself, feeds it into the compiler then chains that. However, it would be very weird :)[...]

That's called "reflection", and it's not weird at all. Also, self-modifying code isn't so bad in languages like Lisp, where code is data is code in a proper fashion. Of course, it's not the same as self-modifying machine code, but it does the same thing of modifying code (in place or not depending on the garbage collector etc) without having separate "generate code, compile, replace old code" steps.

The general term for this kind of thing is "metaprogramming", and it's done all the time with templates in C++, preprocessor statements in C, Common Lisp macros, etc.

Java programmers might play with self modifying executable code safely (most bad types of resulting source files, actually arrays, would return error code in compilation thus amount of crashes would be greatly reduced), at the cost of writing theirs own class loader.
Of course there are some isues, like what rights would have that self modified code.

If you are exploring this area, be aware that OS writers (including those writing console operating systems) are slowly backing away from self modifying code.

Basically, it is seen as a security risk. If code is marked as 'read only', the system can trap virus/buffer-exploit attempts at taking control of the system. This is particularly risky on platforms where security is critical (ie the 360 and PS3).

If you go this route, be aware that your code might not work on some platforms in the future.

I guess one way for me to do it is to write code into a DLL file and then load and execute that portion of code which would make security less of a problem. When I need to update the code I could just unload the file write my code into it and reload it again.

In Prolog (like in Lisp, but maybe even more so) self-modifying code is nothing special, mainly because there's no difference between (in c/c++ terms) is date and program, the program is data and data forms a program. Data/Programs consist of facts and rules, generating rules/data in memory and saving them to file (or directly to file) is easy.

There is a good Prolog (Free, as in beer) called SWI-Prolog, it has an extensive c/c++ interface and you can integrate the prolog engine in your c/c++ program, the opposite is equally possible (for speeding up (imperative) procedures, since it's not always the fastest language.

But having said so, you can write a rule-based decision system in no time, and will be easy to maintain, and as I pointed out in the above, dynamically changing that rule-base is fully possible, so your program/agent can learn as it goes along.

Actually, if we are looking at AI scripts, then there's no reason why it can't be modified in real-time. Well, its just how you define "modify." You can fairly easily "swap" behavior sets.

So, if you have a creature and 10 sets of behavior scripts, you can cycle through them and see how well each one performs, then modify them as they get swapped out. Kind of like what you do in Genetic Programming. However, there's a reason why GP isn't very popular or used alot. There are infinite looping issues with solutions generated in GP, especially if you want to support looping as a feature. It gets really nasty because its not trivial to tell the difference between an infinite loop and one that's just executing a large number of times. Apart from that, if you maintain strong type checks, GP should work pretty well.