Verständnisfragen zum Compiler/Interpreter

[KOply]

Hallo,

ich informiere mich gerade über die Geschichte von Computern und bin bei dem Teil der Programmiersprachen angelangt. Vieles habe ich verstanden, doch manches noch nicht so ganz. Deshalb wollte ich hier mal nachfragen. Vielleicht kann mir ja jemand helfen.

Ich habe gelernt, dass der Compiler und der Interpreter den Code in einer Programmiersprache in eine Sprache übersetzt, welche die Maschine, also der Computer, also z.B. die CPU lesen kann. Die Unterschiede der beiden kenne ich auch schon. Nun habe ich noch gelernt, dass die Sprache nicht immer direkt in Einsen und Nullen übersetzt wird, sondern erst in eine Zwischensprache. Eine Zwischensprache kann z.B. "C" sein. Zusätzlich gibt es dann auch noch die Assemblersprache, welche ganz knapp über den Einsen und Nullen existiert und je nach System anders aussehen kann.

Nun verstehe ich aber manche Dinge noch nicht ganz:

1. Ist die Assemblersprache auch eine Zwischensprache? Oder kommt die sowieso immer zwingend zum Einsatz und ist dann immer zwischen Zwischensprache und Maschinensprache, sofern es eine Zwischensprache gibt?
2. Wenn ich nun eine Programmiersprache erfinden will, dann muss ich ja die Sprache an sich erfinden (Syntax usw.) und einen Compiler/Interpreter schreiben, welcher dann meine Sprache in Maschinensprache übersetzt, richtig?
3. Aber wenn mir das zu schwer ist, kann ich ja auf z.B. "C" als Zwischensprache zurückgreifen und muss nur bis dahin übersetzen, bin dann aber auf die C-Funktionalitäten begrenzt, richtig?
4. Ich nutze Python Scripts, welche ich in VSC laufen lasse. Ich habe als Addon "Python" installiert. Dadurch bekam ich dann den Interpreter, richtig? Denn nun kann ich meine Scripts direkt in der Umgebung laufen lassen.
5. Wie findet denn aber dann die Übersetzung in Maschinensprache statt? Ich kann mir nicht vorstellen, dass dieses Addon mit dem Interpreter meinen Code direkt in Maschinensprache übersetzt und es an meine Hardware weiterleitet.

Das sind erstmal meine Fragen dazu. Es ist wirklich ein sehr interessantes Thema und ich finde es wichtig das alles zu verstehen. Mich regt es immer innerlich auf, wenn ich etwas mache, aber den Hintergrund gar nicht verstehe. Ich kann viel gelassener an die Sache heran gehen, wenn ich verstehe was unter der Haube abläuft...

Vielen Dank und noch einen schönen, sonnigen Tag!

 

[BeBur]

Ist die Assemblersprache auch eine Zwischensprache?

Es gibt nicht "die" Assemblersprache. Verschiedene CPUs haben verschiedene Assemblersprachen. Das deutet auch schon auf die Antwort hin. Assembler ist in dem Sinne keine Zwischensprache, die Kommandos bei Assembler sind 1:1 die auf einer CPU. Aber es ist quasi eine Menschen-freundliche Repräsentation dieser Kommandos/Bitsequenzen.

Wenn ich nun eine Programmiersprache erfinden will, dann muss ich ja die Sprache an sich erfinden (Syntax usw.) und einen Compiler/Interpreter schreiben, welcher dann meine Sprache in Maschinensprache übersetzt, richtig?

Nicht unbedingt, es reicht eine "Zwischensprache" schau dir mal LLVM (oder genauer LLVM-IR) an.

Ich habe als Addon "Python" installiert. Dadurch bekam ich dann den Interpreter, richtig?

Ja, richtig, aber auch hier: Es gibt nicht "den" Interpreter. Es gibt verschiedene Interpreter für die Sprache Python. Wobei im Falle von Python die Sprache nicht formal spezifiziert ist, anders als z.B. C++.

Wie findet denn aber dann die Übersetzung in Maschinensprache statt? Ich kann mir nicht vorstellen, dass dieses Addon mit dem Interpreter meinen Code direkt in Maschinensprache übersetzt und es an meine Hardware weiterleitet.

Doch, genauso ist es, bzw. läuft das ganze über das Betriebsystem, glaube ich. Vielleicht kann dazu noch jemand was schreiben.

 

[KOply]

Es gibt nicht "die" Assemblersprache.

Ja ok, das hatte ich ja eingangs schon erwähnt gehabt.

1:1 die auf einer CPU

Ich dachte die CPU kann nur Einsen und Nullen lesen? Daher dachte ich, dass die Assemblersprache eben nochmal über der Maschinensprache ist und der Assembler dann die menschenfreundliche Schreibweise in Einsen und Nullen übersetzt.

Nicht unbedingt, es reicht eine "Zwischensprache" schau dir mal LLVM an.

Ok, danke. Hatte ich dann ja schon in der Frage darauf vermutet, dass eine Zwischensprache bereits ausreicht. LLVM sagt mir nichts, schaue ich mir an.

Doch, genauso ist es.

Aber ist das kein Sicherheitsrisiko? VBC kann also direkt Code auf meiner Hardware ausführen? Ich dachte, dass es erst noch über andere Schichten geht, welche das Betriebsystem liefert.

 

[Aduasen]

Ja, es wird vom Compiler in 'maschinenausführbaren' Code umgesetzt.

Allerdings kann dieser Code dann 'kompliziert' oder 'einfach' sein.
So ähnlich, wie wenn zwei Menschen zwar das Gleiche erzählen aber der eine extrem umständlich und die andere kurz und prägnant.
Da liegt der Unterschied bei den Compilersprachen - je aufgeblähter sie sind, desto 'beschissener' ist der Maschinencode, der dabei raus kommt.
Tut am Ende zwar das Gleiche, die Ausführung dauert aber länger.

Das ist heutzutage im normalen Anwendungen zwar relativ irrelevant, weil Computer in den letzten Jahrzehnten zunehmend schneller geworden sind.
Aber es ist absolut spür- und erfahrbar.
Allein schon, wenn man sieht, wie riesig die Programmpakete heutzutage sind.

Wenn Du effizienten Code hinbekommen möchtest, dann würde ich Dir empfehlen, direkt Assembler zu lernen.

 

[BeBur]

Ich dachte die CPU kann nur Einsen und Nullen lesen? Daher dachte ich, dass die Assemblersprache eben nochmal über der Maschinensprache ist und der Assembler dann die menschenfreundliche Schreibweise in Einsen und Nullen übersetzt.

Schau dir mal 1.1 und 1.2 hiervon an: Link.

Aber ist das kein Sicherheitsrisiko? VBC kann also direkt Code auf meiner Hardware ausführen? Ich dachte, dass es erst noch über andere Schichten geht, welche das Betriebsystem liefert.

Ich hatte kurz darauf noch was reineditiert. Ja, soweit ich weiß läuft alles über das OS und das entscheidet dann letztendlich (z.B. ob die Speicheradresse gelesen bzw. geschrieben werden darf). Da kenne ich mich aber nicht gut aus mit. Die Hardware selber hat dann auch noch mal Sicherheitsmerkmale, soweit ich micht entsinne.

Wenn Du effizienten Code hinbekommen möchtest, dann würde ich Dir empfehlen, direkt Assembler zu lernen.

Ich habe es selber nicht ausprobiert, aber allgemein sagt man, dass moderne Compiler im Regelfall deutlich performanteren Assembler-Code generieren als das ein Mensch üblicherweise schafft. Es mag immer mal wieder Fälle geben, wo das nicht so ist. Aber das spielt in der Praxis nur in ganz bestimmten Kontexten überhaupt nur eine Rolle.

 

[Mickey Mouse]

vielleicht hilft es, wenn du wirklich ganz unten anfängst!
Was ist eine CPU? Da gibt es schon verschiedene Arten/Ausführungen. Heute redet man allgemein nur noch über Von Neumann Architekturen (VNA) Maschinen. Da gibt es dann RISC/CISC, 8, 16, 32, 64bit usw. aber das sind für das Verständnis eher Details.

nehmen wir ein Beispiel, wie eine 8-bit CPU (VNA) arbeiten könnte:

• reset -> lese den 8-bit Wert von Adresse 0 und interpretiere den als Befehl
• an Addresse 0 steht 0xA9 also 10101001. Bei einem 6502 wäre das Load Akku (Rechenwerk) immediate (mit dem folgenden Wert).
• 8bit CPU -> folgender Wert ist auch wieder ein Byte und steht an Adresse 1. Nehmen wir an das steht 0x55
• die CPU list den Wert 0x55 direkt (immediate) von der auf den LDA folgenden Adresse in den Akku
• die CPU "weiß", dass der gesamte Befehl zwei Byte lang war, erhöht den Adresszähler entsprechend und lädt den nächsten Befehl von Addresse 2

das ganze kann man als "6502 Assembler Einzeiler" so schreiben:
LDA #55

oder eben (Addresse - Wert)
0x0000 - 0xA9
0x0001 - 0x55
0x0002 - ... (nächster Befehl)

du kannst also in dem Sinne keine neue Assembler Sprache "erfinden", sondern du musst dir erst eine eigene CPU bauen und je nachdem was du der beibringst, entsteht die zugehörige Assembler Sprache.

am Ende kann die CPU nur diese Maschinen Sprache und ALLES muss darin übersetzt werden, die Frage ist nur wann/wie/wo...

 

[Web-Schecki]

Aber ist das kein Sicherheitsrisiko?

Grundsätzlich ist es das. Aber die Möglichkeiten einer Anwendung innerhalb eines modernen Betriebssystems sind begrenzt. Zugriff auf I/O geht z.B. für normale Benutzeranwendungen nur über System-Calls des Betriebssystems. Ein direkter Hardwarezugriff z.B. auf Festplatte, Netzwerkcontroller oder Tastatur ist nicht möglich.
Bei Sprachen wie Python wird diese Komplexität etwas verborgen, bei C bekommt man es eher mit, weil man in der Regel Standardbibliotheken explizit importieren muss, die z.B. die Ein- und Ausgabe ermöglichen.
Speicherverwaltung ist natürlich auch eine wichtige Aufgabe des Betriebssystems, die eine gewisse Sicherheit bringen. Bei x86 bietet die Hardware Unterstützung für virtuellen Speicher, sodass jedes Programm dieselbe (virtuelle) Speicheradresse benutzen kann, aber tatsächlich liegen die Daten an völlig verschiedenen Stellen im Speicher.
Das Programm wird natürlich letztendlich von dir ausgeführt und hat daher die gleichen Rechte wie alle anderen Programme. Ein geordneter Zugriff auf I/O ist daher grundsätzlich immer möglich, sodass du problemlos alle persönlichen Daten löschen kannst, wenn dein Benutzer die nötigen Rechte (laut Betriebssystem) hat.

Assembler-Code ist einfach nur eine menschenlesbare Darstellung des Maschinen-Codes. Es ist dasselbe Programm, nur anders dargestellt.
Das gilt für höhere Sprachen nicht. Verschiedene Compiler können aus demselben C-Code verschiedene Maschinenprogramme für dieselbe Maschine erzeugen. Ein Compiler kann auch bereits zu einem gewissen Grad optimieren.

 

[KOply]

Vielen Dank euch!

Ich möchte aber natürlich keine eigene Sprache erfinden, es war nur eine theoretische Frage für das Verständnis.

Von euch gelernt habe ich also nun, dass es nicht den einen Compiler gibt, sondern teilweise sogar mehrere für eine Sprache. Verstehe ich es dann richtig, dass es dann Compiler geben kann, welche direkt in Maschinensprache übersetzen und andere noch den Weg über eine Zwischensprache wie C gehen? Und das könnte dann den Grund haben, dass der Entwickler des Compilers eben gerne mit C oder anderen Zwischensprachen arbeitet und/oder sich dadurch andere Vorteile erhofft, womit dann für den Compiler geworben wird.

Und den simplen Weg, dass der Code zum Compiler und dann zur Hardware geht gibt es dann ja nicht. Es wird ja eigentlich immer ein Betriebsystem verwendet, welches diese ganzen Zugriffe dann auch verwaltet und entsprechend leitet, richtig? Also steht das Betriebsystem auch immer in der Kette des Programmcodes, des Compilers/Interpreter und der Maschinensprache.

 

[BeBur]

für normale Benutzeranwendungen nur über System-Calls des Betriebssystems

Wie wird das praktisch umgesetzt? Interpretiert das OS den Assembler Code dann selber noch? Der Compiler kümmert sich doch soweit ich weiß nicht um diese Belange, für ihn ist das OS doch unsichtbar, oder nicht?
Wenn ich z.B. ein Programm schreibe "Lese X Bytes von Adresse Y", dann produziert der Compiler doch den zugehörigen Assembler Code. Und das Betriebsystem prüft dann vor dem Ausführen, ob das erlaubt ist. So würde ich es jedenfalls annehmen.

Verstehe ich es dann richtig, dass es dann Compiler geben kann, welche direkt in Maschinensprache übersetzen und andere noch den Weg über eine Zwischensprache wie C gehen? Und das könnte dann den Grund haben, dass der Entwickler des Compilers eben gerne mit C oder anderen Zwischensprachen arbeitet und/oder sich dadurch andere Vorteile erhofft, womit dann für den Compiler geworben wird.

Der Grund so etwas zu machen ist meines Wissens nach üblicherweise, weil die Compiler in der "Zielsprache" sehr gut sind. Deswegen nutzen viele Sprachen auch LLVM als Backend für ihren Compiler. Die "Zielsprache" ist da aber eben eine "Intermediate Representation". Im Prinzip aber natürlich auch eine Programmiersprache .
Das man dann aber auch wirklich C-Code haben will, das ist eher unüblich. Wenn man wirklich in eine andere Sprache übersetzen will, dann nennt sich das auch Transpiler.

 

[Ham Burger]

LDA #55

Da werden alte Erinnerungen wach. Mein erster selbstgebauter hatte 1k EEProm, 1k "Grafik" und 64k RAM und ne schnelle Z80 (U880) mit sage und schreibe 2Mhz. Da konnte man sich die Maschinenbefehle noch fast alle merken. Ich muß den mal aus dem Keller ausgraben.

 

[Aduasen]

Ich habe es selber nicht ausprobiert, aber allgemein sagt man, dass moderne Compiler im Regelfall deutlich performanteren Assembler-Code generieren als das ein Mensch üblicherweise schafft. Es mag immer mal wieder Fälle geben, wo das nicht so ist. Aber das spielt in der Praxis nur in ganz bestimmten Kontexten überhaupt nur eine Rolle.

Danke, dann hat sich in den letzten Jahrzehnten offensichtlich Einiges geändert.
Ich habe Anfang der 80er Informatik studiert.
Und es war schon ein ordentlicher Unterschied, den selbstgeschriebenen Assembler Code zu sehen und danach das, was ein Compiler so 'hindilettiert' hat.

Daher bin ich der Ansicht, dass man nicht tief genug anfangen kann, das Programmieren wirklich zu lernen, um sich die entsprechende (mathematische) Denke anzugewöhnen.

Ein bisschen off-Topic...
Ich war immer überrascht, wenn neue Kollegen (ausgebildete Entwickler) haarsträubende Fehler zustande gebracht haben, weil sie den Unterschied zwischen gepackten und gezonten Zahlen nicht kannten.

 

[KOply]

Schau dir mal 1.1 und 1.2 hiervon an: Link.

Das war sehr hilfreich und mega interessant! Werde mir die Seite mal noch weiter anschauen.

Habe nun auch verstanden was @Mickey Mouse geschrieben hat. Vorher war mir das zu hoch.

Eine Frage habe ich jedoch: Vor dem Menüpunkt "Vom Maschinencode zum Assembler" wird die hexadezimale Darstellung erwähnt. Ist das nicht aber auch schon bereits ein Teil von der Assemblersprache? Weil mit Hexadezimal kann der Prozessor doch auch nichts anfangen und es war auch nur ein Schritt, um es den Menschen einfacher zu machen. Ergo brauch es doch dafür auch einen Übersetzer, da der Prozessor ja nur Einsen und Nullen versteht. Also eben ein Assembler. Sehe ich das richtig?

Wie wird das praktisch umgesetzt?

Interessiert mich auch!

 

[Mickey Mouse]

Da werden alte Erinnerungen wach.

du wirst lachen, ich habe Ende der 80er an der Uni (TU-BS Elektrotechnik, Fachrichtung Mikroelektronik/Rechnerarchitektur) in einem Praktikum noch ein kleines Programm auf Lochstreifen gestanzt und eingelesen.

man verinnerlicht die Konzepte einfach viel besser, wenn man die Bits selber fühlen kann und den adress counter per Hand weiter stellt.

 

[RalphS]

Nur der Vollständigkeit wegen. Software läuft schon seit Jahrzehnten nicht mehr auf der Hardware.

Da gibt es abstraction layers. Anwendungen sind dieser Tage "nativ" PECOFF - Windows, UEFI, dotNet - ELF -- Unixoide -- und AOUT, auch wenn das auf dem Weg raus ist -- ältere Unixoide.

Das ist erforderlich einfach deswegen, weil sonst Position Independent Code -- also PIC --- und seine Variationen wie PIE und so weiter, bzw unter Windows ALSR und Konsorten überhaupt nicht möglich wären.

Software ist damit nur zweitrangig für eine spezifische Architektur. Zuallererst muß die Softwareplattform bestimmt werden.

Und ja, Windows könnte ELF und Linux/BSD PECOFF wenn das gewollt wäre.

 

[Ham Burger]

Daher bin ich der Ansicht, dass man nicht tief genug anfangen kann, das Programmieren wirklich zu lernen, um sich die entsprechende (mathematische) Denke anzugewöhnen.

Und das Erfolgserlebnis, was ich hatte, wenn der 4 Bit-Ball über den Schirm flitzte und an den Rändern sogar umkehrte, war unbeschreiblich. Da konnte man sogar noch Leseroutinen (Kassette) selber optimieren, hatte 5 x schnellere Latdezeiten, als damals übliche "Standardroutinen". War für mein kleines Hirn recht hilfreich.

Ergänzung (9. März 2022)

man verinnerlicht die Konzepte einfach viel besser, wenn man die Bits selber fühlen kann und den adress counter per Hand weiter stellt.

So habe ich mein EEProm gebrannt. 8 Bits - 8 Schalter. Ein Adresszähler per Taste weiterschalten, Bits einstellen, auf Taste programmieren drücken. Frau komm rein bei Pos. 864 und ich habe vergessen, ob ich schon Adresse erhöht hatte oder nicht. Alles auf Anfang. Ich habe die Bits tatsächlich gefühlt.

 

[KOply]

Hoffe meine Fragen werde nicht übersehen in meinen letzten Posts. Müssen leider erst immer von einem Mod genehmigt werden und werden deshalb verzögert im Verkauf angezeigt.

 

[Web-Schecki]

Wie wird das praktisch umgesetzt? Interpretiert das OS den Assembler Code dann selber noch? Der Compiler kümmert sich doch soweit ich weiß nicht um diese Belange, für ihn ist das OS doch unsichtbar, oder nicht?
Wenn ich z.B. ein Programm schreibe "Lese X Bytes von Adresse Y", dann produziert der Compiler doch den zugehörigen Assembler Code. Und das Betriebsystem prüft dann vor dem Ausführen, ob das erlaubt ist. So würde ich es jedenfalls annehmen.

Vor dem Ausführen prüft das Betriebssystem höchstens, ob die Datei ausgeführt werden darf. Der Code wird niemals analysiert, das wäre viel zu kompliziert.
"Lese X Bytes von Adresse Y" ist keine Anweisung, die das Betriebssystem interessiert. Wie gesagt gibt es heutzutage Paging, und jedes Programm darf den eigenen, virtuellen Speicher frei benutzen.

System Calls funktionieren in der Regel über Software-Interrupts. Das sind spezielle Maschinenbefehle, die die Ausführung des Programms unterbrechen und dem Betriebssystem signalisieren, dass das Programm einen Software-Interrupt gesendet hat.
Das Betriebssystem liest dann die aktuellen Register und erfährt dadurch, welcher System Call aufgerufen wurde und was zutun ist.
Die Implementierung übernimmt die verwendete C-Bibliothek. Unter Linux-basierten Systemen ist das oft glibc.

 

[BeBur]

Daher bin ich der Ansicht, dass man nicht tief genug anfangen kann, das Programmieren wirklich zu lernen

gezonten Zahlen

Davon habe ich noch nie zuvor gehört ^_^.

Vor dem Menüpunkt "Vom Maschinencode zum Assembler" wird die hexadezimale Darstellung erwähnt. Ist das nicht aber auch schon bereits ein Teil von der Assemblersprache?

Die Hexadezimale Darstellung ist genau das: Eine (andere) Darstellung. Das sind schlicht 1:1 die Bits, aber eben für den Menschen etwas kompakter im Hexadezimalsystem dargestellt. Binär ist letztendlich ja nur ein Zahlensystem mit zwei Symbolen. Das kann man sehr schön stattdessen in einem Zahlensystem mit 16 Symbolen anzeigen.

Da gibt es abstraction layers. Anwendungen sind dieser Tage "nativ" PECOFF - Windows, UEFI, dotNet - ELF -- Unixoide -- und AOUT, auch wenn das auf dem Weg raus ist -- ältere Unixoide.

2/3 deines Beitrages habe ich nicht verstanden. Du kennst nicht zufällig einen guten Artikel zu dem Thema?

"Lese X Bytes von Adresse Y" ist keine Anweisung, die das Betriebssystem interessiert. Wie gesagt gibt es heutzutage Paging, und jedes Programm darf den eigenen, virtuellen Speicher frei benutzen.

Ok, das sehe ich ein. D.h. die Trennung von Speicher erledigt vollständig die CPU heutzutage? Das OS wird aber der CPU ja zumindest irgendwie mitteilen müssen, welche Befehle von welchem Prozess bzw. welcher Anwendung kommen.

Aber ein anderes Beispiel. Wie ist das, wenn ich im Betriebsystem die Priorität eines Prozesses verändere? Da hast du ja folgendes geschrieben:

System Calls funktionieren in der Regel über Software-Interrupts. Das sind spezielle Maschinenbefehle, die die Ausführung des Programms unterbrechen und dem Betriebssystem signalisieren, dass das Programm einen Software-Interrupt gesendet hat.
Das Betriebssystem liest dann die aktuellen Register und erfährt dadurch, welcher System Call aufgerufen wurde und was zutun ist.

Wobei die Priorisierung vermutlich auch direkt von der CPU gemacht wird.
Aber so generell, die CPU sendet (irgendwie) ein Signal an das OS. Und die CPU hat eine Liste mit aktiven Prozessen. Das OS kann diese Liste den verschiedenen Anwendungen zuordnen. Ist das vom Grundverständnis her korrekt?
Woher weiß die CPU denn, von welchem Prozess es gerade OP Codes erhält?

 

[Incanus]

Eine Frage habe ich jedoch: Vor dem Menüpunkt "Vom Maschinencode zum Assembler" wird die hexadezimale Darstellung erwähnt. Ist das nicht aber auch schon bereits ein Teil von der Assemblersprache? Weil mit Hexadezimal kann der Prozessor doch auch nichts anfangen und es war auch nur ein Schritt, um es den Menschen einfacher zu machen. Ergo brauch es doch dafür auch einen Übersetzer, da der Prozessor ja nur Einsen und Nullen versteht. Also eben ein Assembler. Sehe ich das richtig?

Das ist einfach nur eine andere Zahlendarstellung, keine andere Sprache.
100100 binär = 24 hex = 36 dezimal. Alles die gleichen Zahlen.

 

[KOply]

Eine (andere) Darstellung

Das ist einfach nur eine andere Zahlendarstellung

Natürlich, das habe ich ja verstanden. Meine Frage war aber, ob es nicht auch Teil einer Assemblersprache ist. Denn der Computer kann diese Zahlendarstellung doch gar nicht verstehen? Es muss doch dann übersetzt werden, also über einen Assembler. Oder nicht?