Ist es möglich bei Visual Studio 2010 ein C# Programm auch für Linux zu kompilieren?
-
@hustbear,
Gut, C#, VB.Net, F#, usw. wird in CIL oder IL übersetzt und danach interpretiert. Das ist für mich aber ein eher unwichtiger Unterschied. Ob CIL oder C#, Java oder Java-Bytecode es ist einfach nur eine andere Form des Gleichen.Vielleicht müsste man auch zuerst mal definieren, was überhaupt eine interpretierte Sprache ausmacht. Ist für dich z.B. Javascript eine interpretierte Sprache? Obwohl heute viele Implementierungen einen JIT verwenden? Oder hängt dies auch mit der Ausführungsumgebung zusammen? Somit könnte auch C# (nicht CIL!) interpretiert sein, da es C# Interpreter gibt
Ich sehe meistens ein Hauptproblem bei solch einer Diskussion. Die Leute wollen "ihre" Sprache nicht als interpretiert abstempeln, weil sie damit etwas langsames verbinden.
Naja, ich will mich hier jetzt nicht ausführlicher äussern, da ich meine Argumente nur schlecht rüber bringen kann. Ich bin ***** müde und schlafe gleich auf der Tastatur ein
Grüssli
-
Dravere schrieb:
@hustbear,
Gut, C#, VB.Net, F#, usw. wird in CIL oder IL übersetzt und danach interpretiert. Das ist für mich aber ein eher unwichtiger Unterschied. Ob CIL oder C#, Java oder Java-Bytecode es ist einfach nur eine andere Form des Gleichen.Also für mich ist das ein wichtiger Unterschied.
Vielleicht müsste man auch zuerst mal definieren, was überhaupt eine interpretierte Sprache ausmacht.
Müsste man wohl.
* Eine Sprache die nur interpretiert und nie (vollständig) native übersetzt werden kann. Schliesst fast alle Sprachen aus.
* Eine Sprache die auch interpretiert werden kann. Schliesst fast alle Sprachen ein.
* Eine Sprache die üblicherweise interpretiert wird. Ist etwas schwammig. Und schliesst IMO C#, Lua etc. aus.
* Eine Sprache die üblicherweise (zumindest teilweise) zur Runtime interpretiert oder geJITed wird.Ich glaube aber dass du was ganz anderes meinst, wo IMO der Begriff "interpretiert" schon gar nicht angebracht ist. Nämlich das Vorhandensein von viel Meta-Infos, und diversen Features die sich mit compilierten Sprachen nur mit Einbindung eines Compilers machen lassen. Wie z.B. das "Ausführen von Strings".
----
Wenns dich morgen noch freut schreib vielleicht mal ganz grob was du dir als Definition vorgestellt hättest.
-
Hallo,
die Unterscheidung zwischen kompiliert und interpretiert ist eigentlich ganz einfach zu machen. Bei der Kompilation wird Maschinencode generiert wird, sprich selber lauffähig, bei der Interpretation wird die Anweisung nicht in Maschinencode umgewandelt, sondern der Interpreter führt die Anweisung aus. Es ist also eine zweite Instanz zur Durchführung der eigentlichen Aktion notwendig.
.Net Code liegt nach der Kompilation durch den "Sprachencompiler" (C#, VB.Net, C++/CLI usw.) als Byte Code (hier CIL) vor, das ist natürlich richtig. Aber dieser Bytecode wird immer! vor der Ausführung in Maschinencode kompiliert durch den JIT Compiler und erst dieser Maschinencode wird direkt ausgeführt. Deshalb ist die Verwendung des Begriffes interpretiert bei .Net völlig falsch, da da nichts interpretiert wird. Die Möglichkeit Bytecode zu interpretieren gibts bei .Net gar nicht.
Bei Java gibts dagegen beides. Bei den ersten Versionen wurde der Java Bytecode interpretiert, aber den JIT Compiler gibts da mittlerweile auch schon ewig und der wird heute defaultmäßig eingesetzt.
Dieser ganze Prozess Prozess bei .Net ist nicht ganz einfach zu sehen für den User, da der Sprachencompiler wie schon gesagt wurde, eine PE Datei (mit der Endung exe) erzeugt die CIL enthält. Der JIT Compiler erzeugt aber keine neue Datei, sondern ersetzt in genau dieser Datei den Bytecode durch entsprechenden, kompilierten Maschinencode und dieser wird dann ausgeführt. Deshalb ist der ganze Prozess auch so undurchsichtig von außen und man könnte auf die Idee kommen das die .Net Runtime direkt den Bytecode verwendet, dem ist aber nicht so. Ob eine Exe jetzt Bytecode oder schon Maschinencode enthält (vielleicht durch ngen schon vorerzeugt),sieht man der Datei ohne tiefere Betrachtung nicht an.
Aber da gibts gute Literatur zu wie z.B. "CLR via C#" von Jeffrey Richter.
Der deutsche Wikibeitrag zu Interpreter ist übrigens falsch. Dort wird geschrieben, dass der JIT Compiler den Code in Maschinencode kompiliert der direkt ausgeführt wird und im nächsten Satz wird gesagt, dass der JIT Compiler ein Interpreter ist
Der englische dagegen erklärts richtig: http://en.wikipedia.org/wiki/Interpreter_(computing).
-
@Zwergli: Guter Beitrag!
-
Kann man ja nachvollziehen.
Wenn man eine .Net Applikation das erste mal auf ein System startet ist es recht langsam, das liegt daran das der IL Code in den AssemblyCache gebaut wird und von dort dann nur noch ausgeführt. Beim nächsten start merkt die Runtime dann das sich der IL nicht geändert hat und der Build noch da ist und startet direkt ohne bau.
Dadurch sind alle nachfolgenden Starts der selben Applikation schneller.
-
Zwergli schrieb:
die Unterscheidung zwischen kompiliert und interpretiert ist eigentlich ganz einfach zu machen. Bei der Kompilation wird Maschinencode generiert wird, sprich selber lauffähig, bei der Interpretation wird die Anweisung nicht in Maschinencode umgewandelt, sondern der Interpreter führt die Anweisung aus.
http://en.wikipedia.org/wiki/Interpreter_(computing).Dem will ich widersprechen. Interpreter können mindestens in zwei Architekturformen vorkommen.
- Code liegt als Datenstruktur vor, der über eine Maschinenform(Stack oder Register) getrieben wird (Abstrakte Maschine)
- Code wird zur Laufzeit in Maschinencode transformiert.
-
Und wo ist jetzt der Widerspruch?
-
David W schrieb:
Und wo ist jetzt der Widerspruch?
Seine Aussage war, dass beim Interpreter nicht ins Maschinenform übersetzt wird.
-
Und was soll man mit deinem Widerspruch jetzt anfangen? Ein Argument wär nicht schlecht.
-
Zeus schrieb:
Interpreter können mindestens in zwei Architekturformen vorkommen
...
Code wird zur Laufzeit in Maschinencode transformiert.Das ist kein Interpreter! Wenn Code von einer Form in eine andere umgesetzt wird, ist das eine Kompilation.
Meine Aussage im vorherigen Beitrag war da vielleicht nicht ganz korrekt:
Bei der Kompilation wird Maschinencode generiert
stimmt so natürlich nicht ganz. Das ist sehr oft der Fall, aber im Prinzip ist die Compilation allgemein nur eine Umsetzung von einer Form in eine andere.
Ich glaube der Grund warum es soviel Missverständnis gibt, sind die verschiedenen Mischformen die auftreten können.
Es gibt ja durchaus Systeme die Code aus der Ursprungssprache erst in eine Zwischenform überführen (das ist eindeutig Compilation) und diese dann interpretieren indem ein Interpreter den Code verarbeitet und die Aktionen ausführt die der Code beschreibt. Sowas gibts z.B. wenn Java Bytecode interpretiert wird. Aber JIT Compiler interpretieren nichts, da sie ja nicht selber den Code ausführen sondern in Maschinensprache übersetzen und die wird dann durch die CPU ausgeführt.
Bei .Net ist im Prinzip einfach der Compiliervorgang in zwei klar zu unterscheidene Stufen unterteilt. Erst Sprachcompiler(z.B: C# -> CIL) und dann JIT Compiler (CIL -> Maschinencode). Bei vielen anderen Sprachen wo der Compiler direkt ausführbaren Code ausspuckt wird auch nichts anderes gemacht. Erst wird die Ursprungssprache in eine Zwischenform gebracht wo dann optimiert wird etc. und dann wird daraus der Maschinencode erstellt. Nur das es dort ein Programm macht, und bei .Net und Java ist das in zwei Teile unterteilt die zu verschiedenen Zeiten stattfinden. Ich weiß beim besten Willen nicht wie man da auf die Idee kommt da wird was interpretiert.
-
http://en.wikipedia.org/wiki/Just-in-time_compilation schrieb:
Interpreted code is translated from a high-level language to a machine code continuously during every execution, whereas statically compiled code is translated into machine code before execution, and only requires this translation once.
Genauso hab ich auch im Compilerbau gelernt, dass ein Interpreter ein Compiler ist mit dem unterschied, dass dein Eingabeprogramm in einem Form vorhanden ist, die vom Prozessor nicht verstanden wird. Die Compilerphase sind die Gleiche. In diesem Sinn ist der C#-Übersetzen ein Compiler ist, und der JIT-Compiler ein Interpreter ist(der Compiler im Name ist durchaus berechtigt, weil er im Kontext von sich selbst ein Compiler ist, aber im Bezug zum Anwendungsstart ein Interpreter ist).
Im diesen Sinn hab ich gerade mein Widerspruch eliminiert.
-
hustbaer schrieb:
Wenns dich morgen noch freut schreib vielleicht mal ganz grob was du dir als Definition vorgestellt hättest.
Wenn es mich noch freut? Ich muss ja wohl fast, weil ich die ganze Diskussion überhaupt ausgelöst habe
Aber zuerst etwas zum bisher geschriebenen. Ich bin mir ziemlich sicher, dass wir hier alle genau wissen, wie ein JIT funktioniert (z.B. unter .Net), und halte es daher für unnötig auf sprachliche Ungenauigkeiten einzugehen. Meiner Meinung nach läuft dies alles nur auf eine andere Sichtweise/Definition hinaus. Die Definition von Zwergli ist meiner Meinung nach somit nicht falsch. Sie ist einfach nur eine andere Betrachtungsweise.
Ich selber sehe den JIT-Compiler als wichtiges Tool in der aktuellen Entwicklungsstufe eines Interpreters an. Ich definiere womöglich für eure Verhältnisse einen Interpreter etwas zu offen. Für mich ist ein Interpreter einfach ein Programm, welches benötigt wird, um ein anderes Programm auszuführen. Programm I interpretiert Programm B und sorgt dafür, dass B ausgeführt wird. Wie diese Ausführung passieren muss, lasse ich bewusst offen. Bei einem Interpreter mit einem JIT, wird halt eine Kompilierung z.B. zu Maschinencode durchgeführt, das Resultat wird gespeichert (daher sprach ich weiter vorne von einem Cache) und ausgeführt. Der JIT ist für mich ein Teil eines Interpreters.
Der JIT-Kompiler ist für mich wirklich nur ein Kompiler. Und ein Kompiler führt nunmal nichts aus, sondern übersetzt nur. Das Ganze um den JIT-Kompiler ist für mich der Interpreter. Und daher sind Java, .Net Sprachen, usw. für mich interpretierte Sprachen, weil sie einen Interpreter benötigen.
Grüssli
-
Hallo,
Zeus schrieb:
http://en.wikipedia.org/wiki/Just-in-time_compilation schrieb:
Interpreted code is translated from a high-level language to a machine code continuously during every execution, whereas statically compiled code is translated into machine code before execution, and only requires this translation once.
..., und der JIT-Compiler ein Interpreter ist(der Compiler im Name ist durchaus berechtigt, weil er im Kontext von sich selbst ein Compiler ist, aber im Bezug zum Anwendungsstart ein Interpreter ist).
Dem zitierten von Wikipedia stimm ich vollkommen zu da es genau meine Argumentation stützt. .Net Code wird einmalig in Maschinencode kompiliert, nicht jedes mal so wie es die zitierte Definition ja von Interpretern verlangt - > Sprich, da ist nichts von wegen Interpretation. Nur weil die endgültige Compilation von Bytecode in Maschinencode praktisch on the fly beim Programmstart durchgeführt wird ist es doch nicht auf einmal eine Interpretation.
Dravere schrieb:
Für mich ist ein Interpreter einfach ein Programm, welches benötigt wird, um ein anderes Programm auszuführen.
Da geh ich mit. Bei interpretiertem Code ist der Interpreter derjenige der den Code ausführt und nicht das Programm selber weils in Maschinencode vorliegt. Nun die Frage - welches Programm führt den .Net Code aus? Gar keins, der Code liegt zur Ausführungszeit nänmlich in Maschinencode vor und wird direkt durch die CPU ausgeführt und nicht durch ein anderes Programm. Daher kann das ganze nicht interpretiert sein, weil einfach kein Programm da ist zum interpretieren.
Ich definiere womöglich für eure Verhältnisse einen Interpreter etwas zu offen
Du definierst sie einfach falsch im Kontext der Softwareentwicklung. Nur weil man umgangssprachlich vielleicht manches freier sieht, heißt das noch lange nicht das es technisch gültig ist. Ist genauso bei dem Thema "Echtzeit". Nur die wenigsten die das Wort hier im Forum verwenden, wissen was das wirklich bedeutet und verwechseln Echtzeit mit Gleichzeitigkeit/Schnelligkeit, dabei gibt es ganz klare technische Definitionen und da ist es egal wenn man selber was anderes meint. Das ist dann falsch.
Du schreibst am Ende kommt bei .Net Maschinencode raus der direkt ausgeführt wird und nimmst irgendwo die Behauptung her da ist nen Interpreter im Spiel. Bei anderen Sprache wie C oder C++ kommt am Ende auch Maschinencode raus, ist das für dich auch interpretiert?
-
Zwergli schrieb:
Hallo,
Zeus schrieb:
http://en.wikipedia.org/wiki/Just-in-time_compilation schrieb:
Interpreted code is translated from a high-level language to a machine code continuously during every execution, whereas statically compiled code is translated into machine code before execution, and only requires this translation once.
..., und der JIT-Compiler ein Interpreter ist(der Compiler im Name ist durchaus berechtigt, weil er im Kontext von sich selbst ein Compiler ist, aber im Bezug zum Anwendungsstart ein Interpreter ist).
Dem zitierten von Wikipedia stimm ich vollkommen zu da es genau meine Argumentation stützt. .Net Code wird einmalig in Maschinencode kompiliert, nicht jedes mal so wie es die zitierte Definition ja von Interpretern verlangt - > Sprich, da ist nichts von wegen Interpretation. Nur weil die endgültige Compilation von Bytecode in Maschinencode praktisch on the fly beim Programmstart durchgeführt wird ist es doch nicht auf einmal eine Interpretation.
Ich versteh nicht worin dein Gegenargument bestehen soll, der Wikipedia sagt eindeutig oder meine Interpretation vom diesem, wenn die Umsetzung einmal vor der Ausführungszeit passiert, ist es ein kompiliertes Programm, sonst bist du ein interpretiertes Programm.
Da geh ich mit. Bei interpretiertem Code ist der Interpreter derjenige der den Code ausführt und nicht das Programm selber weils in Maschinencode vorliegt. Nun die Frage - welches Programm führt den .Net Code aus? Gar keins, der Code liegt zur Ausführungszeit nänmlich in Maschinencode vor und wird direkt durch die CPU ausgeführt und nicht durch ein anderes Programm. Daher kann das ganze nicht interpretiert sein, weil einfach kein Programm da ist zum interpretieren.
Falsch, die Ausführungszeit beginnt mit ein Doppelklick auf das Executable. Ein IL-Code kann nicht vom Prozessor ausgeführt werden, deswegen muss der JIT aktiv werden.
Ich hab das Gefühl, du stellst dir ein Interpreter als Treiber vom Quellcode vor. Aber ein Umsetzter der jedes mal dein Skript scannt, parst, übersetzt (Komplikat erstellt) und diesen in Arbeitsspeicher hält, wird Intreperter genannt.
-
Was soll das immer heißen, "wird genannt"? Nennt irgendwer so, dem du anscheinend vertraust. Wikipedia kannst du bei solchen Fragen auch grundsätzlich vergessen.
Und mal ehrlich, eine Definition, nach der man einen Interpreter so bauen kann, dass ein Compiler aufgerufen, das compilierte Programm gestartet und am Ende wieder gelöscht wird, taugt aus technischer Sicht auch absolut nichts.
Die Begriffe sind offensichtlich schwammig, schließen sich nicht gegenseitig aus, und hängen von der Sichtweise ab. Das könnte eventuell daran liegen, dass in Fachkreisen überhaupt kein Bedarf besteht, diese Unterscheidung zu thematisieren (im Gegensatz zu dem Beispiel mit der Echtzeit).
-
Bashar schrieb:
...
Die Erläuterung kommen auch aus der Systembetrachtung - siehe Seite 3 Drachenbuch.
-
Zitat bitte. Auf Seite 3 steht da nichts von, auf Seite 4 steht was, was dir widerspricht. Vielleicht hast du eine andere Ausgabe als ich.
Übrigens solltest du dir einen weniger arroganten Argumentationsstil zulegen.
-
[quote="Zeus]wenn die Umsetzung einmal vor der Ausführungszeit passiert, ist es ein kompiliertes Programm, sonst bist du ein interpretiertes Programm.[/quote]
Falsch, die Ausführungszeit beginnt mit ein Doppelklick auf das Executable. Ein IL-Code kann nicht vom Prozessor ausgeführt werden, deswegen muss der JIT aktiv werden.[/quote]
Bezüglich "Ausführungszeit"; Du hast recht, wenn du von der Userebene sprichst, für den beginnt die Ausführung des Programms mit dem Starten der Anwendung.Aber technisch ist das ein wenig anders. Der eigentliche Programmcode liegt, wenn er ausgeführt wird, nämlich nicht mehr in CIL Code vor, sondern in nativen Code, weil er vorher durch den JIT Compiler kompiliert wurde. Und erst dieser wird ausgeführt. Im Detail ist das noch komplizierter, weil der Jitter ja nur on Demand kompiliert und daher nicht die komplette Assembly als Maschinencode vorliegen muss, sondern nur die Teile die ausgeführt wurden. Aber Fakt ist: Ausgeführt wird Maschinencode, der vorher compiliert wurde. Daher kann es kein Interpreter sein.
Alles nachzulesen im Kapitel 1 im Abschnitt "Executing Your Assembly’s Code" im schon genannten Buch "CLR via C#"
Ich habe die Frage schonmal gestellt, wo soll eurer Meinung nach Code bei .Net interpretiert werden? Und wer soll das machen?
-
Und der JIT-Kompiler wird natürlich nicht ausgeführt, sondern der wird vom Zwergli-Gott hergerufen und startet aus einem Wunder Gottes heraus seine Arbeit. Und schaut da, plötzlich war da Maschinencode, wie es der Gott veranlasst hatte und die Anwendung konnte nun starten ohne jemals ausgeführt worden zu sein. Ein Wunder war geschehen.
-
Eine .Net Applikation ist ja ne ganz normale ausführbare Datei im PE32(+) Format und der Einstiegssprung im PE Header zeigt auf die Einsprungsmethode der MSCorEE.dll die die Runtime lädt und diese startet dann die eigentlich Main Methode. Wenn der auszuführende Code nicht in Maschinencode vorliegt, wird er kompiliert und dann wird der kompilierte Code ausgeführt. Lag der Code schon in Maschinencode vor, dann wird er direkt ausgeführt.
Nur weil erst bei Bedarf und nicht komplett bei Programmerstellung der Code kompiliert wird, ist er doch nicht interpretiert. Siehe auch meine Ausführung eben, da ist kein Programm was irgend einen Code interpretiert, involviert.
