Hallo zusammen,
es geht mir darum wo der Compiler bzw. der Interpreter hinterlegt ist bzw. sind. Sprich in der jeweiligen Entwicklungsumgebung der jeweiligen Sprache?
Und wenn das Programm dann auf einer anderen Plattform laufen soll, muss dann zusätzlich ein Interpreter bzw. Compiler installiert werden?
Für Java Programme wird ja Java Runtime benötigt. Aber wie sieht es mit C++ Programmen aus oder bei Java Script.
Vielen Dank.
Grüsse Neo
Hi,
die Frage ist etwas verworren wenn ich das einmal so sagen darf.
Für die Antwort ist erst einmal wichtig, es gibt kompilierte und interpretierte Sprachen.
interpretierte Sprachen oder auch Interpretersprachen
JavaScript, Python und PHP, um drei Beispiele zu nennen, sind interpretierte Sprachen. Um diese Sprachen auszuführen brauchst du immer einen Interpreter der den Code versteht. JavaScript kann so ziemlich jeder Webbrowser, für Python gibt es Implementierungen in vielen verschiedenen Sprachen und für PHP gibt es Webserver.
Nachteil: Sie sind relativ langsam.
Vorteil: Sie laufen auf jedem System für das es einen Interpreter gibt.
kompilierte Sprachen
C++, C# und Java sind kompilierte Sprachen, diese Sprachen werden in Bytecode oder Maschinencode übersetzt. Das heißt, der Code liegt nicht mehr an sich vor wie bei einer Interpretersprache sondern wurde in einen, für den PC, verständlichen Code übersetzt.
Einen Unterschied den es noch bei kompilierten Sprachen gibt, ist der Punkt mit Byte- und Maschinencode.
Maschinencode
Maschinencode ist immer nur auf einem Systemtyp lauffähig, wenn du ein C++ Programm für Windows kompilierst wirst du es, auf Teufel komm raus, nicht unter Linux zum Laufen bekommen.
Nachteil: Sie müssen für jedes System neu kompiliert werden.
Vorteil: Sie sind sehr schnell.
Bytecode
Bytecode ist auf jedem System lauffähig, für das eine Runtime existiert. Beispiele wären da die Java Virtual Maschine(JVM) oder das .net Framework bzw. Mono. Alle Programme die du mit Java schreibst und kompilierst sind auf jeder Maschine, egal welches System lauffähig, vorausgesetzt, die JVM ist auf der Maschine installiert. Gleiches gilt für .net und Mono.
Bytecode ist so ein Mittelding aus Maschinencode und interpretiertem Code, er ist relativ schnell und auf vielen Systemen lauffähig.
Ich hoffe das war verständlich, wenn nicht frag nach 
Lg Knerd
PS: An die anderen Wissenden, wenn ich Bullshit geschrieben hab wäre eine Verbesserung ganz cool
Moin,
die andere Antwort war schon ziemlich gut, aber ein bisschen kann man noch hinzufügen/korrigieren.
es geht mir darum wo der Compiler bzw. der Interpreter
hinterlegt ist
Ein Compiler und ein Interpreter sind beides Programme, wie andere Programme auch und sie müssen in den meisten Betriebssystemen ganz normal installiert werden. Wenn man eine komplette Entwicklungsumgebung installiert, sind Compiler und/oder Interpreter meist dabei, die werden aber als einzelne Programme mit installiert.
„Hinterlegt“ sind sie also in dem Verzeichnis, wo sie installiert wurden.
Und wenn das Programm dann auf einer anderen Plattform laufen
soll, muss dann zusätzlich ein Interpreter bzw. Compiler
installiert werden?
Da gibt es zweierlei. Wchtig ist hier der Unterschied zwischen Compiler und Interpreter. Der Compiler übersetzt ein Programm vor der Laufzeit in Maschinencode (s. anderes Posting). Damit ist das fertig compilierte Programm NUR auf dem Betriebssystem lauffähig, unter dem es compiliert wurde. Ein unter Windows compiliertes Programm läuft nicht unter Linux. Ein Compiler muss nur da installiert sein, wo das Programm übersetzt wird.
Der Interpreter übersetzt ein Programm erst zur Laufzeit in Maschinencode. Ein Programm, das in einer Interpreter-Sprache geschrieben ist, ist auf allen Betriebssystemen lauffähig, für die es den Interpreter gibt. Der Interpreter muss allerdings überall da installiert sein, wo das Programm laufen soll.
Für Java Programme wird ja Java Runtime benötigt.
Java ist so ein Zwischending. Java ist sowohl Compiler als auch Interpreter. Java-Programm müssen erst compiliert werden in einen Bytecode, der dann vom Java-Interpreter gelesen wird. Das ist ein Grund für die Beliebtheit von Java, man entwickelt in einer Hochsprache, die C++ sehr ähnlich ist, erstellt aber Programme, die mit der JRE auf allen Betriebssystemen lauffähig ist.
Aber wie
sieht es mit C++ Programmen aus oder bei Java Script.
C++ wird compiliert für ein Betriebssystem.
JavaScript ist eine Scriptsprache, was fast immer auf einen Interpreter hinweist. Der steckt im Browser (oder im Server für serverseitiges JS).
Compilierte Programme sind in der Regel schneller als interpretierte.
Liebe Grüße,
-Efchen
Hallo :-Efchen,
die andere Antwort war schon ziemlich gut, aber ein bisschen
kann man noch hinzufügen/korrigieren.
So gehts mir auch gerade 
Der Compiler übersetzt ein Programm
vor der Laufzeit in Maschinencode (s. anderes Posting). Damit
ist das fertig compilierte Programm NUR auf dem Betriebssystem
lauffähig, unter dem es compiliert wurde. Ein unter Windows
compiliertes Programm läuft nicht unter Linux. Ein Compiler
muss nur da installiert sein, wo das Programm übersetzt wird.
Dies stimmt so nicht!
Ein Compiler funktioniert immer nur unter einem bestimmten Betriebssystem und erzeugt Code für eine bestimmte CPU, bzw. je nach Sprache für ein bestimmts Betriebssystem.
Dabei müssen das Betiebssystem, welches zur Entwicklung benutzt wird, und das Zielsystem nicht identisch sein --> Cross-Compiler.
MfG Peter(TOO)
Hallo Knerd,
Bytecode
Bytecode ist auf jedem System lauffähig, für das eine Runtime
existiert. Beispiele wären da die Java Virtual Maschine(JVM)
oder das .net Framework bzw. Mono.
Das Konzept wurde früher P-Code genannt.
UCSD-Pascal, das war ein Betriebssystem und eine Srache, lag, fast gänzlich, als P-Code vor.
Die ersten VB-Compiler konnten nur P-Code erzeugen. Erst bei den späteren Versionen hatte man dann die Wahl zwischen P-Code oder Maschinensprache.
FORTH, mit seinem Fädelcode ist so ein Zwischending zwischen P-Code und Maschinensprache.
Die meisten BASIC-Intrpreter waren eigentlich Compreter oder Interpiler. Die Schlüsselwörter wurden direkt bei der Eingabe in Tokens übersetzt. Ein Token war meistens ein Byte im Wertbreich von 0x80-0xFF und lag somit ausserhalb des vewendeten 7-Bit ACII-Codes.
MfG Peter(TOO)
moin moin ,
Beispiel :
Für ein Tablett z.b. Android etwas erstellen.
Das kann natürlich über mehrere Wege gehen .
Windows selber kann es aber nicht,
sondern eher die Entwicklungsumgebung IDE die
quasi das Zielbetriebsystem beinhaltet .
Es wird also irgendwie immer noch für nur 1 zielsystem compiliert
und nicht ein compilat für alle zielsysteme
oder seh ich das falsch .
Hallo ragewrm,
Für ein Tablett z.b. Android etwas erstellen.
Das kann natürlich über mehrere Wege gehen .
Windows selber kann es aber nicht,
sondern eher die Entwicklungsumgebung IDE die
quasi das Zielbetriebsystem beinhaltet .
Es wird also irgendwie immer noch für nur 1 zielsystem
compiliert
und nicht ein compilat für alle zielsysteme
Habe ich etwas anderes geschrieben?
Zudem darf man die IDE nicht mit dem Compiler verwechseln.
MfG Peter(TOO)
Moin,
Ein Compiler funktioniert immer nur unter einem bestimmten
Betriebssystem und erzeugt Code für eine bestimmte CPU
Das kann so ja auch nicht stimmen, wenn „erzeugt für“ bedeutet „ist auch nur da lauffähig“ (so liest sich das zumindest). Denn was für einen Pentium1 compiliert ist, läuft auch auf einem Pentium2 oder was auf einem aktuellen AMD compiliert ist, läuft auch auf einer Intel-CPU.
Dabei müssen das Betiebssystem, welches zur Entwicklung
benutzt wird, und das Zielsystem nicht identisch sein -->
Cross-Compiler.
Du meinst also ich kann unter Windows Programme compilieren, die anstandslos unter Linux (ohne WINE) laufen? Okay, von Cross-Compilern habe ich keine Ahnung, aber die Regel ist das wohl eher nicht!
Liebe Grüße,
-Efchen
Hallo -Efchen,
Ein Compiler funktioniert immer nur unter einem bestimmten
Betriebssystem und erzeugt Code für eine bestimmte CPUDas kann so ja auch nicht stimmen, wenn „erzeugt für“ bedeutet
„ist auch nur da lauffähig“ (so liest sich das zumindest).
Denn was für einen Pentium1 compiliert ist, läuft auch auf
einem Pentium2 oder was auf einem aktuellen AMD compiliert
ist, läuft auch auf einer Intel-CPU.
Es gibt noch ein paar andere CPUs, als nur jene von Intel und AMD, welche man in einem PC findet! Zudem läuft dein Code garantiert nicht auf einen 8080!
Und hast du dir schon einmal überlegt, wie denn nun z.B. Linux überhaupt auf einen ARM gekommen ist?
Und die ganzen Micro-Controller müssen auch irgendwie programmiert werden, wird heute meistens in C gemacht.
Dabei müssen das Betiebssystem, welches zur Entwicklung
benutzt wird, und das Zielsystem nicht identisch sein -->
Cross-Compiler.Du meinst also ich kann unter Windows Programme compilieren,
die anstandslos unter Linux (ohne WINE) laufen? Okay, von
Cross-Compilern habe ich keine Ahnung, aber die Regel ist das
wohl eher nicht!
Das kommt ganz drauf an. In den letzten Jahrzehnten habe ich hauptsächlich Software für Nicht-PCs geschrieben auf PCs geschrieben.
http://de.wikipedia.org/wiki/Cross-Compiler
Vielleicht kennst du GCC
http://de.wikipedia.org/wiki/GNU_Compiler_Collection…
Hier noch kommerzielle Anbieter. Diese Compiler/IDEs laufen hauptsächlich unter Windows:
http://www.keil.com/dd/
http://www.iar.com/en/Products/IAR-Embedded-Workbench/
MfG Peter(TOO)
HAllo -Efchen
Das kann so ja auch nicht stimmen, wenn „erzeugt für“ bedeutet
„ist auch nur da lauffähig“ (so liest sich das zumindest).
Denn was für einen Pentium1 compiliert ist, läuft auch auf
einem Pentium2 oder was auf einem aktuellen AMD compiliert
ist, läuft auch auf einer Intel-CPU.
Hier wird ein spezieller „Trick“ verwendet.
Tatsächlich ist der Befehlssatz dieser Prozessoren etwas unterschiedlich.
Viele heutige CPUs besitzen einen speziellen Interrupt-Vector „Invalid Instruction“, welcher ausgelöst wird, wenn ein unbekannter Maschinen-Befehl erkannt wird. Dann kann man diesen Befehl per Software emulieren.
Die Weiterentwicklung besteht darin, dass es einen speziellen Bereich in der CPU gibt, in welchen Micro-Code geladen werden kann. Damit lassen sich zusätzlich Befehle implementieren und es können damit auch, in der Hardware, fehlerhafte Befehle korrigiert werden.
Deshalb ist es wichtig, dass das BIOS die CPU erkennen und die entsprechenden Korrektur-Tabellen in die CPU laden kann.
Dieser Mechanismus wurde nach dem 80386 eingeführt, wird aber nicht wirklich an die Grosse Glocke gehängt, da die Meldungen über die Fehler des 80386 zu heftigen Kursstürzen an der Börse geführt hatten.
Zitat von Intel:
The microcode data file contains the latest microcode definitions for all Intel processors. Intel releases microcode updates to correct processor behavior as documented in the respective processor specification updates. While the regular approach to getting this microcode update is via a BIOS upgrade, Intel realizes that this can be an administrative hassle. The Linux operating system and VMware ESX products have a mechanism to update the microcode after booting. For example, this file will be used by the operating system mechanism if the file is placed in the /etc/firmware directory of the Linux system.
Eine hübsche Umschreibung für einen Prozessor-Bug
Hier noch eine Liste der Intel und AMD CPUs:
https://wiki.archlinux.org/index.php/Microcode#Which…
Beim x86 gibt es einen zusätzlichen Vektor für Co-Prozessor-Befehle. War z.B. beim 8086 kein 8087 vorhanden, wurden die FP-Opeationen von einem 8087-Emulator verarbeitet. War ein 8087 vorhanden, teilte er dies dem 8087 mit und verarbeitet den Befehl wobei bei diesem Konzept der 8087 nur die Rechenoperationen ausgeführt hat, die Speicher-Adressierung wurde vom 8086 ausgeführt.
MfG Peter(TOO)
Und wenn das Programm dann auf einer anderen Plattform laufen
soll …
Hier machen Anfänger oft den Fehler zu glauben, dass sie ein beliebiges Programm, das sie z.B. für Windows entwickelt haben, auch auf jedem anderen System laufen lassen können auf welchem es Java, C oder C++ gibt.
Uneingeschränkt gültig ist das nur für simple Progrämmchen a la „lies zwei Zahlen und gib die Summe aus“ oder generische Algorithmen wie „bau einen binären Baum auf und sortiere die Knoten“. Im Schulbereich kann der Lehrer seine Beispiele so wählen dass er ausschließlich mit dem Standard-Sprachumfang auskommt.
„Richtige“ Software macht dagegen oft mehr oder weniger exzessiv Gebrauch von externen Schnittstellen und Bibliotheken. So lange man sich auf Bibliotheken beschränken kann, die auf allen ins Auge gefassten Zielplattformen (beachte die Einschränkung - das kann sich sehr schnell ändern wenn etwas Neues am Markt auftaucht und man seine Software „mal schnell“ dahin portieren soll, was ja „kein Problem sein kann“ sobald es Java Unterstützung für die Zielplattform gibt) verfügbar sind, hat man damit kein Problem. Leider kommt man mit den Standards umso weniger zu akzeptablen Ergebnissen, je spezifischer die Ansprüche werden, und für ganz spezielle Anforderungen gibt es möglicherweise überhaupt keine Standardbibliothek, und Du bekommst auch nicht x Jahre zeit Dir mit plattformunabhängigen Standardsprachelementen selber eine zu schreiben. Du wirst dann unter zeit- und kostendruck gezwungen, die Offenheit der Software zu opfern und Dich in Abhängigkeiten zu begeben.
Manche Anbieter (z.B. mal wieder der Paradeböse, Microsoft mit dem .net Framework) locken Entwickler bewusst in solche Ecken (man nennt das „Lock-in“ Effekt erzeugen) indem sie zugegebener Maßen sehr nützliche und komfortable Biblöiothekssammlungen zur Verfügung stellen (.net Framework gehört neuerdings sogar zum Standardlieferumfang von Windows, früher musste man es erst installieren), mit denen man in sehr kurzer Zeit ansehnlich aussehende Programme erstellen kann. Dementsprechend werden einem diese Segnungen auch permanent angedient, indem die Programmiererdokus permanent darauf verweisen. Diese Programme sind - obwohl z.B. in C++ geschrieben - nicht auf einer anderen Plattform lauffähig, weil Microsoft .net nur für Windows liefert.
Außerdem tendieren streng plattformunabhängig programmierte Programme dazu, weil sie die plattformabhängigen „Goodies“ ja vermeiden müssen, bei den Anwendern als „umständlich“, „eigenwillig“ und „hässlich“ kritisiert zu weden, weil sie anders aussehen nund sich anders anfühlen (das berühmte „Look and Feel“) als das was der Anwender gewohnt ist.
Armin.