>>Well, in Prolog, the program is able to modify itself by writing new
>>rules and facts to the knowledgebase as time goes on. This allows the
>>program to "learn" from its experiences.

Prolog "programs" are just a "knowledge base" (of logical formulae) which the Prolog implementation ("the solver") then solves.

This is analogous to the fact machine code "programs" are just a "knowledge base" (of machine instructions) which the machine code interpreter (e.g processor) then interpretes.

So basically, the essence of self-modifying code is that the "knowledge base" exploits the interpreter so as to physically modify itself. This kind of "strange loops" (to borrow Hofstadter's terminology) are possible in high-level software systems as well: data structures indirectly changing themselves through an interpreting object.

Sorry, just writing thoughts down =)

-- Mikko

The method using genetic algorithms is called genetic programming. To sum it up in a nutshell, it's a technique using a genetic algorithm to evolve a population of parse trees derived from (usually randomly created) programs. It isn't a form of self-modifying code, but instead it uses chunks of code that can solve a problem to some degree and mixes and matches branches of their parse trees to hopefully improve the population over successive generations until an adequate solution is found. More information here.

Obviously, this isn't a very practical method of developing programs per se, but it has proven useful in evolving viable solutions to a few problems that humans had yet to solve by other means (and to find more optimal solutions than those found by humans).

Correct me if I'm wrong, but self-modifying code in the intended sense is not particularly useful to AI. Not only is it very difficult, if not impossible, to achieve on modern processors (as Rockoon1 said) but what would it accomplish? If it's to alter a program's execution among predetermined code paths, use an if statement, polymorphism, or even probabilistic reasoning to determine which code path to take. If it's to have a program somehow induce code in an artificially intelligent way and then execute it, you're better off using a language that supports the run-time execution of code strings (like Python).

Even then, you have the problem of how to induce the code. Aside from using genetic programming, I don't know of any other useful techniques for code induction. You could try to have the program develop valid code based on knowledge of the target language, but that seems like it would require enough problem-specific information that you could just as easily code the solution yourself.

Off-hand, I can't think of any existing AI techniques that would benefit from self-modifying code, but if there are any, I'd like to hear of them.

-Auron

Be careful when you start self modifying code which alters the the assembly itself (ie changing opcodes on the fly). I believe many people now consider support for this to be a security risk, so it may not fly on newer hardware/OS verions.

The more concerned people get about security, the more likely this technique will be discouraged or prohibited. For example, some next gen consoles (which are ripe targets for software piracy) are doing everything possible to avoid external code being executed. Part of this may be not providing a way to do dynamic code generation/self modifying code.

Apart from terminating rolled out loops self modifying code can speed up many
procedures. Repeated transforms, block drawing and blitting all benefit.

I do not let procedures modify themselves. They are generated by a code generation proc and modified by a code modifier proc.

Some may not consider this truly self modifying code, mere RT generation/modification.

The example below shows that it is possible on an amd64 (in either 32 or 64 bit
mode).

If you want to test it you will have to insert some of this code into an application.

Self Modifying Code?:

DELPHI / PASCAL - I USED LAZARUS
begin SMCG;

type

T65536x8s = array [0..65535] of byte;
T65536Bytes = T65536x8s;
P65536x8s = ^T65536x8s;
P65536Bytes = P65536x8s;

var
Form1: TForm1;
CodePadSpace: P65536x8s; // matches processor code cache size
CodePad: Pointer;
OldProt: PDWord;

implementation

procedure TForm1.RunBtClick(Sender: TObject);
begin
asm
// Modify codepad to contain 1 instruction (leave)
mov [CodePadSpace], $c3 // $c3 = leave (return)
// without the leave statement the (dummy) procedure will not return
// causing an error
// more complex code can be inserted
// the $c3 (leave) instruction could be inserted in a rolled out loop
// so that only x number of instructions are run.
call CodePad
end;
end;

initialization

new(CodePadSpace); // reserved the space
CodePad:=@CodePadSpace; // pointer to a pointer to some memory
VirtualProtect (CodePad, 65535, PAGE_EXECUTE_ReadWrite, OldProt);
// set CodePad as readable, writable and executable
end;