Diskussion:Selbstmodifizierender Code

Lisp und Prolog

Wie sieht es mit Lisp oder Prolog aus, das sind Hochsprachen mit der Fähigkeit zur Selbstmodifikation.

Es wäre interessant zu wissen, ob Lisp, Prolog Programme auch auf einer Harvard-Architektur laufen. Wenn ja, dann wird kein echter Selbstmodifizierender Code compiliert, sondern simuliert. -- PANAMATIK 18:30, 3. Apr 2006 (CEST)

Beides sind oft interpretierte Sprachen.

Insofern kann man diese generell als "simuliert" bezeichnen oder auch nicht.

--arilou (Diskussion) 12:52, 2. Mär. 2015 (CET)

überarbeiten

• 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)

Es sind die Nachteile gemeint, die am Ende des Artikels aufgeführt sind.

Es sollte damit angedeutet werden, daß die Aussicht besteht, mit einer Selbstmodifizierung eines Programms im großen Stil eine 'Verbesserung' des Programms zu erzielen, ähnlich wie bei Lebewesen durch die Auslese in der Evolution. Eine Maschine, die sich selbst sinnvoll umprogrammieren kann und hinzulernt, ist dann auch mit einer Maschinenintelligenz ausgestattet. Mit unseren heutigen Programmiertechniken ist das noch nicht gelungen und es ist unklar wie es einmal erreicht werden kann. -- PANAMATIK 21:16, 21. Jun 2006 (CEST)

hhs:

Mein (etwas langer Senf) dazu, zu lang für die Hauptseite, und ich bin kein Autor.

Nachteil des selbstmodifizierenden Codes ist, daß er an die Maschinensprache gebunden ist. Üblicherweise beherrschen nur Assemblerprogrammierer diese Technik, die durch Maschinencode sehr hardwarenah angesiedelt ist.

Drei Beispiele:

1. Das Microprocessor-Entwicklungssystem von Motorola, Exorsizer, bestand ca. 1976 aus einem 1MHz M6800 mit 32kb RAM, aufrüstbar auf maximal 56kb. Das 8-Zoll- Doppelfloppy-Laufwerk sollte 11.000 DM kosten, die 56kb-Speicherkarte 10.000 ;-) Das Betriebssystem MDOS benötigte ca. 12 kb, obwohl es sehr umfangreich war. Der Trick: Kernel, 3 Overlay-Regionen + residenten/transienten Command-Interpreter. Das Filesystem war eleganter als FAT, der Editor Marke Edlin besser als der vom später kommenden IBM-PC. Der Beginn einer jeden Overlay-Region bestand aus einer Sprungtabelle. War die Funktion verfügbar, wurde weitergesprungen ins Overlay zur Funktion, war sie nicht verfügbar, wurde zum Overlay-Handler gesprungen, der das passende Overlay lud, und exakt zur Aufrufadresse rückkehrte, nur daß diesmal die passende Adresse drinstand. Fazit: damals unvermeidbare Technik, aber heute ebenso angewendet bei Auslagerungsdateien.

2. Relozierbarer Code: Ein Programm sollte eigentlich laufen können, egal an welcher Stelle meines Gigabyte-grossen Speichers es steht. Da hatten Prozessoren mit kilobyte-großen Adressräumen erhebliche Probleme, ach was solls, das EXE-Format ist das beste Beispiel. Wenn die CPU relative Adressierung nur in einem kleinen Bereich beherrscht und ansonsten auf absolute Adressierung angewiesen ist, muß man die Adressen halt beim Laden des Programms je nach Lage verändern. Beim Exe-Format macht das der Lader, bei anderen Prozessoren gibt es den Trick, beim Start in ein Unterprogramm zu springen, das die Rücksprungadresse vom Stack holt, und geeignet berücksichtigt, indem entweder der Programmspeicher an den relevanten Stellen verändert wird, wie es das Exe-Format erfordert, oder schlicht und einfach die Basisadresse in ein Indexregister gesetzt wird, und damit das Programm angepasst ist. Da gibt/gab es halt große Unterschiede zwischen intel und dem Rest der Welt.

3. Assemblerprogrammierung Ein C-Programm wird in Maschinencode übersetzt, und läuft als Maschinencode ab, daher hat man wenig Chancen, selbstmodifizierenden Code in C zu schreiben. Natürlich geht das auch in C, vorausgesetzt, der Programmierer versteht den von C erzeugten Assemblercode, und kennt Maschinencode, und kann sich darauf verlassen, daß seine Modifikationen (Maschinencode) an die passenden Stellen geschrieben werden. Da gibt es wenig Hilfestellung seitens der Werkzeuge, man muß wissen was man macht, unter Umständen erst nach dem Übersetzungslauf die zu ersetzenden Bytes rausfinden und einsetzen und nochmal übersetzen. Das ganze war früher fehlerträchtig, erforderte Sorgfalt und Überblick, und eben durch mehr Test mehr kostbare Zeit, und ist heutzutage wenig sinnvoll. Assemblerprogrammierung überhaupt ist heute seltenst erforderlich, im Mozilla-Projekt eine handvoll Zeilen in einem Modul, um diese Relokationsschwierigkeiten auf verschiedenen Platformen zu lösen.

4. der Motorola 8-Bitter M6800 hatte 6800 Transistoren, der 32-bitter M68000 angeblich 68000 Transistoren. Als der 6800 anfing preiswert zu werden, kostete er 40DM, das PIA, ein 40-Pin Baustein mit zwei 8-Bit-Ports und 4 Interrupteingängen 25DM. 1kx8 EPROM 2708 kostete 1975 ca. 200 DM.

exec-Befehl

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)

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)

Korrektheit, NPOV

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)

Überarbeiten

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)

Im Artikel steht aktuell: "Der selbstmodifizierende Code eines Programms hat nichts mit Lernen oder der Verbesserung eines Programmes zu tun. Selbstmodifizierende Programme, die die Hochsprache des Programms modifizieren, sind in der Zukunft möglicherweise hilfreich, die Maschinenintelligenz zu steigern." Der scheinbare Widerspruch sollte auf jeden Fall näher erläutert und differnzeirt werden Heiko242 (Diskussion) 10:39, 11. Mär. 2016 (CET)

Beispiel Mathematikprogramm - MS- BASIC

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))

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)

Ein paar Infos zu Self Modifying Code

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)

Interessanter Link

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)

Service: Brainfuck ;-) --rolf_acker (Diskussion • Beiträge) 11:27, 12. Jun. 2020 (CEST)