Hallo Besucher, der Thread wurde 7,5k mal aufgerufen und enthält 91 Antworten

letzter Beitrag von JeeK am

Umsetzung von Basic-Befehlen in Maschinensprache

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


    Kein Oberbegriff?


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

    alleantworten.de? Im Ernst jetzt? Ich finde dir für jede x-beliebige These irgendeine Seite, die das bestätigt.

    Die 10 Sekunden sieht man deinen Suchergebnissen leider auch an.


    Aber ich denke, wir können das hier beenden. Denn du wirst jetzt mit Händen und Füssen deine Formulierungen verteidigen. Und es geht nicht mehr um die Sache sondern nur noch um's Rechthaben.

  • Ich finde dir für jede x-beliebige Thesen irgendeine Seite, die das bestätigt.

    Genau. Sogar das DLR bestätigt, dass die Erde keine Kugel sondern eine Scheibe ist:

    https://www.dlr.de/next/deskto…d-12657/22082_read-50426/


    Und die sind ganz sicher als Glaubwürdig einzustufen :thumbup:


    SCNR

  • Aber ich denke, wir können das hier beenden. Denn du wirst jetzt mit Händen und Füssen deine Formulierungen verteidigen. Und es geht nicht mehr um die Sache sondern nur noch um's Rechthaben.

    Ähh... also, mir zumindest geht es um die Sache. Die Frage nach dem Oberbegriff ist weiterhin ernst gemeint.

  • Ähh... also, mir zumindest geht es um die Sache. Die Frage nach dem Oberbegriff ist weiterhin ernst gemeint.

    Meine Antwort hatte ich schon gegeben.

  • Meine Antwort hatte ich schon gegeben.

    Und ich hatte die Frage seitdem angepasst.

    "Übersetzen und anschließendes Ausführen": Das wäre eine Just-In-Time-Compiler. Dotnet macht das so. Da wird der "Intermediate Language"-Code beim Laden des Programms in Maschinen-Code umgewandelt und anschließend ausgeführt. Im Gegensatz zu einem Interpreter erfolgt das aber nur einmalig. Anschließend wird dann nur noch der Maschinen-Code ausgeführt.


    Bei einem Interpreter, wird jeder einzelne Befehl vor der Ausführung immer wieder neu interpretiert. Wenn du eine Schleife programmierst, dann wird immer wieder der gleiche Basic-Code interpretiert. Zu keiner Zeit findet sich irgendwo übersetzter Code.



    Und deine "Quelle" widerspricht sich sogar selbst. Les doch einfach mal die beiden Abschnitte in Ruhe durch.

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

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

    Das entspricht nicht der gängigen Lehrmeinung und Definition in der Informatik. Man mag ja solchen gerne nachhängen und seine "Meinung" bekannt geben, aber bitte nicht erwarten, dass die bestehende Auffassung der Mehrheit hiermit geändert wird. Es scheint mir echt verlorene Müh' hier gegen den Strom zu schwimmen und permanent dagegen anzukämpfen.
    Das klingt dann schon leicht trumpesk: Es ist nicht falsch, nur eine "Alternative". Das ist ein bisserl so, wie wenn man einem Polizisten auf die Frage, warum man denn bei Rote die Kreuzung querte, sagt, man sähe das "Rot" als Untergruppe der Farbe "Grün" ... Da kann man auch viel Spaß haben. :)

  • "Übersetzen und anschließendes Ausführen": Das wäre eine Just-In-Time-Compiler. Dotnet macht das so.

    Das muss bei .net aber nicht so sein (ich programmiere selbst in .net). Über den Roslyn-Compiler kann man direkt ausführbaren Code erzeugen, der muss nicht mehr compiliert werden. Aber in der Java-Welt (wie auch in der .net-Welt) war das eine Zeit lang gang und gebe: der Bytecode wurde interpretiert und Schleifen JIT-compiliert, also wirklich erst zur Laufzeit. Und in frühen Java-Versionen wurde der JIT-Compiler, wenn man Pech hatte, für die gleiche Schleife immer wieder ausgeführt. Inzwischen compiliert Java aber meines Wissens nach beim Start den kompletten Bytecode, bevor es los geht - wie .net (wenn man die Option nicht nutzt) auch.

  • "Übersetzen und anschließendes Ausführen": Das wäre eine Just-In-Time-Compiler. Dotnet macht das so.

    Das muss bei .net aber nicht so sein (ich programmiere selbst in .net). Über den Roslyn-Compiler kann man direkt ausführbaren Code erzeugen, der muss nicht mehr compiliert werden.

    Macht das irgendeinen merkbaren Unterschied?

  • Im Gegensatz zu einem Interpreter erfolgt das aber nur einmalig.

    Es ist nicht unüblich, bei Just-in-Time-Compilern den Code mehr als einmal zu übersetzen - zuerst mit einem schnellen, aber schlecht optimierenden Compiler und später die Hotspots nochmal mit mehr Zeitaufwand und mehr Wissen um die Umstände der üblichen Aufrufe. Das ergibt einerseits einen schnellen Start und andererseits schnellen Code da, wo er gebraucht wird. Und bei JIT für CPU-Emulation landet der übersetzte Code typischerweise in einem Cache, der diese Stücke auch wieder rauswerfen kann, so dass es später zu Neuübersetzungen kommen kann.


    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: Ein Compiler nimmt ein Programm als Eingabe und liefert als Ausgabe das transformierte Programm, zB in Maschinencode - wobei letzteres keine Pflicht ist, es gibt ja zB auch den Typescript-Compiler, der Javascript ausgibt. Für einen Interpreter reicht aber das Programm als Eingabe nicht, er braucht zusätzlich die Eingabe, die das übergebene Programm erwartet und liefert als Ausgabe nur die Ausgabe des Programms mit dieser Eingabe.


    (und ja, mit dieser Interpretation sind Just-in-Time-Compiler in einer Grauzone wo sie mal mehr ein spontan aufgerufener Compiler oder aber mehr Interpreter mit Compiler-Techniken und Codecache sein können)

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

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

    "Interpretieren" ist der exakt passende Begriff. Alternativ könnte man auch noch "Ausführen" sagen.

    Aber es findet keine Übersetzung statt.


    Häng dich doch nicht so an dem Begriff auf. Wir wissen doch alle, dass das zwei grundverschiedene Dinge sind. Da sind wir wieder beim Rechthabenwollen.

  • Macht das irgendeinen merkbaren Unterschied?

    Bei großen .EXE-Dateien macht sich das durchaus mit einigen Sekunden Startverzögerung bemerkbar. Wobei das nur 1x passiert (zumindest bei .net), denn einmal compiliert ist es im Anwendungscache drin. Solange die exe nicht ausgetauscht wird, wird dann ab dem 2. Start die fertige Version aus dem Cache benutzt, sprich: es startet dann sofort.

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

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

    Zitat

    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.

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

    Zitat

    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.

    Auch nicht, habe ich doch schon längst geschrieben, "Zu keiner Zeit..."


    Du beginnst, sämtliche Argumente zu ignorieren und wiederholst stattdessen immer wieder die gleichen Phrasen. Du weisst schon, wie man dieses Verhalten in Foren nennt?


    Ich bin dann jetzt raus.

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

    Der unterschied zwischen Interpreter und Compiler ist aber genau der, dass beim Interpreter diese "Übersetzung" jedes mal beim passieren dieses Codes stattfindet (zur Run-time) und beim Compiler nur einmal (vor der Ausführung, zur Compile-time).
    Hmm, Erstsemestrige haben beim Informatikstudium damit in der Regel keine Probleme, diesen Unterschied zu erfassen oder neigen eher nicht dazu, daraus eine offene Grundsatzfrage der Informatik zu machen. ;)