Diskussion:Selbstmodifizierender Code

message: * Im Artikel steht, eine Programmiertechnik, die selbstmodifizierenden Code benutzt, habe gravierende Nachteile. Welche Nachteile sind das?
* Im Artikel steht: Selbstmodifizierende Programme, die die Hochsprache des Programms modifizieren, sind in der Zukunft möglicherweise hilfreich, die Maschinenintelligenz zu steigern. Aha. "möglicherweise". Und wie? 
--Knorxx 18:53, 21. Jun 2006 (CEST)
thread_title:  überarbeiten 

message: Der exec-Befehl von Perl und Shell-Sprachen wird als hochsprachliche Möglichkeit von selbstmodifizierendem Code gehandelt und ist offenbar von der Prozessorarchitektur unabhängig. Oder? -- Olaf Studt 21:40, 10. Apr. 2008 (CEST)
replies: text: stimmt. ebenso dlopen(), runtime-linker, JIT-Compiler, compiler-libraries (wie etwa tcc von Fabrice Bellard), selbst Grafiktreiber für GPUs mit programmierbaren Shadern, die Teile des Codes erst zur Laufzeit generieren und linken. -- 89.247.78.15 20:39, 13. Apr. 2008 (CEST)
thread_title:  exec-Befehl 

message: Der Artikel ist in Teilen inkorrekt (oder stellt diese Programmiertechnik zumindest recht einseitig verzerrend von Seiten der Gegner des Konzeptes dar). Bitte mit der englischen Version abgleichen, und den NPOV wahren. JIT-Compiler sind prominente Beispiele für in großem Maßstab verwendete Techniken dieser Art (u.a. Java, ECMAScript/ActionScript/JavaScript und auch dotnet/C#, selbst DirectX/OpenGL-GLSL Grafiktreiber von modernen GPUs mit programmierbaren Shadern lassen sich als distributed self-modifying software interpretieren, die ihren eigenen Code erst zur Laufzeit mit zusätzlich compilierten, gelinkten, geladenen Shadern kombinieren und z.T. auf verschiedene Prozessoren verteilt). Zumindest die Zusammenarbeit/Synchromisation von Daten- und Instruktions-Caches sollte Erwähnung finden, wie im engl. Artikel. -- 89.247.78.15 20:37, 13. Apr. 2008 (CEST)
thread_title:  Korrektheit, NPOV 

message: Mit Verlaub - der Artikel ist ziemlich daneben. Einiges ist Theoriefindung, anderes ist falsch. Außerdem ist er zu langatmig, ohne wirklich auf den Punkt zu kommen.
Beispiele: mal muss der Maschinenkode verändert werden können, mal geht es doch in höheren Programmiersprachen. Dabei trifft man da ein Muster, das erklärt werden könnte.
Dann muss ein Programm selbstmodifizierender Kode interpretiert werden (oder doch nicht? - klare Aussagen sind schwierig, scheint es). Lisps eval scheint dem Autor unbekannt zu sein, dabei ist es ein Showcase, und es widerlegt gleichzeitig die Repräsentation des Programms als Zeichenkette. Die Mutmaßungen über Archtitekturen gehören ebenfalls gelöscht/überarbeitet. Man sehe auch meinen Vorredner. -- ZZ (Diskussion) 17:37, 20. Mär. 2013 (CET)
thread_title:  Überarbeiten 

message: Das angeführte Beispiel vermag nicht so recht zu überzeugen. Die BASIC Versionen von MS (z.B. C64) wechseln durch Druck auf die Taste "RUN STOP" oder den Programmbefehl STOP in den Direktmodus (BASIC- Editor). Die Variablenwerte und geladenen Parameter (z.B. Einsprung- und Rücksprungadressen) bleiben dabei erhalten bis mit "CLR" gelöscht oder durch Drücken der Tasten "RUN STOP" + "RESTORE" in den Einschaltzustand zurückversetzt oder ein Kaltstart (bei C64 mit SYS(64738)) ausgeführt oder (bei späteren Modellen) die RESET- Taste gedrückt wird. Im Direktmodus können neue Programmzeilen hinzugefügt und Variablen und selbstdefinierte Funktionen (DEF FN) neu zugewiesen werden; Soweit ist also alles richtig. Danach muss (wie vollkommen richtig ausgeführt) mit CONT oder GOTO XXX das Programm fortgesetzt werden. Es handelt sich also um eine Art der Programmsteuerung, vergleichbar mit dem Austauschen von Lochkarten in der Computersteinzeit.
Offensichtlich kann der Direktmodus ausgetrickst werden, indem eine neue Programmzeile und darunter der Befehl zur Fortsetzung des Programms ausgegeben, der Cursor an den Anfang der neuen Programmzeile (in diesem Beispiel linke obere Bildschirmecke) gesetzt und der Tastaturpuffer mit dem Zeichen für WAGENRÜCKLAUF (CHR(13)) gefüllt wird, um die Programmzeile sowie den Befehl zur Programmfortsetzung einzulesen. Die Tastatureingaben des Benutzers werden also simuliert, insofern kann von kreativer Programmierung unter Ausnutzung des Direktmodus aber strenggenommen nicht von SELBSTmodifizierendem Code gesprochen werden.
Tatsächlicher SELBSTmodifizierender Code ist mit MS- BASIC in sehr umständlicher Weise möglich: Wenn dem Programmierer bekannt ist, in welchem Speicherbereich der BASIC Code gespeichert ist, kann dieser Bereich mit dem POKE- Befehl (direkter Speicherzugriff!) neu beschrieben werden. Dies ist zwar nicht Prozessorabhängig aber Abhängig von der Speicherverwaltung des Systems. (nicht signierter Beitrag von 77.20.41.194 (Diskussion) 22:20, 29. Jun. 2013 (CEST)
replies: text: Also wenn ein Programm eigene Programmzeilen löschen, ändern, neue Zeilen hinzufügen kann, dann ist das ein Paradebespiel für selbstmodifizierende Programme. Auf dem C64 kann das Programm dafür den Editor des Systems quasi als Werkzeug verwenden, um die Modifikation durchzuführen, aber anschließend ist es eben zweifelsfrei modifiziert. Da der Editor im ROM immer garantiert verfügbar ist, kann er praktisch auch als eine Erweiterung der ebenfalls im ROM befindlichen Sprache betrachtet werden. Die Technik ist auch kein "obskurer Trick", sondern wird in der gehobenen C64-Literatur vielfach behandelt. --95.90.185.28 16:57, 13. Sep. 2022 (CEST)
thread_title:  Beispiel Mathematikprogramm - MS- BASIC 

message: Ich finde den Artikel interessant, aber es fehlt noch einiges an Informationen. Ich habe mich in meiner Bachelorarbeit sehr intensiv mit diesem Thema auseinander gesetzt. Besonders was die Gefahren und Vorteile angeht habe ich viel Ausgearbeitet. Zum Beispiel nennt man es in der Literatur häufig SMC oder SMOC - was definitiv in der Einleitung erwähnt werden sollte.
Ein wesentliches Ergebnis meiner Arbeit war die Unterscheidung der "."-Operatoren in Skriptsprachen und Kompilierten sprachen. Bei Skriptsprachen hat dieser eine völlig andere Semantik und sorgt lediglich für Laufzeitfehler wogegen in kompilierten Sprachen der Compiler bereits frühzeitig streikt. Für Selbstmodifikationen in Hochsprachen ist es daher dringend notwendig den "."-Operator zu ergänzen oder einen neuen Operator einzuführen, der nicht zur Kompilierzeit geprüft wird. Erst dies ermöglicht freie Modifikation in Hochsprachen. Ich konnte mit einigen Tricks Java soweit umbiegen, dass viele Modifikationen bereits in Version 6 hervorragend möglich waren. 
Ansonsten fehlt im wesentlichen SmallTalk in diesem Artikel. SmallTalk war im Gegensatz zu Java oder C# als voll objektorientierte Hochsprache bereits 100% in der Lage Modifikationen zur Laufzeit über Metaklassenmanipulation durchzuführen. C++ schaffte das dann ab weil es als "unsauber" galt (und natürlich 'langsam' ist). Java führt zumindest die Introspektion über Metaklassen wieder ein. Modifikationen werden leider nur angestrebt aber nicht explizit sondern meistens über das JVM-Tool-Interface (Debugger). Hinzufügen von Methoden ist hier problemfrei möglich. Austauschen von Source ohne die Signatur zu verändern ebenfalls. Löschen und freies editieren wird zumindest vom Interface angeboten aber war in Java-6 openjdk und sun nicht implementiert. 
Ich kann meine Bachelorarbeit Interessierten daher gerne ans Herz legen: https://www.kriese.at/wp-content/uploads/2014/03/Bachelorarbeit.pdf (Vorabversion) und vielleicht finde ich auch mal Zeit diesen Artikel ein wenig auf zu werten ;) Aktuell habe ich nur Zeit diese Diskussion ein wenig zu ergänzen.
--Christian.Buerckert (Diskussion) 17:42, 26. Apr. 2014 (CEST)
thread_title:  Ein paar Infos zu Self Modifying Code 

message: Hier ist selbstmodifizierender Code in Brainfuck implementiert worden, um gewisse Aufgaben zu loesen. Also es wird ueber einen Optimierungsalgorithmus Brainfuckcode staendig modifiziert, um ein gewuenschtes Ergebnis zu erhalten. Als Masz wird die "Outputdifferenz" genommen.
http://www.primaryobjects.com/2013/01/27/using-artificial-intelligence-to-write-self-modifying-improving-programs/
--Demon667 (Diskussion) 12:23, 14. Okt. 2018 (CEST)
replies: text: Service: Brainfuck ;-) --rolf_acker (Diskussion • Beiträge) 11:27, 12. Jun. 2020 (CEST)
thread_title:  Interessanter Link