Posts by goloMAK

    Dennoch ist irgendwo der Punkt gekommen, an dem z.B. ein POKE durch ein LDA + STA ersetzt wird

    Diese Ersetzung bildest du dir nur ein, sie findet nicht statt. Der POKE-Befehl im BASIC-Programm bleibt bestehen, auch nachdem der Interpreter ihn ausgeführt hat.

    Jaa.... natürlich bleibt der POKE-Befehl im BASIC-Programm bestehen. Da sind wir wieder bei der Frage, ob Wasser nass ist.


    Was beim Prozessor ankommt, ist aber eben nicht "POKE", sondern LDA + STA, und auf dem Weg vom BASIC-Speicher zum Prozessor wurde eben dieser Austausch vorgenommen.


    *seufz*

    Habe noch eine schöne Formulierung gefunden, auf die wir uns ja vielleicht einigen können. :)

    Quote

    Interpreter arbeiten anders: Hier wird der Quellcode zusammen mit den nötigen Eingaben von einem Interpreter ausgeführt, der als Programm auf einer Maschine läuft.

    Ein bleibendes Übersetzungsresultat kommt nicht vor.

    Da lese ich heraus, dass es aber sozusagen ein flüchtiges Übersetzungsresultat gibt, und damit könnte ich mich anfreunden.

    Aber ich stimme den meisten Postern hier in diesem Thread zu: Ein Interpreter erzeugt keinen Maschinencode - wenn er das täte, könnte man diesen Maschinencode abspeichern ohne ihn auszuführen. Schon rein strukturell ist klar, dass ein Interpreter etwas ganz anderes ist als ein Compiler

    Moment, ich für meinen Teil habe nie behauptet, dass ein Interpreter "Maschinencode erzeugt". Und natürlich ist ein Interpreter strukturell etwas anderes als ein Compiler. Das ist alles gar nicht strittig.


    Ich sage nur: Interpreter- und Compiler-Programme stehen beide für eine Art der Übersetzung von Hochsprachen in Maschinencode. Der Interpreter ruft dafür fertige Versatzstücke auf, der Compiler eben nicht (ausschließlich).


    Dennoch ist irgendwo der Punkt gekommen, an dem z.B. ein POKE durch ein LDA + STA ersetzt wird, und wenn das keine Übersetzung sein soll, dann hätte ich gerne einen passenderen Begriff dafür.

    Aber ich frage mal andersherum: Welchen Oberbegriff würdet ihr für "interpretieren" und "übersetzen" benutzen?

    Es gibt keinen Oberbegriff, weil das zwei unterschiedliche Dinge sind.


    "Übersetzen" bringt das Programm in eine andere Form, ohne es auszuführen.

    "Interpretieren" führt ein Programm aus.

    Ok, dann präzisiere ich: "Übersetzen und anschließendes Ausführen" auf der einen Seite, und "Interpretieren" auf der anderen.


    Kein Oberbegriff?


    Es ging mir nur darum, dass der Sprachgebrauch hier eben nicht so einheitlich ist.

    Eigentlich ist der in der Informatik sehr einheitlich. Alle hier verstehen das einheitlich, inkl. des Schülerdudens. ;)

    Nun, ich hatte 2 anderslautende Quellen genannt. Mehr als 10 Sekunden Googeln war dafür nicht nötig.

    Schülerduden Die Informatik, Mannheim 1991, Bibliographisches Institut & F.A. Brockhaus AG, S. 240

    Noch Fragen?

    Also, dass es auch andere Definitionen gibt, habe ich nicht bestritten, da hast du dir die Mühe jetzt umsonst gemacht.


    Es ging mir nur darum, dass der Sprachgebrauch hier eben nicht so einheitlich ist.


    Aber ich frage mal andersherum: Welchen Oberbegriff würdet ihr für "interpretieren" und "übersetzen" benutzen?

    Wenn man übersetzt ersteht ein neuer Code. M-Code (Maschinen-Code) oder P-Code oder irgendwas anderes. Das ist das gängige Verständnis und keine einseitige Festlegung. Was du meinst, ist "interpretieren" oder "ausführen".

    Ja, ich meine "interpretieren", was eine Untergruppe von "übersetzen" ist.


    Noch einmal: Wenn das Programm nicht übersetzt werden würde, könnte es auch nicht ausgeführt werden, denn mit "PRINT" kann der Prozessor bekanntlich nichts anfangen. Meine Feststellung ist also ungefähr so aufregend wie "1+1=2".


    Aber man kann es auch "übertragen" oder "umsetzen" nennen, ich will mich jetzt nicht an einzelnen Wörtern aufhängen. Es ging nur um die Begründung, warum der OP kein Maschinenspracheprogramm im Speicher findet, das seinem BASIC-Programm entspricht.


    Im Übrigen:

    Quote

    Was macht ein Interpreter?

    Der Interpreter liest dazu eine oder mehrere Quelldateien ein, analysiert diese und führt sie anschließend Anweisung für Anweisung aus, indem er sie in Maschinencode übersetzt, die ein Computersystem direkt ausführen kann

    https://alleantworten.de/was-ist-der-interpreter


    Quote

    Die Interpreter sind besondere Programme, welche einen eingegebenen Text in einer Programmiersprache Zeile für Zeile nacheinander abarbeiten und dabei direkt in Maschinencode übersetzen.

    https://www.omt.de/lexikon/compiler/

    Die Betonung lag auf "während der Laufzeit immer wieder neu". Das ist der Unterschied zu einem Compiler.

    Also ich stimme deiner Argumentation ja weitgehend zu, aber genau in dem Punkt leider nicht - denn was du beschreibst, ist ein JIT-Compiler, und das ist der Interpreter eben nicht.

    Also, ein JIT-Compiler speichert aber zumindest teilweise auch bereits übersetzten Code und muss ihn dann eben nicht immer wieder neu übersetzen. Deswegen finde ich schon, dass meine Beschreibung besser zu Interpretern passt.


    Die Gemeinsamkeit ist, dass man sich nicht z.B. das komplette BASIC-Programm fertig übersetzt als Maschinencode im Speicher angucken kann, und das war ja ursprünglich die Fragestellung.

    Der C64 hat einen eingebauten Interpreter, d.h. die BASIC-Programme werden während der Ausführung immer wieder neu in Maschinensprache übersetzt, [...]

    Da wird gerade mal gar nichts in Maschinencode übersetzt!

    Doch. Wenn anhand von BASIC-Befehlen der entsprechende Maschinencode im ROM aufgerufen wird, dann ist das eine Übersetzung. Sonst könnte es auch gar nicht laufen, weil der Prozessor bekanntlich nur Maschinencode ausführen kann. Das ist also eine Selbstverständlichkeit.


    Die Betonung lag auf "während der Laufzeit immer wieder neu". Das ist der Unterschied zu einem Compiler.


    Ein Interpreter enthält fertigen aber auch sehr allgemein gehaltenen und darum tendenziell ineffizienten Maschinencode

    Das ist doch hier völlig irrelevant. Dann ist es eben eine ineffiziente Übersetzung.


    Da sich so ein Interpreter im Regelfall keine Ergebnisse der Zwischenauswertungen merkt, macht er diese Arbeit je---des---mal neu

    Genau das schrieb ich doch. Hast es sogar selbst zitiert.


    Als nächstes diskutieren wir darüber, ob Wasser nass ist. :nixwiss:

    Hab auch eins. :)


    Dezimal nach Hex, so schlank und elegant wie es mir eingefallen ist.


    Code
    1. 10 print "=== dezimal in hexadezimal ==="
    2. 20 input "eine dezimalzahl:";a
    3. 30 for p=3 to 0 step -1
    4. 40 : b=int(a/16^p)
    5. 50 : b$=chr$(48-7*(b>9)+b)
    6. 60 : h$=h$+b$
    7. 70 : a=a-b*16^p
    8. 80 next
    9. 90 print "hexadezimalzahl: $";h$

    Diese IF-Orgie im Wiki fand ich auch recht merkwürdig...


    Progrämmle im Anhang.

    Files

    • dez2hex.prg

      (203 Byte, downloaded 1 times, last: )

    Ich habe mir den 64er Assembler-ist-keine-Alchimie Kurs besorgt und meine ersten Gehversuche gemacht.

    Das heißt, du hast jetzt ein 64er Sonderheft zum Thema Assembler? Die fand ich auch immer recht gut. Ich persönlich habe mit dem Sonderheft 35 angefangen.


    Ich würde dir empfehlen, erst einmal alle Befehle durchzugehen (sind nicht so viele) und dann erst dazu überzugehen, bestimmte BASIC-Programme in Maschinensprache zu übertragen.


    Der C64 hat einen eingebauten Interpreter, d.h. die BASIC-Programme werden während der Ausführung immer wieder neu in Maschinensprache übersetzt, man kann sich also kein fertiges Maschinenspracheprogramm im Speicher angucken.


    Siehe auch hier:

    https://www.c64-wiki.de/wiki/Interpreter

    ... wenn du in einem Taxi sitzt und dich fragst, warum der Fahrer nicht einfach über die langsam vorausfahrenden Autos drüberspringt.


    ... wenn du in einem Konferenzraum Tische zu Reihen zusammenschiebst und dich fragst, ob die Reihe dann jetzt nicht gleich verschwindet.


    ... wenn du auf die Dächer deiner Stadt schaust und dich fragst, in welcher Reihenfolge man am besten über die Dächer springen sollte.

    Schön, aber auch schade, denn es war zum Schluss gerade so interessant. ;(

    Was meinst du damit? Fehlt am Schluss noch was?

    Öh... keine Ahnung! :/ Du meintest ja, der Text sei nicht fertig, und da es am Ende gerade so schön spannend war, habe ich mir das dann so zusammengereimt. :)

    Schön, aber auch schade, denn es war zum Schluss gerade so interessant. ;(


    Ich hoffe also trotz vollen Projektkalenders auf eine Fortsetzung, sozusagen POKE53280,1 :)

    Unglaublisch!


    Ich würde ja sagen, das ist unser (virtuelles) Listing des Monats, aber dafür ist es wohl zu kurz, deswegen reicht es leider nur für den Sieger des 2K-Wettbewerbs. :-)


    Ich habe so herrlich keinen Plan, wie dein Programm funktioniert, aber ich gucke es mir noch in Ruhe an, vielleicht komme ich noch dahinter.


    Prost!