nicht angemeldet
Was genau bedeutet "compilieren"?
Hallo!
Ich lese andauernd was von "compilieren", "compilierte Version"... Meist in Zusammenhang mit C#. Was bedeutet das genau?
Ich weiß, sehr dummer Frage, finde aber irgendwie keine Antwort!
Vielen Dank!
Grüsse
Andreas
-
Moin!
Ich lese andauernd was von "compilieren", "compilierte Version"... Meist in Zusammenhang mit C#. Was bedeutet das genau?
Ich weiß, sehr dummer Frage, finde aber irgendwie keine Antwort!Compiliertes "Etwas" wird von einem Compiler hergestellt. Das ist ein Programm, welches einen Programmquelltext (lesbaren Text) in eine Form umsetzt, die der Rechner schnell ausführen kann, die dafür aber kein Mensch mehr lesen kann - jedenfalls nicht so ohne weiteres (man benötigt dann schon Kenntnisse von dem, was der Compiler so herstellt. Ein Computer kann damit was anfangen, warum nicht grundsätzlich auch ein Mensch...).
"Compiler" - der Name könnte von "compute" (berechnen) und "pile" (stapeln) herrühren. Frei übersetzt: Etwas, was irgendwas berechnet und stapelt, zusammensetzt. In engerem Sinne eben ein Programm, was zum Beispiel andere Programme "berechnet" und "zusammensetzt" aus etlichen grundlegenden Maschinensprachebefehlen.
Compiler müssen sich nicht unbedingt auf Programmiersprachen bzw. das Ergebnis "lauffähiges Programm" beschränken.
- Sven Rautenberg
-
... das hier ist aber auch eine brauchbare Erklärung:
http://www.computerlexikon.com/?w=1&q=146:)
- Sven Rautenberg
-
Hi Sven!
"Compiler" - der Name könnte von "compute" (berechnen) und "pile" (stapeln) herrühren.
Koennte natuerlich auch einfach das zum Verb "compile" zugehoerige Substantiv sein. ;-)
So long
-
-
Hallo!
Ich lese andauernd was von "compilieren", "compilierte Version"... Meist in Zusammenhang mit C#. Was bedeutet das genau?Compilieren == übersetzen
Quellcode (ASCII) in eine für den computer verständliche form (binary... maschinensprache) übersetzen.
mit den quellcode in einer programmiersprache kann kein computer was anfangen, (auch nicht php oder perl, wird auch compiliert, allerdings erst zur laufzeit) deswegen muss es in eine für den computer verständliche form übersetzt werden.
wenn ich hier von computer spreche sollte man auch berücksichtigen das "anständiger" quellcode auf jedem Prozessor übersetzt werden kann (nein nicht intel oder amd, die laufen unter der bezeichnung i386 (bzw i586, i686....) sondern zb. Motorola, ppc, i386, amr,...uva
wenn dir das nicht reicht:
http://www.freenetpages.co.uk/hp/alan.gauld/german/tutwhat.htm
http://www.drd.de/helmich/inf/comp/pdf/comp01.pdflg & n8
Ludwig -
Guten Morgen.
Hallo!
Ich lese andauernd was von "compilieren", "compilierte Version"... Meist in Zusammenhang mit C#. Was bedeutet das genau?
Ich weiß, sehr dummer Frage, finde aber irgendwie keine Antwort!Wieso dumm? Das ist wahrscheinlich sogar eine philosphische Frage.
"Compiler" kommt vermutlich aus dem Englischen (die Lateiner werden sicherlich Einspruch erheben - ich habe aber ausdrücklich nicht "ursprünglich aus dem ... " gesagt), was soviel bedeutet wie "Zusammenstellen" oder "Zusammentragen". Historisch ist die sinngemäße Erklärung "einen Quellcode einer Programmiersprache in eine maschinenelesbare Form übertragen" vermutlich absolut korrekt. Heutzutage würde ich aber etwas vorsichtiger formulieren. Ganz abstrakt handelt es sich meiner Meinung nach um nichts Weiteres als eine Tranformation, eine Überführung von einer "Sprache" (=Informationseinheit) in eine andere*.
Warum?
Wegen der Fakten. Niemand würde ernsthaft behaupten wollen, dass es sich bei Java's Bytecode oder Microsofts .NET-IDL bereits um Maschinencode handelt. Trotzdem wird die Übersetzung der entsprechenden Quelltexte in die zuvor erwähnten Formen als "Kompilierung" bezeichnet (was nicht bedeutet, dass dies formal korrekt ist).
Ich würde sagen, "Kompilierung" heißt entweder, direkte Transformation in Maschinencode, oder Überführung in eine Sprache, die von geeigneten "Interpretern" eingelesen, validiert (= auf syntaktische Korrektheit überprüft), und dann zur Laufzeit in Maschinencode übersetzt wird.Wird also JavaScript kompiliert? Nein - es wird ohne Zwischenschritt interpretiert.
Wird also C oder C++ kompiliert? Ha! - kompiliert wird es immer, die Frage ist jetzt nur, in was. Maschinenencode oder eine Zwischenstufe? Beides ist möglich. Während die Übersetzng in Maschinencode allseits bekannt ist, wirft die zukünftige Möglichkeit einer "Compilation" in IDL-Code der .NET-Plattform eine theoretisch interessante Frage auf. Ist es auf dieser Plattform überhaupt noch entscheidend, in welcher Sprache man programmiert? Soweit mein Verständnis reicht: Nein! U.U. "enden" Quellcodes, die in VisualBasic, C++ oder JScript geschrieben wurden, alle im selben IDL-Code. Das klingt sehr verlockend, ob ein Projektleiter darüber glücklich ist, steht aber auf einem anderen Blatte ... (ganz abgesehen davon, dass _mir_ MS-Initiativen zur Beglückung von Entwicklern und Benutzern höchst suspekt sind).
Warum gibt es dann bei manchen Programmiersprachen diesen Zwischenschritt?
Ich denke, die zugrundeliegende Absicht war/ist die Entkopplung der konkreten Implementierung von der Zielplattform. Die Abbildung des kompilierten "Zwischencodes" auf die konkrete Plattform ist allein Sache des Interpreters. Das hat viele Vorteile (Konzentration auf die "wesentlichen" Programmbestandteile, "Write once, run everywhere" ist kein bloßes Marketing mehr), aber auch Nachteile (Perfomanz, Realisierung plattformspezifischer Features etc.). Die "Compiler" können den Quellcode aber je nach ihrer Implementierung bereits "vor"-optimieren, so dass die Ausführgeschwindigkeit durch den Interpreter minimiert wird. Da es in dieser Hinsicht noch Reserven gibt, und die Prozessorperformance nicht geringer werden dürfte (dafür die Heizungskosten geringer werden), liegt in den interpretierten Sprachen m.E. die Zukunft.Viele Grüße,
Martin-
Appendix:
*: Ließe sich ein solcher Compiler evtl mittes XML und XSLT realisieren?
Die Heizkosten steigen natürlich mit zunehmender Prozessorfrequenz!
-
Moin
Wieso dumm? Das ist wahrscheinlich sogar eine philosphische Frage.
Warum?
Wegen der Fakten. Niemand würde ernsthaft behaupten wollen, dass es sich bei Java's Bytecode oder Microsofts .NET-IDL bereits um Maschinencode handelt. Trotzdem wird die Übersetzung der entsprechenden Quelltexte in die zuvor erwähnten Formen als "Kompilierung" bezeichnet (was nicht bedeutet, dass dies formal korrekt ist).Das wird sogar noch philosophischer als dein harmloser Text vermuten lässt :) Der Java-Bytecode wird nämlich auf einer virtuellen Maschine _ausgeführt_ und nicht interpretiert ist also strenggenommen genauso Maschinencode wie das was die gängigen C-Compiler ausspucken. Das wird noch unterstrichen dadurch, dass es Prozessoren gibt, die eine Java-Maschine in Hardware haben. Da wird also der Bytecode direkt ausgeführt.
--
Henryk Plötz
Grüße aus Berlin-
Hi Henryk,
Das wird sogar noch philosophischer als dein harmloser Text vermuten lässt :) Der Java-Bytecode wird nämlich auf einer virtuellen Maschine _ausgeführt_ und nicht interpretiert ist also strenggenommen genauso Maschinencode wie das was die gängigen C-Compiler ausspucken.
Die VM _ist_ ein Interpreter! Sie interpretiert ByteCode http://java.sun.com/docs/books/vmspec/2nd-edition/html/Introduction.doc.html#3087
Das wird noch unterstrichen dadurch, dass es Prozessoren gibt, die eine Java-Maschine in Hardware haben. Da wird also der Bytecode direkt ausgeführt.
Nichts spricht gegen einen in Hardware implementierten Interpreter.
Viel Grüße,
Martin-
Moin!
Die VM _ist_ ein Interpreter! Sie interpretiert ByteCode http://java.sun.com/docs/books/vmspec/2nd-edition/html/Introduction.doc.html#3087
Das muß aber nicht unbedingt so sein. Eine VM (bzw. das, was Java ausführt), könnte den Bytecode nochmals kompilieren und auf die Plattform umsetzen. Dadurch könnte das Programm schneller werden.
Das wird noch unterstrichen dadurch, dass es Prozessoren gibt, die eine Java-Maschine in Hardware haben. Da wird also der Bytecode direkt ausgeführt.
Nichts spricht gegen einen in Hardware implementierten Interpreter.Genau, so wie die (späteren) ix86-Prozessoren welche sind. :) Interpretieren Bytecode. Manchmal sogar (Pentium FDIV-Bug) sogar recht frei. ;)
- Sven Rautenberg
-
hi!
Das wird sogar noch philosophischer als dein harmloser Text
vermuten lässt :) Der Java-Bytecode wird nämlich auf einer
virtuellen Maschine _ausgeführt_ und nicht interpretiert ist also
strenggenommen genauso Maschinencode wie das was die gängigen C-
Compiler ausspucken.
Die VM _ist_ ein Interpreter! Sie interpretiert ByteCodeWenn die virtuelle _Maschine_ ihren eigenen Bytecode interpretiert,
ist das dann kein Maschinencode?Das wird noch unterstrichen dadurch, dass es Prozessoren gibt,
die eine Java-Maschine in Hardware haben. Da wird also der
Bytecode direkt ausgeführt.
Nichts spricht gegen einen in Hardware implementierten Interpreter.Was ist dann deiner Meinung nach der unterschied zwischen "einem in
Hardware implementierten Interpreter" und einer normalen CPU, die
Maschinencode ausführt (wie zb. x86)?bye, Frank!
-
Hi Frank und Sven,
Das wird sogar noch philosophischer als dein harmloser Text
vermuten lässt :) Der Java-Bytecode wird nämlich auf einer
virtuellen Maschine _ausgeführt_ und nicht interpretiert ist also
strenggenommen genauso Maschinencode wie das was die gängigen C-
Compiler ausspucken.Ich verstand das so: die VM interpretiert den ByteCode zur Laufzeit und gibt dabei Maschinencode aus.
Wenn die virtuelle _Maschine_ ihren eigenen Bytecode interpretiert,
ist das dann kein Maschinencode?Was meinst Du mit "eigenen Bytecode"?
Nichts spricht gegen einen in Hardware implementierten Interpreter.
Was ist dann deiner Meinung nach der unterschied zwischen "einem in
Hardware implementierten Interpreter" und einer normalen CPU, die
Maschinencode ausführt (wie zb. x86)?Die Anzahl der Indirektionen bzw. die "Position" in der Kaskade.
VM: Quellcode -> Bytecode -> VM -> Machinencode -> Prozessor -> Microcode -> Recheneinheiten
Liege ich da jetzt falsch?
Viel Grüße,
Martinbye, Frank!
-
Hi zusammen,
Ich verstand das so: die VM interpretiert den ByteCode zur Laufzeit
Ja.
und gibt dabei Maschinencode aus.
Nein. Wohin denn?
Wenn die virtuelle _Maschine_ ihren eigenen Bytecode interpretiert,
ist das dann kein Maschinencode?
Was meinst Du mit "eigenen Bytecode"?Denjenigen, den sie selbst verarbeitet.
Auch eine "reale CPU" ist letzten Endes nichts anderes als eine "Virtuelle Maschine", die in Microcode programmiert ist; ein Addierwerk ist ein Interpreter für Eingabesignale usw.
Nichts spricht gegen einen in Hardware implementierten Interpreter.
Was ist dann deiner Meinung nach der unterschied zwischen "einem in
Hardware implementierten Interpreter" und einer normalen CPU, die
Maschinencode ausführt (wie zb. x86)?
Die Anzahl der Indirektionen bzw. die "Position" in der Kaskade.Ja. Aber das ist kein qualitativer Unterschied, nur ein quantitativer.
Der qualitative Unterschied wäre für mich, ob ein Automat, der als Eingabe ein Programm erhält, als Ausgabe ein anderes Programm liefert oder aber die Ergebnisse des Eingabeprogramms.
Ersteres wäre für mich ein Compiler, letzteres ein Interpreter.
Die Zahl der Umwandlungsschritte halte ich für irrelevant in diesem Kontext, weil sie vom verwendeten Axiomensystem abhängt, d. h. davon, was Du als "elementaren Interpreter" ansiehst. Und das ist ggf. Ansichtssache, weil der Begriff "Eingabe" irgendwo im elektrischen Bereich unscharf zu werden beginnt.VM: Quellcode -> Bytecode -> VM -> Machinencode -> Prozessor -> Microcode -> Recheneinheiten
Liege ich da jetzt falsch?Die VM _ist_ der Maschinencode, der vom Prozessor verarbeitet wird.
Würde sie solchen aus Bytecode erzeugen, also ein Programm ausgeben, dann würde ich sie selbst als Compiler bezeichnen ... da sie es nicht tut, stelle ich sie einer CPU gleich und nenne beide Interpreter.Viele Grüße
Michael-
Willkommen in dieser interessanten Runde,
Hi zusammen,
und gibt dabei Maschinencode aus.
Nein. Wohin denn?Das ist _die_ Frage, die mir zum Verständnis fehlte.
Sich der Existenz von just-in-time _Compilern_ nochmal explizit bewusst zu werden, hätte mir darüberhinaus bei der Erkenntnissuche auch nicht zum Nachteil gereicht. ;-)
Auch eine "reale CPU" ist letzten Endes nichts anderes als eine "Virtuelle Maschine", die in Microcode programmiert ist; ein Addierwerk ist ein Interpreter für Eingabesignale usw.
So verstehe ich das auch.
Die Anzahl der Indirektionen bzw. die "Position" in der Kaskade.
Ja. Aber das ist kein qualitativer Unterschied, nur ein quantitativer.Der qualitative Unterschied wäre für mich, ob ein Automat, der als Eingabe ein Programm erhält, als Ausgabe ein anderes Programm liefert oder aber die Ergebnisse des Eingabeprogramms.
Ersteres wäre für mich ein Compiler, letzteres ein Interpreter.Verständliche und elegante Definition (wobei Du mit "Programm" in diesem Fall eine syntaktische Einheit meinst?). Schreibst Du zufälligerweise Bücher? Wenn ja, bei welchem Verlag sind sie erhältlich?
Die VM _ist_ der Maschinencode, der vom Prozessor verarbeitet wird.
Würde sie solchen aus Bytecode erzeugen, also ein Programm ausgeben, dann würde ich sie selbst als Compiler bezeichnen ... da sie es nicht tut, stelle ich sie einer CPU gleich und nenne beide Interpreter.Versuch einer korrekten Zusammenfassung:
Ein Compiler ist ein Programm, welches durch eine Kaskade endlich vieler Interpreter interpretiert wird und dadurch aus Programmieranweisungen Programme erzeugt.Viele Grüße,
Martin-
Hi auch,
Schreibst Du zufälligerweise Bücher?
Nein, bisher hat es nur zu Feature-Artikeln gereicht. ;-)
Wenn ja, bei welchem Verlag sind sie erhältlich?
Abgesehen von obigen kann ich Dich gerne auf eine Runde UNITED-FORUM
einladen. (http://www.schroepl.net/projekte/united_forum/ 8-]]])Hinterlistige Grüße
Michael
-
-
Hi,
Auch eine "reale CPU" ist letzten Endes nichts anderes als eine "Virtuelle Maschine", die in Microcode programmiert ist; ein Addierwerk ist ein Interpreter für Eingabesignale usw.
Das ist jetzt aber ziemlich philosophisch;)
Ich würde einen Steuerungscode für real existierende Einheiten nicht virtuell nennen und Eingabesignale werden auch nicht interpretiert. Das weißt Du natürlch, ich wollte das nur noch einmal unterstreichen.Grüße
micha
-
-
-
-
-
-
-
Da soll sich noch einer über arrogante Antworten aufregen!
Das hier ist das Beispiel, dass man auch auf "einfache" Fragen vernünftige Antworten kriegt. Auch beim Fragen macht eben der Ton die Musik.Peter
Hallo!
Ich lese andauernd was von "compilieren", "compilierte Version"... Meist in Zusammenhang mit C#. Was bedeutet das genau?
Ich weiß, sehr dummer Frage, finde aber irgendwie keine Antwort!
Vielen Dank!
Grüsse
Andreas -
Hallo!
Zunächst einmal vielen Dank für die vielen hilfreichen Antworten! Ich glaube ich bin jetzt wieder mal ein bisschen schlauer ;-)Ich darf einmal kurz zusammenfassen, wie ich das jetzt verstehe:
Vorab eben noch die Frage - was ist IDL-Code?Also wie ich das alles jetzt verstehe, bedeutet Kompilieren die Übersetzung eines in Ascii Code vom Programmierer geschriebenen Quellcodes, entweder in direkt maschinenlesbaren Code, oder eine Zwischenstufe, die erst beim Ausführen jedesmal interpretiert werden.
Ja da war noch die Optimierung..., aber mir geht es erstmal ums Grundsätzliche. Aber Unix und Windows laufen doch z.B. auf denselben "maschinden", aber die verstehen doch nicht denselben Quellcode?! Das OS muß da doch auch irgendwas mit zu tun haben. Und bei dieser Zwischenstufe, die kann auf mehrern OS installiert werden, und wird jeweils unterschiedlich interpretiert, oder nur auf verschiedene Maschienen bezogen?
Also C, C++, C# und Java werden alle mehr oder wenig konsequent(nenn ich das jetzt mal) kompiliert, und ggfs beim ausführen noch interpretiert. PHP und PERL dagegen werden nicht kompiliert, sondern beim ausführen interpretiert(hatte auch mal was gehört das der PERL Interpreter jedesmal neu geladen werden muß, und bei PHP als Modul der Interpreter die ganze Zeit geladen ist, oder so ähnlich:-).
Nur für mein Verständnis, es gibt ja von vielen Programmen(z.B. PHP) immer den Sourcecode, ist der für alle Maschinen und OS gleich? Also kann das wenn man will jeder durch seinen entsprechenden Compilier laufen lassen, und alle habe aus demselben Code eine andere maschinen/os-Spezifisches Programm? Die Binary-Distributions gibt es ja auch für alle OS einzelnd.
Und noch eine Frage zum Schluß, Javascript und html - die werden vom Browser einfach nur interpretiert, d.h. an dieser Stelle in Bytecode übbersetzt, den die Maschine versteht?Viele Grüße und nochmal vielen Dank für die zahlreichen Antworten!
Andreas
-
Moin
Ja da war noch die Optimierung..., aber mir geht es erstmal ums Grundsätzliche. Aber Unix und Windows laufen doch z.B. auf denselben "maschinden", aber die verstehen doch nicht denselben Quellcode?! Das OS muß da doch auch irgendwas mit zu tun haben. Und bei dieser Zwischenstufe, die kann auf mehrern OS installiert werden, und wird jeweils unterschiedlich interpretiert, oder nur auf verschiedene Maschienen bezogen?
Jein. Die Maschinen sind die selben, und der Code der letztendlich auf der Maschine ausgeführt wird ist der selbe. Aber da gibt es noch kleine aber wichtige Unterschiede. Zunächst mal sind die Binärdateiformate nicht kompatibel. Das Betriebssystem kann ja, wenn du die Datei ausführst, sie nicht einfach aufmachen und alles was da kommt an den Prozessor schicken (naja, bei .com-Dateien unter DOS lief das glaub ich so ähnlich). Stattdessen enthält die Datei Zusatzinformationen: Was für Bibliotheken gebraucht werden, an welche Stellen im Speicher die einzelnen Bereiche der Datei geladen werden sollen, die Hauptfunktion an die das Betriebssytem einspringen soll um das Programm zu starten, etc. Da geht schonmal das reine rüberkopieren der Binary-Dateien nicht.
Beim Compilieren fallen aber als Zwischenschritt Objektdateien an, die später zusammengelinkt werden und erst dabei kommt die endgültige Binary raus. Die Objektdateien müssten also theoretisch von Betriebssystem zu Betriebssystem kompatibel sein. Pustekuchen! Da gibt es nämlich noch mehr Unterschiede, vor allem bei den verwendeten Bibliotheken und Systemaufrufen. Ein gängiges Programm kann ja nicht einfach so im luftleeren Raum agieren, sondern benutzt in der Regel Hilfsbibliotheken mit nützlichen Funktionen (zum Beispiel die C Standardbibliothek) und muss ab und zu auch mal das Betriebssystem direkt, mit sogenannten Betriebssystemaufrufen, ansprechen etwa um eine Datei zu öffnen, einen Prozess zu starten oder (bei Windows) ein Fenster zu malen, etc. Auch diese Ebene ist also nicht kompatibel.Nur für mein Verständnis, es gibt ja von vielen Programmen(z.B. PHP) immer den Sourcecode, ist der für alle Maschinen und OS gleich? Also kann das wenn man will jeder durch seinen entsprechenden Compilier laufen lassen, und alle habe aus demselben Code eine andere maschinen/os-Spezifisches Programm? Die Binary-Distributions gibt es ja auch für alle OS einzelnd.
Bleibt der ursprüngliche Quellcode, zum Beispiel in C. Der ist 'weitgehend' kompatibel. Ein einfaches C-Programm müsste relativ problemlos unter den verschiedensten Betriebssystemen kompilierbar sein. Sobald es aber Betriebssystemspezifische Sachen benutzen möchte, wird es wieder komplizierter, und das nonplusultra sind dann die grafischen Benutzeroberflächen. Bei letzterem helfen einige Toolkits wenigstens weiter, wie etwa qt oder gtk.
Und noch eine Frage zum Schluß, Javascript und html - die werden vom Browser einfach nur interpretiert, d.h. an dieser Stelle in Bytecode übbersetzt, den die Maschine versteht?
HTML ist _keine_ Programmiersprache :), fällt also bei dieser Betrachtung weitestgehend raus. JavaScript wird dann wohl ähnlich wie etwa PHP interpretiert
--
Henryk Plötz
Grüße aus Berlin -
Hallo,
Ich darf einmal kurz zusammenfassen, wie ich das jetzt verstehe:
Vorab eben noch die Frage - was ist IDL-Code?IDL bedeutet Interface Description Language. Es werden hier, grob ausgedrückt, über definierte Schnittstellen Schnittstellen für den Zugriff auf Objekten definiert. Klingt etwas verwirrent ist aber eine logische Konzequenz, welche auf der Tatsache beruht, dass zwar Sprachen wie C oder C++ definiert sind, jedoch ihr binäres Layout bzw. die Umsetzung der Sprachen in ein binäres Layout den Compiler-Herstellern überlassen wurde. Das schöne an der ganzen Sache ist also, dass man nicht wissen muß womit die Programme compiliert wurden oder auf welchem System sie laufen, da es eine definierte Schnittstelle zur Kommunikation gibt. Das alles ist jetzt recht kurz und unzureichend zusammengefaßt aber dieses Thema ist einfach zu groß. Bleibt nur noch zu sagen, dass Programme dahingehend ausgelegt werden müssen. Unter VC++ kann dies z.B. mittels der ATL bewerkstelligt werden....
tom
-
Hallo,
Kleine Korrekturen :
Es werden hier, grob ausgedrückt, über definierte Schnittstellen Schnittstellen für den Zugriff auf Objekten definiert.
Über spezifizierte, einheitliche Schnittstellen werden Schnittstellen zu Objekten offengelegt ist besser.
dass zwar Sprachen wie C oder C++ definiert sind ...
Auch diese sind spezifiziert, sprich klar festgelegt wohingegen es für das binäre Layout keine Spezifikation gibt.
Und wenn ich jetzt meinen Text noch einmal durchlese, dann fange ich bestimmt wieder an mit dem korrigieren;)
tom
-
-
Hallo,
Aber Unix und Windows laufen doch z.B. auf denselben "maschinden", >>aber die verstehen doch nicht denselben Quellcode?! Das OS muß da >>doch auch irgendwas mit zu tun haben.
Das ist Richtig, denn das OS stellt, kurz gesagt, die Funktionen für die Ein und Ausgabe zur Verfügung. dazu gehört das Dateisystem und die meist graphische Benutzeroberfläche. Diese Funktionen Unterscheiden sich von System zu System. Der Zugriff auf diese Funktionen gestaltet sich (auf jeden fall auf der Mashienensprachen Ebene) von System zu System unterschiedlich z.B. beim "guten" alten DOS über den Software Interupt 21h als Hauptkomponente für die Ein und Ausgabe.
Die einzelnen Programme führen nur ihre Algoritmen aus die, Vorrausgesetzt das OS tritt nicht als Virtuelle Maschiene auf, im Prinzip (abgesehen davon das man eventuell auf das Scheduling des einzelenen OS eingehen muss ...) auf der Ebende der Maschienensprache gleichkompeliert werden müssten. Die Ein und Ausgabe erledigt dann Das Betriebsystem denn das ist eine der Hauptaufgeaben eines OS.
Und bei dieser Zwischenstufe, die kann auf mehrern OS installiert >>werden, und wird jeweils unterschiedlich interpretiert, oder nur >>auf verschiedene Maschienen bezogen?
Das ist soweit richtig denn diese Zwischenstufe die Du meinst (wenn wir uns richtig verstehen) ist nichts anderes als ein Virtueller Maschienencode, der von einer Software interpretiert wird, die für das Betriebsystem und die Maschiene (s.o.) kompeliert wurde.
solche Software nennt man auch Virtuelle Maschiene.Somit ist dieses Programm auf jedem System Lauffähig für das eine solche Software installiert wurde.
Also C, C++, C# und Java werden alle mehr oder wenig konsequent(nenn ich das jetzt mal) kompiliert, und ggfs beim ausführen noch interpretiert. PHP und PERL dagegen werden nicht kompiliert, sondern beim ausführen interpretiert(hatte auch mal was gehört das der PERL Interpreter jedesmal neu geladen werden muß, und bei PHP als Modul der Interpreter die ganze Zeit geladen ist, oder so ähnlich:-).
Nur für mein Verständnis, es gibt ja von vielen Programmen(z.B. PHP) immer den Sourcecode, ist der für alle Maschinen und OS gleich? Also kann das wenn man will jeder durch seinen entsprechenden Compilier laufen lassen, und alle habe aus demselben Code eine andere maschinen/os-Spezifisches Programm? Die Binary-Distributions gibt es ja auch für alle OS einzelnd.
Und noch eine Frage zum Schluß, Javascript und html - die werden vom Browser einfach nur interpretiert, d.h. an dieser Stelle in Bytecode übbersetzt, den die Maschine versteht?Viele Grüße und nochmal vielen Dank für die zahlreichen Antworten!
Andreas
-