Ist es möglich bei Visual Studio 2010 ein C# Programm auch für Linux zu kompilieren?
-
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.
-
@Zwergli,
Ich empfehle dir nochmals meine Argumentation durchzulesen. Ich will es aber nochmals versuchen.Wenn man die *.exe doppelklickt, wird der .Net Interpreter aufgestartet (und jetzt heul nicht schon rum, sondern lies erst mal weiter!). Dieser Interpreter interpretiert den IL-Code in dem er diesen dem JIT-Kompiler übergibt. Der JIT-Kompiler gibt Maschinencode zurück, welcher vom Interpreter nun an die CPU zur Ausführung übergibt. Der erzeugte Maschinencode wird vom Interpreter in einen Cache gesetzt, damit er nicht verloren geht und jedesmal den JIT-Kompiler neu aufgerufen werden müsste. Am besten ist der Maschinencode sogar gleich im Cache richtig zusammengehängt.
Wie ich schon mal gesagt hatte, ist für mich der JIT-Kompiler eine Komponente eines modernen Interpreters.
Technisch gesehen widerspreche ich dir in keinem Punkt. Und trotzdem versuchst du es uns immer wieder zu erklären. Komm bitte mal von da oben runter und sieh uns nicht als Unwissende an, vielleicht verstehst du dann unsere Argumentation.
Wenn ich Zeus richtig verstanden habe, setzt er einfach JIT-Kompiler und Interpreter als dasselbe hin. Ich sage der JIT-Kompiler ist ein Tool des Interpreters. Am Ende kommt es eigentlich auf fast das Gleiche hinaus. Schliesslich ist neben dem JIT-Kompiler nicht mehr viel sonst vorhanden, was man dem Interpreter zuordnen könnte.
Und zu deinem Buch: "C# via CLR". Fang endlich an zu zitieren, sonst hat das keinerlei Sinn.
Oder willst du mit dem Buch uns nur erklären, wie .Net funktioniert, was wir aber alle hier wissen und du nur nicht wahrhaben willst?Grüssli
-
Dravere schrieb:
Wenn man die *.exe doppelklickt, wird der .Net Interpreter aufgestartet. Dieser Interpreter interpretiert den IL-Code in dem er diesen dem JIT-Kompiler übergibt. Der JIT-Kompiler gibt Maschinencode zurück, welcher vom Interpreter nun an die CPU zur Ausführung übergibt. Der erzeugte Maschinencode wird vom Interpreter in einen Cache gesetzt.
Genau so habe ich es auch immer verstanden, und ich bin mir sicher alle anderen sehen das auch so - gut zusammengefasst :).
Das "Problem" an diesem Thread ist, glaub ich, die Definition eines Interpreters.
Ich selber habe da nie von einem Interpreter gesprochen.
Für mich war ein Interpreter bisher immer ein Modul der ein "Script" bekommt und dessen Anweisungen direkt ausführt.Bei C# sage ich eher das die .Net Runtime den IL durch den JIT Compiler jagt und das Ergebnis daraus ausführen lässt.
Ob dieses "Übergib das Zeug den JIT Compiler und führe danach das Ergebnis aus" nun intern ein Script ist, spielt für mich keine RolleAlso zusammenfassend:
Für mich ist ein Interpreter ein Programm das Anweisungen die als Script rein kommen direkt ausführt. Wie PHP, VBS, JavaScript oder Batch.
Wenn das nicht zutrifft ist es kein Interpreter.
-
Bashar schrieb:
Übrigens solltest du dir einen weniger arroganten Argumentationsstil zulegen.
Entschuldigung ich war bisschen im Streß.
Also zum Kapitel Sprachprozessor 1.1 aus dem Drachenbuch.
Kurzfassung von Seite 3.
Quellprogramm ist ein Programm in einer andere Sprache
Zielprogramm ist ein Programm (offensichtlich native - steht so nicht direkt geschrieben)Ein Compiler ist ein Programm dass ein Quellprogramm in ein Zielprogramm überführt.
Danach kann das Programm(in Maschinencode) ausgeführt werden, um Eingabe zu verarbeiten und Ausgabe zu produzieren.Weil mir persönlich die Erläuterung nicht passt, zitiere ich den Interpreter Erklärung.
Drachenbuch Seite 3 schrieb:
Ein Intrepreter ist eine andere Form von Sprachprozessor. Anstell ein Zielprogramm durch durch den Übersetzung zu erstellen, führt der Interpreter die von Quellprogramm verlangten Operationen scheinbar direkt an dem von Benutzer bereitgestellten Eingaben aus...
Anmerkung:
- Die Pfeile von Quellprogramm und Eingabe die zum Intrepreter enden, suggieren zeitlich, dass etwas gleichzeitig passiert, denn ist aber nie so, denn auch eine Eingabe beim Interpreter muss voher paar Statements intpretiert sein, bevor eine interaktive Eingabe passiert sein kann, oder die Eingabe befindet sich im Quellcode.
- Compiler und Intrepreter sind Black-Box, die interene/technische Realisierung scheint nicht von Bedeutung zu sein, und findet auch keine weitere Betrachtung in diesem Kapitel statt, allerdings werden weitere Werkzeuge betrachtet.
- Quell/Zielprogramme sind im Kontext der Erläuterung persistente(auf Dateisystem) und erreichbare(für den Benutzer) Programme, sonst würde der Begriff Übersetzung kein Sinn machen, denn irgendwie wird bei beiden doch 'Übersetzt' sonst könnten wir doch kein Programm ausführen?!
- Damit ergibt sich eine harte Definition von Compiler und eine weiche Definition für Interpreter, wenn man den die Erläuterung zu eine Definition umschreiben möchte.
Die Kriteriern sind:- Einmal Übersetzung beim Compiler
- Trennung zwischen Übersetzungszeit und Ausführungszeit beim Compiler
Drachenbuch Seite 4 schrieb:
Java-Sprachprozessor kombinieren Kompilierung und Interpretation,... Ein Java-Quellcodeprogramm kann zunächst in ein Zwischenform kompiliert werden, dem sogenannten Bytecode, der dann von einer virtuellen Maschine, interpretiert wird. ...
@Bashar der Widerspruch ist der Abschnitt über JITC?
Drachenbuch Seite 4 schrieb:
Um eine schnellere Verarbeitung der Eingabe in Ausgabe zu erreichen, übersetzen manche Java-Compiler, die sogenannten Just-in-time-Compiler, den Bytecode in Maschinensprache, direkt bevor sie das Zwischenprogramm zum Verarbeiten von Ausgaben ausführen.
Ich seh kein Konflikt zum Buch oder zu meine Ansicht darüber.
Mit java.exe -jar myapp.jar müss du dein Programm trotzdem ausführen egal ob interpretiert/getrieben wird oder durch ein JITCer kompiliert wird.
Schon vorher hab ich gesagt, dass JITCer ein Kompilier ist. Aber im Kontext der Anwendung trotzdem interpretiert ist.Gedankenexperiment
Hab ich ein Programm geschrieben, dass Quellprogramme einließt, der C++-Code einließt und on-the-fly Maschinencode generiert und ausführt, hab ich einen Kompiler oder einen Interpreter geschrieben?@Dravere
Nun wenn du Interpreterbauen möchtest muss du an der Uni/Hochschule Compilerbau besuchen, vorausgesetzt du möchtest dir nicht selbst beibringen, die Thematik ist die Gleiche.Nach Zwergli Definition sind Interperter entweder im Form vom AST Executer oder abstrakte Maschinen und der rest Komplikate, oder? - Bekomme ich ein bisschen Bauchschmerzen.
Aber guckenn wir doch an, was die Leute sagen, der dauernd damit zu tun haben.
http://llvm.org/ProjectsWithLLVM/#pure schrieb:
The interpreter uses LLVM as a backend to JIT-compile Pure programs to fast native code.
Jetzt dürft ihr mich über meine Irrtume aufklären
-
Zeus schrieb:
@Dravere
Nun wenn du Interpreterbauen möchtest muss du an der Uni/Hochschule Compilerbau besuchen, vorausgesetzt du möchtest dir nicht selbst beibringen, die Thematik ist die Gleiche.Wie kommst du jetzt darauf?
Und wie bitte kann man das Besuchen einer Vorlesung mit "nichts selber beibringen" vereinen? Nur mit etwas Theorie kommt man nicht weit, man sollte schon auch mal sowas selber umsetzen. Um das selbst beibringen kommt man nicht herum. Zumindest ist das meine Erfahrung, aber das weicht nun etwas vom Thema ab. Keine Ahnung wie du nun darauf gekommen bistGrüssli
