Diskussion:Compiler/Archiv/1
Optimierung
Dieser Text ist zu einseitig auf die Optimierung bezogen. Der englische Text ist wesentlich ausführlicher und sollte hier eingearbeitet werden. Eggert Ehmke
- Ich würde die Compiler-Optimierung gern in einen eigenen Artikel auslagern, da ich über SSA-Optimierungen, Common Subexpression Elimination und ähnliche Späße schreiben möchte, was den Rahmen des jetzigen Compiler-Artikels wahrscheinlich sprengen würde. Im Compiler-Artikel selbst fehlen mir persönlich noch ein paar Vokabeln wie Frontend und Backend, das ganze gehört insgesamt etwas systematischer aufgezogen. Wenn niemand laut schreit, werde ich meine Vorstellungen bald umsetzen. --Echoray 17:53, 8. Apr 2004 (CEST)
- Mach es!!!!!!! -- tsor 20:14, 8. Apr 2004 (CEST)
- Reduktion von Paging zur Laufzeit [Bearbeiten]
- Zusammenhängender Code, z. B. eine Schleife, sollte zur Laufzeit möglichst auf der gleichen „Seite“ ::(zusammenhängend vom Betriebssystem verwalteter Speicherblock) im Hauptspeicher liegen. Dies kann man z. B. ::dadurch erreichen, dass man dem Programmcode geeignete Leeranweisungen („NOPs“ – No OPeration) hinzufügt. ::Dadurch wird der Programmcode zwar größer, aber wegen des reduzierten Pagings wird das Programm schneller ausgeführt.
Gibt es das wirklich? Eine Speicherseite (Page) ist 4 kbyte bis 4 Mbyte gross! Ich habe noch nie so viele NOPs in einem Maschinenprogramm gesehen. Das macht auch keinen Sinn! Optimierender Übersetzer richtet auf die Grenze von Cache-Zeilen(64-256 Byte) aus und nicht auf Speicherseiten!
Falsche Änderungen
Es wäre schön, wenn die Leute, die sich nicht mit dem Thema auskennen, aber trotzdem mitmachen möchten, erst einmal hier auf dieser Seite fragen könnten, ob eine inhaltliche Änderung sachlich richtig ist. Leider mußte ich gerade ein paar Sachen zurückändern, die früher schon einmal richtig waren:
- Es ist wichtig, daß der C. in ein semantisch äquivalentes Zielprogramm übersetzt. Ansonsten ist das Zielprogramm sicher nicht äquivalent.
- Der Compiler bietet mit Sicherheit keine Tests an (das wäre eine Entwicklungsumgebung, die einen Compiler benutzt oder enthält) und auch keinen Interpreter.
- Der Begriff Whitespace umfaßt mehr als Leerzeichen und ist daher wichtig. Außerdem wird der Whitespace nicht aus dem Programm entfernt, sondern bei der Umwandlung des Programms in einen Tokenstrom überlesen.
- Ich habe beim Compilerbau noch nie von einer "lexikografischen Analyse" gehört.
- Mit der Klasse von Tokens ist hier gerade nicht die Objektorientierte Programmierung gemeint.
- "Prozessor" ist gutes Deutsch und man braucht daraus keinen "Zentralen Prozessor" zu machen.
Mh 21:26, 13. Apr 2004 (CEST)
Es gibt auch Compiler, die Code in anderen Programmiersprachen erzeugen können.
Was soll er sonst tun? Ein Übersetzer ist so definiert, dass er von Programmiersprache A nach Programiersprache B wandelt und dabei die Semantik erhält (also dass die gleiche berechenbare Funktion jeweils realisiert wird, oder noch anders ausgedrückt das beim Lauf von A, das gleiche wie beim Lauf von B rauskommt bei gleicher Eingabe). Siehe mein Genöle in der Diskussion zu Interpreter. :-) --Marc van Woerkom 14:54, 3. Sep 2004 (CEST)
Zuweisungssymbol
Wäre es nicht besser, wenn man in den Programmbeispielen (zumindest in denen, die nicht auf eine bestimmte Sprache bezogen sind) den Befehl '=' durch ':=' ersetzt? Dann wäre nämlich wenigstens eindeutig sichtbar, ob z: B. beim Befehl 'a = b' der Wert von a b zugewiesen wird oder umgekehrt.(nicht signierter Beitrag von 80.134.20.23 (Diskussion) 21:04, 2. Okt. 2004 (CEST))
a = b bedeutet überall dass a dann den wert von b hat, wieso sollte aufeinmal jemand auf die idee kommen es ist anders ?
bei bekannte compiler sollte man entweder die liste stark ausdehnen, zusammen schick mit entsprechender sprache (c,c++,java,pascal,oberon,erlang,lisp,brainfuck,haskell and much more)(nicht signierter Beitrag von 84.137.113.93 (Diskussion) 20:42, 2. Dez. 2005 (CET))
a=b oder a:=b Mathematisch gesehen bedeutet := eine Zuweisung, nicht =. Ein Beispiel ist etwa die Sprache Eiffel, dort bedeutet = nicht eine Zuweisung, sondern :=(nicht signierter Beitrag von 62.203.99.157 (Diskussion) 11:22, 3. Dez. 2006 (CET))
- In Sprachen wie C wird zur Unterscheidung ein == für Vergleiche benutzt. Im Compilerbau ist C eine durchaus übliche Sprache und da nur diese hier verwendet wird, sollten Mißverständnisse ausgeschlossen sein. Desweiteren verwenden auch "neuere" Sprachen wie Java und Skriptsprachen wie PHP solche Symbole.
- Aus diesem Grund sehe ich kein Problem darin = als Zuweisungsymbol beizubehalten. --JonnyJD 18:02, 8. Mär. 2007 (CET)
Ausbaufähig
Ich finde, hier ist einiges noch an Arbeit zu leisten (ich hab schon etwas hinzugefügt). Zum Beispiel fehlen hier der Bezug auf formale Sprachen, die Chomsky-Hierarchie und weiteres theoretisches Background. Der Umfang von der Programmoptimierung gefällt mir und wäre auch bei den anderen Unterpunkten angebracht. --Humbrie 21:43, 20. Dez 2004 (CET)
Lexical analysis (lexikographische Analyse) ist im englischen Sprachraum durchaus bekannt. Dabei handelt es sich um das Scannen des Source Codes und die Erzeugung eines Token Streams, welcher wiederum in Form einzelner Token an den Parser weitergerreicht wird. Ich entschuldige mich fuer den uebermaessigen Gebrauch englischer Vokablen, aber es faellt mir bei einem Thema wie diesem nicht leicht, die doch manchmal etwas umstaendlichen deutschen Begriffe zu verwenden, sofern sie mir denn ueberhaupt bekannt sind.
Es gibt durchaus auch Source-to-Source Compiler, die nicht in eine andere Programmiersprache uebersetzen. In diesem Fall sind Eingabe- und Ausgabesprache identisch. Diese auf den ersten Blick etwas seltsam anmutende Technik wird vor allem bei parallelisierenden Compilern gern verwendet, die zum Beispiel (sequentielle) C Source Codes in (parallele) C Source Codes verwandeln. Dieser parallele Code macht dann Gebrauch von OS-spezifischen Erweiterungen (z.B. POSIX-Threads) oder speziellen Libraries (z.B. MPI), um die in ANSI-C nicht bekannte Parallelverarbeitung fuer ein spezielles System zu implementieren. Andere Beispiele von Source-to-Source Compilern finden dort Verwendung, wo sog. High-Level Transformationen zur Unterstuetzung des existierenden Back-end Compilers Verwendung finden. Dabei kann z.B. durch Loop Unrolling auf der Source Ebene dem Back-end Compiler "auf die Spruenge" geholfen werden, sofern er diese Schleifentransformation nicht von sich aus beherrscht.(nicht signierter Beitrag von 82.41.49.115 (Diskussion) 00:02, 24. Jan. 2005 (CST))
Wenn man zum Beispiel in einer höheren Programmiersprache den Inhalt von 2 Variablen vertauscht, dann benötigt man eine Hilfsvariable:
Lüge!
void swap(int *a, int *b) { if (a == b) return; /* Sonst wird das Ergebnis immer 0 */ *a ^= *b; *b ^= *a; *a ^= *b; }
(nicht signierter Beitrag von 83.236.158.129 (Diskussion) 14:24, 15. Mär. 2005 (CET))
(nicht signierter Beitrag von 62.180.124.21 (Diskussion) 10:43, 8. Apr. 2005 (CEST))
- Auch wenn man in der Hochsprache keine Hilfsvariable braucht hat die Variante eher gar keinen Vorteil. Damit weiß der Compiler schon mal meistens nicht was man will und außerdem handelt man sich einen zusätzlichen Sprung ein. In obiger Variante fehlen übrigends zwei Sterne (andernfalls werden Zeiger verglichen). Hier (Intel 386) hat der gcc übrigends 18 Maschinenbefehle für obige Funktion ausgespuckt. Für eine Variante mit Hilfsvariable sind es 12.--Plaicy 21:54, 14. Mär. 2007 (CET)
Textschnipsel
Da ich gerade Programmiersprache bearbeitet habe, sind folgende zu spezielle Textbausteine übrig geblieben, die in diesem Artikel zu verarbeiten lohnenswert sein könnten:
- Da digitale Computer intern nur die Werte 0 und 1 verarbeiten, wäre es nach heutigen Maßstäben extrem umständlich und mühsam, die vielen Formen der Informationsverarbeitung als Binärzahlen eingeben zu müssen (zu kodieren). Daher haben sich in den letzten Jahrzehnten Verfahrensweisen etabliert, mit denen man häufig verwendete Zahlen, Zeichen und grundlegende Operationen als symbolische Befehle angeben kann. Eine weitere technische Einrichtung übersetzt dann diese Angaben in interne Daten, einfachste Datenänderungsbefehle und Kontrollanweisungen, die der Computer dann schließlich verstehen und ausführen kann.
- Der Compiler ist selbst ein Programm, welches als Dateneingabe den menschenlesbaren Programmtext bekommt und als Datenausgabe den Maschinencode liefert, der direkt vom Prozessor verstanden wird (zum Beispiel Objectcode, EXE-Datei) oder in einer Laufzeitumgebung (zum Beispiel JVM oder .NET) ausgeführt wird. Wird ein Programmtext hingegen Schritt für Schritt übersetzt und der jeweils übersetzte Schritt sofort ausgeführt, spricht man von einem Interpreter. Interpretierte Programme laufen meist langsamer als kompilierte. Es ist zukünftig zu erwarten, dass neuere Compiler nicht mehr direkt in Maschinensprache sondern in eine Universalsprache übersetzen. Die so entstandenen Computerprogramme werden dann innerhalb einer Laufzeitumgebung interpretierend ausgeführt.
--62.134.232.28 11:15, 16. Sep 2005 (CEST)
Abbildung?
This figure at commons (in spanish) based in the english article one is available for translations through the source openoffice.org file linked at its Common "Image:CompilationScheme-Spanish.png". You can easily translate it to your language. gengiskanhg from Spanish and english wikipedias. --132.248.36.43 16:32, 27. Sep 2005 (CEST)
Denglish
Ich finde, wir sollten den deutschen Begriff Übersetzer bevorzugen. --Marc van Woerkom 10:05, 10. Mär 2006 (CET)
- Die Bezeichnungen Compiler oder Kompilierer sind eigentlich irreführend, weil sie von der Zusammenstellung von Tabellen herrühren, die der Compiler für seine interne Datenverwaltung benötigt, was aber an der Kernaufgabe eines Compilers vorbeigeht.
Noch ein Grund. :-) --Marc van Woerkom 10:06, 10. Mär 2006 (CET)
- englische begrifflichkeiten hin oder her, die bezeichnung compiler ist nun mal die verbreitetste. gerade in computerartigen artikeln sollten wir mit der eindeutschung vorsichtig sein. und das denglische kompilierer habe ich so noch nie gelesen. also für meinen teil ist das lemma korrekt benannt. gruß --Murkel (anmurkeln) 18:07, 10. Mär 2006 (CET)
- Ich bin auch für das bleiben bei Compiler, auf die Idee nach Übersetzer (Computer) zu suchen, würde ich wahrscheinlich nicht kommen. Vor allem nicht auf Übersetzerbau. Bei Übersetzer würde ich eher an die Übersetzung von Texten denken und nicht an die Übersetzung von Programmen.--Plaicy 01:01, 14. Aug 2006 (CEST)
Überarbeitung
Hallo Leute,
es wurde ja hier schon viel darüber geschrieben wie man den Compiler Artikel überarbeiten könnte.
Ich habe auch ein paar Vorschläge, die zum Teil alte Vorschläge aufgreifen:
- Aufspalten des Artikels in mehrere kleinere, d.h.
- es könnte einen eigenen Artikel Programmoptimierungen geben
- der Beispielcompiler könnte evtl. dem Compilerbau Artikel zugeschlagen werden
- mittelfristig hat meiner Meinung nach auch die Geschichte des Compilerbaus -als ältestem Gebiet der praktischen Informatik- einen eigenen Artikel verdient.
- Die Begriffe "Analysephase" und "Synthesephase" durch die meiner Erfahrung nach geläufigeren Bezeichnungen Frontend und Backend ersetzen. Ich bin eigentlich kein Freund zuvieler englischer Wörter, aber das Wort Analysephase ist irreführend, weil die meisten und aufwendigsten Programmanalysen in modernen Compilern zu Optimierungen gehören und damit gerade nicht Teil der "Analysephase" sind.
--Joblech 17:55, 18. Sep. 2006 (CEST)
- Ich stimme dir zu, dass es einen eigenen Artikel über Programmoptimierung geben sollte. --Strimo 12:22, 10. Sep. 2007 (CEST)
Semantische Analyse
Lexikalische Analyse: Lexer
Syntaktische Analyse: Parser
Semantische Analyse: ?
Gibt es dafür auch einen Begriff. (PS: Ich weiß, dass Lexer auch nur spezielle Parser sind.)
--84.57.142.15 15:23, 3. Mär. 2008 (CET)
Illustration gelöscht
Klaeren hat die Illustration gelöscht mit der Begründung, sie sei irreführend und überflüssig. Was war daran irreführend? Und warum überflüssig? --j ?! 21:40, 31. Okt. 2008 (CET)
- hallo Jpp, die Illustration hatte gleich mehrere Probleme bzw. sachliche Fehler. Ein Problem bestand darin, dass hier ein Compilationsprozess in seinen einzelnen Phasen am Beispiel eines Hello-World-Programms in C gezeigt werden sollte. Das eignet sich aber extrem schlecht als Beispiel, weil da gar nicht viel Code erzeugt wird: es gibt nur einen Aufruf einer Bibliotheksfunktion, die den String ausdruckt. Dementsprechend war der Code vor und nach der gezeigten Optimierung schon mal gleich, weil es hier nichts zu optimieren gibt. Der Leser wird deshalb den Sinn dieses Schrittes nicht einsehen. Viel problematischer sind aber sachliche Fehler in der Illustration: Bei der Syntaxanalyse wird umständlich vorgeführt, wie der Compiler auf das
#include <stdio.h>
am Anfang des Programms reagiert. Das kriegt der Compiler aber niemals zu sehen, weil dieser Teil eines C-Programms vom Präprozessor bearbeitet wird, der hier den Text vonstdio.h
einfügt. Dessen Verarbeitung durch den Compiler wäre aber auch total langweilig. Zusammengefasst: Eine problematische, teilweise sachlich falsche, und im ganzen uninstruktive Illustration. (Ach, ich sollte es vielleicht noch sagen: Ich bin Informatikprofessor, mein Fachgebiet ist Compilerbau ;-) Gruss --Herbert Klaeren 12:54, 1. Nov. 2008 (CET)- Dennoch war die Illustration für Laien sinnvoll, weil sie einen schnellen Überblick gab. Die bemängelten „Fehler“ scheinen mir da eher marginal zu sein. Aber nun gut, ich hoffe dann mal drauf, dass du uns bald eine verbesserte Grafik zur Verfügung stellst. Sollte sich aus deinen Vorlesungsskripten ja problemlos extrahieren lassen. :-) --j ?! 17:00, 2. Nov. 2008 (CET)
- ja klar, ich mach da mal was, dauert aber noch eine Weile. Den Artikel hab ich auf dem Radar, da muss ich im ganzen nochmal ran. --Herbert Klaeren 09:21, 3. Nov. 2008 (CET)
- Dennoch war die Illustration für Laien sinnvoll, weil sie einen schnellen Überblick gab. Die bemängelten „Fehler“ scheinen mir da eher marginal zu sein. Aber nun gut, ich hoffe dann mal drauf, dass du uns bald eine verbesserte Grafik zur Verfügung stellst. Sollte sich aus deinen Vorlesungsskripten ja problemlos extrahieren lassen. :-) --j ?! 17:00, 2. Nov. 2008 (CET)
ich schwör'
ich schwör's euch: Bei der lexikalischen Analyse einfach alle Kommentare mitm Lookahead und die Leerzeichenfolgen durch ein Trennzeichen ersetzen... Dann lest ihr bis zum nächsten Sequence-Point -sprich: Komma oder Semikolon ein und kopierts in einen String. Da stottert ihr dann die Operatorenliste mit den Operatoren und ihren Prioritäten und Assoziativität ab. Und zwar erst die eckige Klammer, dann die runde Klammer, dann z.B. Multiplikationsoperator o.ae. und setzt anhanddessen die Start- und Endzeiger fürs raufkopieren. Den eingegrenzten Bereich kopiert man eine Zeile rauf und setzt da dann die Operation hin mitm Gleichsetzungsverweis auf eine mit einem Variablennamengenerator-generierten Variablennamen. Und ersetzt den Fetzen dann durch ebenden Variablennamen. Im selben Bereich zwischen den Sequence-Points wiederholt man das Spiel, bis keine Operatoren mehr drinnen sind. Dann geht's weiter bis zum nächsten Sequence-Point. Das geht dann alles direkt zu Assembler und darum kümmert sich dann der Bytecode-Assembler. Für if, for, while und do braucht man noch Sprungmarkengeneratorstacks...
x=1+(a*5)
rptr1=a*5 x=1+(rptr1) rptr2=rptr1 x=1+rptr2
rptr1=a*5 rptr2=rptr1 rptr3=1+rptr2
x=rptr3
so in etwa... (nicht signierter Beitrag von 88.66.147.27 (Diskussion) 15:40, 20. Jul 2010 (CEST))
Attribuieren
"attributieren" ist nicht "Fachsprache", sondern schlicht oft vorkommender Fehler. Das Wort wird nicht durch "Verbisierung" von "Attribut" durch die Endung "-ieren" gebildet, sondern direkt aus dem lateinischen von attribuere. Das "t" kommt nur durch die dritte Person Singular. Das Wort "attributieren" ist also ein Phantasiewort, kein Fachjargon. Da es das Wort "attribuieren" im deutschen schon gibt, besteht keine Notwendigkeit, erstens, das Wort "attributieren" zu erfinden, und zweitens attribuieren und attributieren inhaltlich voneinander abzugrenzen, da sie ja dasselbe bezeichnen. Nur weil viele, und wahrscheinlich sogar die Mehrheit "attributieren" sagen, wird es dadurch nicht weniger falsch. -- Arist0s 20:02, 11. Apr. 2010 (CEST)
- Ich behaupte, "attributieren" kommt von "Attribution". Oder erklär mal, wo "attribuere" herkommt. Einen griechischen Vorfahren konnte ich auf die Stelle nicht finden. Google findet für "attribuierter Syntaxbaum" 3 Ergebnisse, die nicht von Wikipedia (kopiert) sind. Die Ergebnisse für "attributierter Syntaxbaum" sind um mehr als 2 Größenordnungen (567) darüber. Das Wort "attributiert" wurde also schon längst erfunden, es besteht keine Notwendigkeit, den Gebrauch umzuwerfen, weil ein Wortstamm entdeckt wurde, der Gebrauch bestimmt die Sprache. Geändert. -- Krstfrs 02:35, 25. Mai 2010 (CEST)
- Ergänzung: Im Artikel heißt es "[...] nennt man dann dekorierter oder attribu[t]ierter Syntaxbaum.". Man nennt es ganz sicher attributierter Syntaxbaum, das "man", das es attribuierter Syntaxbaum nennt beschränkt sich im Internet auf 3 Personen. -- Krstfrs 02:38, 25. Mai 2010 (CEST)
Einleitung, Geschichte
Vor dem 26.9.2011 hat der IP-User 84.157.211.167 ziemlich umfangreiche Änderungen am Artikel, v.a. Einleitung und Geschichte, geschrieben. Den Großteil davon finde ich sinnvoll und verständlich, jedoch sind auch einige Informationen gekillt worden, die durchaus erhaltenswert gewesen wären. Ich hab' jetzt erst mal versucht, eine Kompromissversion zu erstellen zwischen dem Davor und der neuen IP-Version.
Hat schon seinen Sinn, dass umfangreiche Änderungen erst auf der Disku angesprochen werden sollten X-} --arilou 08:30, 26. Sep. 2011 (CEST)
Quelltexte
Was sollen diese beiden ewig langen Abschnitte, in denen nur Quelltexte stehen? --DF5GO 01:39, 25. Dez. 2011 (CET)
- Das hier war wohl eine Art Weihnachtsgeschenk. Sieht nach einem Grundkurs an der Uni aus, oder LK. Vielleicht funktioniert es ja, aber dann erst fertig schreiben, und richtig formatieren und abschnittsweise kommentieren. Und dann eher Wikiversity als Wikipedia.
- Der kleine Beispielcompiler gehört zum Bestand, hat eine Einleitung sowie Beispiele zum Nachverfolgen und den generierten Beispieloutput. Das ist ja okay.
- Ich hab dann mal aufgeräumt. --PerfektesChaos 11:03, 25. Dez. 2011 (CET)
- Ist immer noch ziemlich viel Quelltext. Soviel auf jeden Fall, dass ich nicht komplett verstehe, was das Programm tut. Liegt aber wohl auch daran, dass der Quelltext komplett unkommentiert ist. --DF5GO 03:31, 26. Dez. 2011 (CET)
Sorry - aber so kann der Quelltext nicht stehenbleiben. Wenn wer einen Mini-Compiler wo findet, der in 10-20 Zeilen Code was compiliert, dann gerne - aber das hier ist einfach viel zu lange. Ich hab mal die Funktionalität des Compilers reduziert - der Source ist aber immer noch 74 Zeilen lang. Ich denke der Artikel Compiler (und auch Interpreter) braucht keinen Sourcecode den Sachverhalt zu erklären - im Gegenteil, Sourcecode verwirrt hier nur. --Sebastian.Dietrich ✉ 10:33, 26. Dez. 2011 (CET)
- Wer Vieles bringt, wird manchem etwas bringen.
- Der Artikel richtet sich an Schüler, Studies, PC-Interessierte. Weil ein Foto eines Compilers den Artikel kaum illustrieren könnte, ist ein einfacher Beispielcode für ein verallgemeinerbares Grundproblem sehr sinnvoll und sollte unbedingt erhalten bleiben. Ich habe den existierenden Beispielcode jetzt nicht allzusehr geflöht; mir scheinen aber auch noch ein paar für den Profi triviale, für beginners hilfreiche Kommentare im Quellcode oder umschließenden Text ergänzbar, und seien es nur die deutschen Übersetzungen für die Namen der Unterprogramme. Ansonsten ist das existierende Beispiel didaktisch wohl ganz brauchbar. Und da ganz, ganz hinten stört das auch keinen Lesefluss. Noch kürzer als diesen Übersetzer für arithmetische Ausdrücke wird man ein sinnvolles Beispielprogramm nicht hinkriegen. Und eine Verwirrrung sehe ich unmittelbar vor dem Literatur&Weblink-Anhang in keiner Weise; wer es nicht mag, liest halt nicht weiter.
- Soviel für 2011 --PerfektesChaos 21:05, 26. Dez. 2011 (CET)
- Die Wikipedia richtet sich aber nicht nur an Schüler, Studies, PC-Interessierte, sondern auch an Laien. Dementsprechend sollte der Artikel auch aufgebaut sein, Stichwort Laientest. Und das beinhaltet imho auf jeden Fall, dass ein Quelltext ausführlich kommentiert sein sollte, genauso wie ein Bild auch eine vernünftige Bildbeschreibung haben sollte. --DF5GO 00:27, 27. Dez. 2011 (CET)
- und in jedem Fall ist dieses Beispiel zu kompliziert und deshalb für Laien unverständlich. Hier wird eine Stapelmaschine auf ziemlich undurchsichtige Weise verwendet. Eigentlich sollte der Code
5+3*2-9
- so übersetzt werden:
PUSH 5
PUSH 3
PUSH 2
MUL
ADD
PUSH 9
SUB
- Der Code des Compilers würde dementsprechend auch einfacher. --Herbert Klaeren 10:18, 27. Dez. 2011 (CET)
- Da sich hier seit knapp zwei Wochen nichts getan hat, habe ich den Artikel mal bei der Qualitätssicherung der Redaktion Informatik eingetragen. --DF5GO 13:12, 7. Jan. 2012 (CET)
- WP:OMA möchte vor allem, dass Laien beim Lesen des Artikels verstehen, um was es im Groben geht. Es ist nicht notwendig, dass sie alles verstehen. Der QS-Eintrag ist daher völlig überflüssig.
- Davon abgesehen ist der hier diskutierte Abschnitt keine Hilfe für irgendeinen Leser. Und das liegt nicht an der fehlenden Kommentierung. Das Lemma ist schlicht ungeeignet für konkrete Beispiele. Zumal der Quellcode in den Artikel Tokenizer gehört, wenn überhaupt irgendwohin! Das trifft im Übrigen auch auf die weiter oben befindlichen Codebeispiele zu. Hier sollte eher mit Ablaufdiagrammen gearbeitet werden als mit Beispielcode. Evtl. ist ein (ganz!) kleines Beispiel in ANTLR mit In- und Output hilfreich, weil das am leichtesten die Funktionsweise eines Compilers klar macht. Aber das ist purer Luxus.
- Was dem Artikel fehlt, sind Erklärungen über die Bestandteile und die Funktionsweise von Übersetzern, Parser, Parserkonzepte (Top-Down/Bottom-Up/einfach/mehrfach/Präcompiler), Lexer, Formale Grammatiken. Die momentan dort vorhanden Teile sind ziemlich dünn. Aber auch das ist definitiv nicht laientauglich. --Trac3R 14:09, 7. Jan. 2012 (CET)
- Also meinetwegen kann das Beispiel auch raus. Aber wenn es drin bleibt, dann muss es auch ordentlich kommentiert sein. --DF5GO 11:50, 11. Jan. 2012 (CET)
- Wenn es drin bleibt, dann ist es dennoch im falschen Artikel. Im Artikel Tokenizer kann man sicher die Funktion an einem abstrakteren und kürzeren Beispiel erklären. Ebenso wie man die Funktion einer syntaktischen Prüfung im Artikel Parser klären kann. Ein lauffähiges Beispiel wie dieses ist total überflüssig und führt zwangsläufig zu einem unverständlichen Artikel. --Trac3R 12:28, 11. Jan. 2012 (CET)
- Ok, was machen wir jetzt? Da ich fachlich nicht in der Lage bin, das Beispiel zu verständlich zu machen, aber es auch sonst offenbar niemand bereit dazu ist, das verständlich zu machen, wäre ich für löschen des Beispielquelltextes. --DF5GO 13:11, 11. Jan. 2012 (CET)
- meinen Segen hast du dazu... --Herbert Klaeren 13:13, 11. Jan. 2012 (CET)
- Ich hab das Beispiel jetzt durch ein formaleres ersetzt. Ob das jeder versteht bezweifle ich jedoch, es macht allerdings die Funktionsweise der einzelnen Komponenten besser sichtbar und ist kommentiert. --Trac3R 17:23, 11. Jan. 2012 (CET)
- Das Beispiel ist deutlich besser. Bin bei weitem kein Programmierexperte, aber durch die Kommentare kann ich zumindest ungefähr nachvollziehen, was das Programm tut. Das alte Programm hingegen hab ich nicht ansatzweise verstanden. Insofern eine deutliche Verbesserung. -- ErledigtDF5GO 17:49, 11. Jan. 2012 (CET)
Anderer Beispiel-Compiler
es geht wirklich komplett billig. Ihr könnt euer Drachenbuch grad nehmen und in die Tonne treten. Ihr gebt hier einen simplen Term ein, und das Programm übernimmt das Raufsortieren. Je höher die Priorität des Operators, desto weiter oben. Danach geht's nach der Operatorerkennung direkt zu Assembler. Mit einfachen Uebersetzungsregeln. Für die Kontrollstrukturen (if, while, for,... ) fügt ihr ein cmp ein, legt einen Stack an und holt bei der geschlossenen geschweiften Klammer die jmp-Sprungmarke vom Stack. Es geht wirklich nicht schwer. Löst Algebra auf, und überlegt, was ihr dabei macht.
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
static int var_name_count=0;
void variable_countup(char *name, int do_countup)
{
char appendix[255];
char *base="rptr";
if ( do_countup == 1 ) ++var_name_count;
itoa(var_name_count, appendix, 10);
strcpy(name,base);
strcat( name, appendix );
return ;
}
void prepare_input( char *string)
{
while ( *string != '\0' )
{
if ( *string==' ' )
{
string++;
while ( *string==' ' ) strcpy(string-1, string ), string++;
}
string++;
}
}
int token_in_range( char *string, int len, char token, int *token_pos )
{
int count=0;
while (string[count]!= token )
{
count++;
if ( count> len ) return 0;
}
*token_pos=count;
return 1;
}
int seek_to_variable_in_range_downwards(int *pointer, char *string, int start )
{
while ( string[*pointer]==' ' && *pointer > 0) (*pointer)--;
if ( ! isalnum( string[*pointer] ) )return 1;
while ( isalnum ( string[*pointer] ) &&
*pointer >= start )
{
(*pointer)--;
}
(*pointer)++;
return 0;
}
int seek_to_variable_in_range_upwards(int *pointer, char *string, int len )
{
while ( string[*pointer]==' ' && *pointer < len ) (*pointer)++;
if ( ! isalnum (string[*pointer] ) )return 1;
while ( isalnum( string[*pointer] ) &&
*pointer <= len )
{
(*pointer)++;
}
(*pointer)--;
return 0;
}
int main(void)
{
char input[255];
char result_string[255]="";
char end_of_input[255];
char var_name[255];
int abort=0;
int noops=0;
int start, start_seek, start_seek_b, end, end_seek, token_pos;
gets(input);
prepare_input(input);
start=0;
end=strlen(input);
while (noops==0)
{
noops=1;
end=strlen(input);
start=0;
/* zum Funktionsaufruf eingrenzen */
if( token_in_range(input, end,')', &token_pos )==1 )
{
noops=0;
end_seek=start;
while( input[end_seek]!=')' ) end_seek++;
start_seek=end_seek;
if ( token_in_range( input, end_seek, '(', &token_pos ) )
{
while(input[start_seek]!='(' ) start_seek--;
if (start_seek > 0 ) start_seek--;
if ( seek_to_variable_in_range_downwards(&start_seek, input, start)==0 )
{
end=end_seek;
start=start_seek;
}
}
}
/* zu den Klammern eingrenzen */
if( token_in_range(input, end,')', &token_pos )==1 )
{
noops=0;
end_seek=start;
while( input[end_seek]!=')' ) end_seek++;
start_seek=end_seek;
if ( token_in_range( input, end_seek, '(', &token_pos ) )
{
while(input[start_seek]!='(' ) start_seek--;
}
else
{
printf ("Syntaxfehler: geschlossene Klammer fehlt.\n");
abort=1;
}
if ( ! abort )
{
start_seek_b=start_seek-1;
if ( seek_to_variable_in_range_downwards(&start_seek_b, input, start)==1 )
{
end=end_seek;
start=start_seek;
}
}
}
/* zum Multiplikations- oder Divisionsoperator eingrenzen */
if ( token_in_range ( input+start, end-start, '*', &token_pos ) ||
token_in_range ( input+start, end-start, '/', &token_pos ) )
{
noops=0;
start_seek= start+token_pos;
end_seek= start+token_pos;
start_seek--, end_seek++;
if( seek_to_variable_in_range_downwards(&start_seek, input, start)==1 ||
seek_to_variable_in_range_upwards(&end_seek, input, end)==1 )
{
printf("Syntaxfehler bei Multiplikation oder Division.\n"); abort=1;
}
else
{
end=end_seek, start=start_seek;
}
}
if (abort==1 ) return;
/* zum Additions- oder Subtraktionsoperator eingrenzen*/
if ( token_in_range ( input+start, end-start, '+', &token_pos ) ||
token_in_range ( input+start, end-start, '-', &token_pos ) )
{
noops=0;
start_seek= start+token_pos;
end_seek= start+token_pos;
start_seek--, end_seek++;
if( seek_to_variable_in_range_downwards(&start_seek, input, start)==1 ||
seek_to_variable_in_range_upwards(&end_seek, input, end)==1 )
{
printf("Syntaxfehler bei Addition oder Subtraktion.\n"); abort=1;
}
else
{
end=end_seek, start=start_seek;
}
}
if ( abort==1 ) return;
/* Raufsortieren und Substring ausm String loeschen */
if ( noops==0)
{
strncat( result_string, input+start, end-start+1);
strcat( result_string, "=");
variable_countup(var_name,1);
strcat( result_string, var_name);
strcat( result_string, "\n");
strcpy (end_of_input, input+end+1);
strcpy (input+start, var_name);
strcpy( input+start+strlen(var_name), end_of_input);
}
}
strcat(result_string, input );
printf("%s", result_string);
getch();
return;
}
(nicht signierter Beitrag von 109.43.181.76 (Diskussion) 01:32, 25. Apr. 2012 (CEST))
- Als "neuer Beitrag" von mir ans Disku-Ende verschoben.
- Sourcecode gehört umrandet mit ,
<syntaxhighlight lang="c" />
,<syntaxhighlight lang="c" />
oder ähnlichem.<code />
- Unterschrieben war's auch nicht.
- Keine Überschrift.
*grummel* --arilou (Diskussion) 09:26, 25. Apr. 2012 (CEST)
Inhaltlich kann ich hierzu NULL sagen. Nur soviel: Was da gezeigt wird, kann nie im Leben der Code eines Compilers sein. Das sind höchstens irgendwelche Parameter, die von einem wirklichen Übersetzerprogramm interpretiert werden. Ein Compiler braucht im einfachsten Fall Lesebefehle für Quelltextzeilen, müsste Algorithmen zum Umsetzen von symbolischen in physikalische Adressen haben, müsste Befehlscode konvertieren in Maschinenbefehlscode, Write-Befehle für die Ausgabe des Maschinencodes aufweisen, Fehlerhinweise bei Syntaxfehlern ausgeben etc. etc. Von all dem 'sieht' man hier nix.
Also: Liege ICH da falsch? Oder verstehe ich gar nichts von Compilern? Die OMA jedenfalls wird diesen Code keinesfalls mit dem geschriebenen Text in Einklang bringen können. Vielleicht ist nur die Kapitelüberschrift 'Ein Beispielcompiler' unpräzise. --VÖRBY (Diskussion) 19:54, 4. Aug. 2012 (CEST)
- Ich hatte auf das Ding schon mal oben unter #Quelltexte reagiert, Stichwort „Weihnachtsgeschenk“.
- Es ist irgendwo mit C&P abgekupfert; vermutlich funktioniert es sogar.
- Es ist tatsächlich ein Compiler, der arithmetische Ausdrücke (vier Grundrechenarten und Klammern, sowie Variablennamen und Wertzuweisung) übersetzen kann.
- Die Zielsprache ist nicht programmiert. Assembler-Code könnte man zumindest aus der Auswertung des Resultats dieser Angelegenheit generieren und dann irgendwas damit ausrechnen.
- Eigentlich ist das aber mehr ein Parser. Gleichwohl: Genau sowas wird beim Zwischencode=Bytecode verwendet. Lisp nennt sein Gebilde für Bytecode auch Compiler
(byte-compile)
, zumindest in denjenigen von 100 Dialekten, die mir bislang untergekommen sind; und in Java heißt das javac für Java-Compile. Dieses Dings hier übersetzt die in menschenlesbarer, formatierter Sprache vorliegende Zeichenkette in die maschinengeeigneten Brösel und formale Beziehungen dazwischen. Jetzt könnte man die Abfolge der Brösel den Assembler-Befehlen zuordnen, oder den Zwischencode-Syntaxelementen. - Für unseren Artikel ist das eh nix; ich glaube, vor einem Jahr hatte da mal ein anderer „Beispielcompiler“=Parser dringestanden.
- Hoffe geholfen zu haben --PerfektesChaos 22:11, 4. Aug. 2012 (CEST)
- Danke, ich verstehe das dann so: Der gezeigte Code ist tatsächlich 'Quellcode' für einen (fiktiven) „Compiler“. In welcher 'Programmiersprache' ist dieser Code formuliert? Wie jeder Quellcode wird auch dieser von einem (anderen) Compiler/Interpreter übersetzt und das Ergebnis letztlich als Maschinencode bereitgestellt bzw. ausgeführt (wie das ebenfalls immer ist). Hier wären also zwei Compiler-Ebenen 'im Spiel'. Die von mir vermissten Funktionen müssten dann in der zweiten Compiler-Ebene angesiedelt sein, werden dort standardmäßig durchgeführt - und sind hier im Code nicht sichtbar. Richtig? (Zuviel Diskussion will ich aber hiermit nicht auslösen.) Grüße von --VÖRBY (Diskussion) 09:38, 5. Aug. 2012 (CEST)
- Ich habe das Progrämmle nicht kompiliert und damit herumexperimentiert, aber vom Drüberlesen passiert gefühlsmäßig etwa Folgendes:
- Eingabeformat: Arithmetischer Ausdruck in menschenlesbarer Form, wie
17 * (5 + 19 + 36) + 28*(96+14-18) + 654
- Ausgabe: Zurzeit ebenfalls menschenlesbar; Einzelanweisungen sortiert wie ungefähr
- Ich habe das Progrämmle nicht kompiliert und damit herumexperimentiert, aber vom Drüberlesen passiert gefühlsmäßig etwa Folgendes:
v0=17 v1=5 v1=v1+19 v1=v1+36 v0=v0*v1 v1=28 v2=96 v2=v2+14 v2=v2-18 v1=v1*v2 v0=v0+v1 v0=v0+654
- oder so ähnlich.
v0
ist das Ergebnis.
- oder so ähnlich.
- In den letzten zehn Statements des Programms stehen die Ausgabeanweisungen für zurzeit menschenlesbare Sprache. Hier könnte man aber genausogut die Statements irgendeines Assemblers einsetzen, und dann hätte man einen Compiler für arithmetische Anweisungen nach Assembler (was fast schon Maschinencode ist, nur in menschlicher Notation). Man kann auch im Handbuch für die CPU seines Vertrauens die Kodierungen für Operationen und Registerzuweisungen nachgucken und diesen in den Ausgabeanweisungen benutzen; dann wäre es echter Maschinencode.
- Entscheidend ist, dass dieser Parser-Compiler in seinen internen Speichern die Syntaxbrösel, Zahlen und Operatoren in der richtigen Beziehung hält; aus diesen kann man in jedem beliebigen Format Bytecode, Assembler oder Maschinensprache ausgeben.
- Sowas wird vielleicht in der 11. Klasse bei einem guten Informatik-Kurs gemacht, oder die Schüler sollen es selbst in Pascal schreiben. Irgendwo aus so einer Ecke ist das auch abgekupfert. Für unseren Artikel zu gaga, auch wenn wir über Jahre irgendwelche ähnlichen Codes im Artikel hatten.
- Schönen Sonntag noch --PerfektesChaos 16:25, 5. Aug. 2012 (CEST)
Herzlichen Dank nochmal für deine Mühe. Trotzdem verstehe ich (und sicher auch meine OMA!) nur Bahnhof. Zum Beispiel kann ich überhaupt nicht erkennen, wo dieser Compilercode feststellt, wo die Klammern gesetzt sind oder wo/wie die Punkt-vor-Strich-Regel implementiert ist. Oder wie festgelegt ist, dass die Zeilen des späteren Quellcodes gelesen werden, wo und wie die Syntaxprüfung stattfindet oder dass/wie die Ausgabebefehle erzeugt oder eine Liste erstellt würde. Nach meinem Verständnis ist das also nicht der „Quellcode eines Compilers“, sondern es sind nur Angaben, die ein 'Compiler-Compiler' nach einer festgelegten Syntax interpretiert und anhand dieser Angaben den Maschinencode für einen (einfachen) Compiler erzeugen kann. Der 'Löwenanteil' der dazu erforderlichen Funktionalität steckt NICHT in dem hier gezeigten Code, sondern ist im Compiler-Compiler (nicht sichtbar) programmiert - der nach meinem Verständnis 'der Compiler' wäre - dessen Quellcode hier nicht gezeigt wird.
Insofern wäre die Überschrift m.E. nicht ganz korrekt - oder ich bin blind für die 'Wunder', die DIESER 'Compiler' vollbringen kann (Maschinencode für Dinge erzeugen, die nirgends sichtbar sind). Damit wollen wir es aber nun belassen. Danke nochmal. --VÖRBY (Diskussion) 18:39, 5. Aug. 2012 (CEST)
- Vielleicht doch noch die 'Erleuchtung' meinerseits? Ich denke, man muss verschiedene Generationen von Compilern unterscheiden. Meine vorgenannten 'Einwände' basieren auf dem Verständnis für einen konventionellen (2-3-GL?) Compiler. Wenn man aber unterstellt, dass auch bei der Anwendungsentwicklung, z.B. über einen Reportgenerator, der 'Quellcode' auch nicht zeigt, dass/wo Daten gelesen und Zeilen gedruckt werden, dann kann das genauso auch bei Compilern sein: Der gezeigte Code wird von einem Compiler-Programmierer erzeugt, der diesen Code als 'Compiler-Quellcode' bezeichnet - wie der Anwendungsprogrammierer die Reportspezifikation. Beide werden von 'tiefer liegenden' Softwareschichten verarbeitet, und führen zum beabsichtigten Zweck, einem Report bzw. einem Compiler.
- Nun will ich es aber wirklich gut sein lassen. Ob 'man' den Text diesbezüglich präzisieren sollte, kann ich nur schwer beurteilen. --VÖRBY (Diskussion) 13:07, 6. Aug. 2012 (CEST)
WAS tut ein Compiler?
Hallo im Artikel suche ich vergebens danach, was ein Compiler konkret tut. Mit den einzelnen Phasen wird zwar ausführlich beschrieben, WIE er das tut - aber eben nicht WAS. Ich meine damit die aktuell hier beschriebenen Aspekte. Leider auch ohne Belege und ohne Garantie auf Vollständigkeit. Sollte man den Abschnitt von dort einfach hier einfügen? --VÖRBY (Diskussion) 12:47, 4. Aug. 2012 (CEST)
- Die ersten zwei Sätze sagen es doch sehr schön. --Chricho ¹ ² ³ 18:39, 4. Aug. 2012 (CEST)
- 'Sehr schön' ist leider nicht sehr klar, denn das ist nur die pauschale Aussage 'Übersetzen'. Was das konkret ist, wird da nicht erklärt. Hattest du den obigen Link aufgerufen? Hättest du dazu konkretere Informationen? --VÖRBY (Diskussion) 19:40, 4. Aug. 2012 (CEST)
- In der Tat, hatte ich nicht angeklickt, sorry. Das (was dort steht) ist aber auch ziemlich unerheblich dafür, was prinzipiell ein Compiler ist. Gehört daher keineswegs in die Einleitung oder zu einer Definition o. ä. --Chricho ¹ ² ³ 14:36, 5. Aug. 2012 (CEST)
- Für die Definition würde ich das auch nicht verwenden. Trotzdem werden WP-Artikel üblicherweise zusätzlich zur Definition durch weitere (wesentliche) Details ergänzt. Und sowas würde ich hier einfach auch suchen, ggf. als erstes Unterkapitel von 'Details' - denn das ist auf jedenfall 'essentieller' als die Wahlfunktionen der 'Optimierung'. --VÖRBY (Diskussion) 14:43, 5. Aug. 2012 (CEST)
- In der Tat, hatte ich nicht angeklickt, sorry. Das (was dort steht) ist aber auch ziemlich unerheblich dafür, was prinzipiell ein Compiler ist. Gehört daher keineswegs in die Einleitung oder zu einer Definition o. ä. --Chricho ¹ ² ³ 14:36, 5. Aug. 2012 (CEST)
- 'Sehr schön' ist leider nicht sehr klar, denn das ist nur die pauschale Aussage 'Übersetzen'. Was das konkret ist, wird da nicht erklärt. Hattest du den obigen Link aufgerufen? Hättest du dazu konkretere Informationen? --VÖRBY (Diskussion) 19:40, 4. Aug. 2012 (CEST)
Ich habe diese Teilfunktionen (wie auch andere Detailtexte zu 'Übersetzer') aus dem Artikel Programmiersprache HIER eingefügt. Dort sollen solche Details nicht stehen, sondern über einen Hauptartikelverweis verlinkt werden (in Bearbeitung). --VÖRBY (Diskussion) 19:58, 6. Aug. 2012 (CEST)
- Also mit dem, was jetzt in der Einleitung steht, bin ich nicht so glücklich. So ein C-Präprozessor ist zweifelsohne ein Compiler für eine gewisse Sprache, und überhaupt erscheint mir das viel zu speziell für die Einleitung. Das ist dann eher spezieller Jargon, dass man im Kontext eines Builds nur einen ganz bestimmten Schritt als eigentliches Kompilieren bezeichnet. Zur Klärung des allgemeinen Compilerbegriffs trägt das nichts bei. --Chricho ¹ ² ³ 01:18, 7. Aug. 2012 (CEST)
- Hm, ein Präprozessor ist imo kein Compiler. Präprozessor-Anweisungen werden nicht "übersetzt", sondern ausgeführt, indem die entsprechenden Quellcode-Umbauten durchgeführt werden. Insofern kommt ein Präprozessor eher einem Interpreter gleich, der den Input (C-Quellcode) gemäß eingebetteter Anweisungen umbaut und als Output nun reinen C-Code weitergibt. --arilou (Diskussion) 11:31, 7. Aug. 2012 (CEST)
- Die neue Ergänzung in der Einleitung erläutert eine frühere Bedeutung von 'Compiler'. Insofern ist das in der Einleitung richtig angesiedelt. Ob dann die beiden Spielgelpunkte so stehen bleiben müssten, wäre eine andere Frage. Ich denke, das könnte man mit Fließtext an dieser Stelle besser beschreiben.--VÖRBY (Diskussion) 12:05, 7. Aug. 2012 (CEST)
Fortsetzung der Diskussion siehe nächster Abschnitt 'Zu viele Unterschiede'; gehört nicht mehr zur DIESER Fragestellung.
Die hier angesprochene Fragestellung war durch einen entsprechenden Artikeltext erledigt, wurde aber anschließend wieder revertiert - ohne Konsens. Trotzdem kann dieser Abschnitt als erledigt gelten.
Zu viele Unterschiede
- (Die langwierigen Diskussionen wurde ohne Konsens abgebrochen, der Artikeltext nicht verändert; Warten auf Neuaufnahme?)--VÖRBY (Diskussion) 13:11, 28. Sep. 2012 (CEST)
Baustein nicht archivieren hatte nicht funktioniert; einzelne Teilkapitel waren getrennt archiviert worden - was ich deshalb (Zusammenhang ging verloren) revertierte. Diskussion ohne Konsens abgebrochen, ERLEDIGT, Archivierung als Gesamttext möglich.--VÖRBY (Diskussion) 18:48, 1. Nov. 2012 (CET)
Fortsetzung vom vorherigen Abschnitt 'Was tut ein Compiler' (letzter Absatz):
Hallo, zunehmende Beschäftigung mit dem Thema verursacht auch bei mir ein wenig 'Grummeln'. Meine Sicht: Es gibt offensichtlich zu viele Varianten für Compilereinsätze, als dass man das immer in einem Text beschreiben könnte.
Zum Beispiel betrifft das bisher die Sache mit Compiler vs Interpreter vs Zusatzlinker vs Preprozessor. Das führt ihrgendwie immer zu komplizierten Formulierungen wie 'Maschinencode oder Zwischencode', der Kompromiss 'Zielcode' wäre da auch nicht immer vorteilhaft.
Noch gravierender aber unterscheidet sich unser Lemma in Szenarien für klassische Sprachen (~imperativ) vs Übersetzung neuerer Anwendungen (~deklaratkiv, OO etc.). Als Beispiel will ich nur SQL oder eine Access-Anwendung anführen: Dort läuft doch das ganze Übersetzen total anders als z.B. bei Cobol. Der bisherige Text orientiert sich aber meist am klassischen Compilerbegriff bzw. ist diesbezüglich ein intransparenter Mischtext. Hier scheinen auch die Einwände von Chricho ihre Ursache zu haben.
Habt Ihr Vorschläge, wie man diese Unterschiede gut beschreiben und darstellen könnte? Eigene Artikel scheinen mir auch keine gute Lösung zu sein.
Grüße von --VÖRBY (Diskussion) 09:13, 7. Aug. 2012 (CEST)
- Sorry, kenn' mich nur mit der "klassischen Variante" halbwegs aus.
- Im Moment seh' ich keinen sinnvolleren Weg, als die verschiedenen Varianten hier im Artikel aufzudröseln.
- Vielleicht kommt die Erkenntnis ja dann. --arilou (Diskussion) 11:44, 7. Aug. 2012 (CEST)
- Ich denke, es ist nicht zielführend, anzufangen, hier ganz spezielle Begrifflichkeiten zu wählen, die allerhand vom Compilerbegriff ausschließen, nur weil man die normalerweise bei einem anderen Namen nennt. Ein Präprozessor ist definitiv ein Compiler, die Sprache, die der übersetzt, ist aber eben so angelegt, dass das Quellprogramm den Kompilierungsvorgang recht direkt steuert, das ist bei zahlreichen Sprachen mit Metaprogrammierungsfähigkeiten nicht anders. Eine Sache, bei der man sich wohl entscheiden muss, ist, ob man nur die Software zählen lässt, die für den Weg zur Ausführung gedacht ist, oder allgemeine Übersetzer zwischen formalen Sprachen (was auch Decompiler einschließen würde). Das Drachenbuch unterscheidet zwischen compilers (erstes Ding, „But, before a program can be run, it first must be translated into a form in which it can be executed by a computer. The software systems that do this translation are called compilers“.) und „language translators“. Ein C-Präprozessor wäre aber zweifelsohne in beiden Fällen dabei, denn er ist nunmal kein Textverarbeitungstool sondern dient der Überführung in Richtung ausführbarer Code. Wie auch immer, wie ein Präprozessor heißt, ist gar nicht mal so wichtig: Diese (zwei Sätze vorher) begriffliche Unterscheidung müsste man in der Einleitung klar machen, nicht irgendwelche Spezialfälle. --Chricho ¹ ² ³ 12:03, 7. Aug. 2012 (CEST)
- Deine Anmerkungen zeigen u.a. das Dillemma: Dein englisches Zitat schreibt '... which can be executed by a Computer'. Dann sagst du, ein C-Präprozessor gehöre 'zweifelsohne' dazu - und schreibst, dieser erzeuge Code 'in Richtung' ausführbarer Code. Das ist ein erheblicher Unterschied. Was die Einleitung betrifft, habe ich den Absatz umgetextet und hoffe, so passt es eher. Ansonsten zeigt auch diese Diskussion, dass im Artikel die dem Sachverhalt angemessene Struktur - die beim Leser Klarheit bringen würde - noch fehlt.--VÖRBY (Diskussion) 12:24, 7. Aug. 2012 (CEST)
- Es geht darum, dass das letztliche Ziel eine Ausführung eines Programms ist, Zwischenstufen zählen natürlich auch. --Chricho ¹ ² ³ 12:35, 7. Aug. 2012 (CEST)
- Deine Anmerkungen zeigen u.a. das Dillemma: Dein englisches Zitat schreibt '... which can be executed by a Computer'. Dann sagst du, ein C-Präprozessor gehöre 'zweifelsohne' dazu - und schreibst, dieser erzeuge Code 'in Richtung' ausführbarer Code. Das ist ein erheblicher Unterschied. Was die Einleitung betrifft, habe ich den Absatz umgetextet und hoffe, so passt es eher. Ansonsten zeigt auch diese Diskussion, dass im Artikel die dem Sachverhalt angemessene Struktur - die beim Leser Klarheit bringen würde - noch fehlt.--VÖRBY (Diskussion) 12:24, 7. Aug. 2012 (CEST)
Klarheit in unser Lemma könnten einzelne Beschreibungen je Szenario sein. Ein Beispiel dafür:
- Szenario IBM-Großrechner mit 3GL:
- Der Compiler übersetzt den per Texteditor erzeugten, optional von einem Precompiler ergänzten Quellcode für genau ein 'Programm' (PGM X) und erzeugt dabei prozessorspezifischen Objektcode. Soll das Programm direkt vom Betriebssystem aufrufbar sein, so wird dieser Code mit dem Linkage Editor um sprachspezifische Module ergänzt und der Objektcode aller aufgerufenen Unterprogramme hinzugebunden. Ergebnis ist ein ausführbares Lademodul für das 'Programm X'. Für nicht getrennt aufrubare Unterprogramme wird nur der Objektcode erzeugt - der nur beim Linken der sie aufrufenden Programme verwendet wird. Siehe auch Grafik - könnte folgen.
Wäre das ein Ansatz? --VÖRBY (Diskussion) 19:53, 7. Aug. 2012 (CEST)
Nach dem Diskussionsstand, auch in den nachfolgenden Abschnitten, scheinen sich alle Beteiligten darin einig, dass der Artikel verbesserungsfähig ist. Als nächsten Schritt schlage ich vor, eine kleine ToDo-Liste zu führen, wo überall Veränderungen / Ergänzungen stattfinden sollten. Danach könnten wir feststellen, wer sich wofür kompetent fühlt und Textentwürfe zuerst diskutieren und dann in den Artikel übernehmen. --VÖRBY (Diskussion) 11:41, 9. Aug. 2012 (CEST)
ToDo's
Nachfolgend sind einige Stichworte genannt (zum Teil in Frageform), zu denen sich m.E. (VÖRBY) im Artikeltext bzw. den jeweils genannten Abschnitten Aussagen finden sollten. Unter 'Relevanz' können weitere Mitautoren ihre Meinung (zur Relevanz) eintragen. Die inhaltlichen Texte dazu sollten im Abschnitt #Entwurfstexte eingestellt werden.
(bitte bei Bedarf entsprechend ergänzen / anpassen)
- Einleitung:
- Erwähnen, dass sich der Begriff im Zeitverlauf und bedingt durch zahlreiche Veränderungen in der Computer- und Entwicklungsarchitektur ebenfalls stark verändert hat. >>ERL. VÖRBY s.u.
- Relevanz: noch kein Feedback
- Klare Kriterien benennen, wonach man feststellen kann, was als Compiler gilt
- Relevanz: noch kein Feedback
- Ist ein Interpreter eine 'Art von Compiler' oder eine 'Abgrenzung zu Compiler', also kein Compiler? Gilt das für beide Versionen von Interpretation (Befehle einzeln bzw. en-bloc)?
- dto: für Linker geltend
- dto: für beide Stufen bei Erzeugung von Zwischencode bzw. Maschinencode daraus?
- dto: nur wenn Maschinencode erzeugt wird oder bei jeder Übersetzung 'in Richtung' Maschinencode/Ausführung? Was bedeutet die bisherige Formulierung 'Insbesondere ... Maschinencode' für die Definition?
- Erwähnen, dass man den Begriff nach engerer (z.B. Maschinencode erzeugen) oder nach weiterer Definition (jede Art von Konvertierung) interpretieren kann
- Relevanz: noch kein Feedback
- Übersetzungsszenarien:
- Entsteht beim Kompilieren bzw. Interpretieren inhaltlich identischer Code oder 'etwas ganz anderes'? ERLED 16.8.: Jetzt Links auf AOT/JIT-Compilierung
- Relevanz: noch kein Feedback
- Es gibt noch ein drittes Grundprinzip: Die Verwendung von Quellcode-Spezifikationen über Laufzeitsysteme - die weder Compilierung noch Befehls-Interpretation ist. ERLED 16.8.: Laufzeitumgebungen eingefügt
- Relevanz: noch kein Feedback
- Ablaufbeispiele: (konkrete Beschreibungen - neben den nur global/allgemein formulierten Übersetzungsszenarien):
- Ergänzen weiterer relevanter Beispiele, zB. C, Java, LZ-Umgebung mit MS Access (ERL)
- Relevanz: noch kein Feedback
- Allgemeine Beschreibung unter 'Übersetzungsszenarien' entsprechend verallgemeinert belassen / umformulieren ERLED 16.8.
- Relevanz: noch kein Feedback
- Sonstiges:
- Gibt es Unterschiede zwischen imperativen, deklarativen, OO- und anderen Paradigmen (die Compilierung betreffend)? Evtl. sind das ~ die Unterschiede zwischen Laufzeitumgebung und Kompilierung??
- Relevanz: noch kein Feedback
- Belege für die wichtigen Aussagen im Artikel nachtragen
- Relevanz: noch kein Feedback
Diskussionen zu ToDo's
Allgemeines
Hallo Mitstreiter, die Diskussion hier läuft ja mal wieder recht zäh; scheint WP-spezifisch zu sein. Abgesehen von der Zielsetzung, den Artikel zu verbessern, scheint es aber sehr unterschiedliche Meinungen zum WIE und zum VORGEHEN zu geben. 'Mein Ansatz' war deshalb, zunächst zu definieren, was geändert werden sollte; bei den ToDo's sind diese Punkte im offenen Sprachstil formuliert. Allerdings habe ich noch kein 'Bild' davon, wie weit diese Punkte aus eurer Sicht relevant für den Artikel sind; ich selbst sehe diese Relevanz. Da die WP kaum andere Mittel außer Fließtext bietet, schlage ich vor, direkt nach jedem dieser Punkte kurze Statements zur Relevanzbeurteilung (mit J/N oder sonstwie, ggf. kurze Begründung) einzustellen. Nicht als relevant eingestufte Punkte könnte man danach zwar immer noch diskutieren, aber zunächst sollten es die 'relevanten' bleiben, für die dann 'Entwurfstexte' entstehen sollten. Ich grüße euch: --VÖRBY (Diskussion) 09:48, 17. Aug. 2012 (CEST)
Interpreter ./. Compiler
@VÖRBY: Ich probiere es mal mit einem Schwung Antworten.
- Antworten von VÖRBY in small angefügt.
- Interpreter. Das sind m.E. zu viele Details, ich hatte an grundsätzliche Unterschiede zwischen Interpretation und 'Compilierung' gedacht.
- Das hängt alles sehr davon ab, was da ausgeführt werden soll.
- Im Regelfall ist der Interpreter ein laufendes Anwendungsprogramm, das die interaktiv eingetippten oder über Skript/Stapel eintreffenden Statements einliest und nach jedem Statement die vorgesehene Aktivität entfaltet. >>Der I. ist ist doch immer ein laufendes Anwendungsprogramm.
- Der Arm des Roboters kann gehoben werden oder ein Kringel kann auf den Bildschirm gezeichnet werden.
- Ein Arithmetik-Programm könnte das Resultat von
5 * 7 + 9 - x =
- nach Drücken von Enter auf den Bildschirm schreiben, oder als Wertzuweisung diese vornehmen:
y = 5 * 7 + 9 - x
- Bekannt ist der Kommandozeilen-Interpreter der verschiedenen Betriebssysteme (shell, console):
- Jedes Statement fängt mit einem Befehlswort an, danach folgen optional spezifische Parameter.
- Inspiziere bei jedem Statement zunächst das Befehlswort, ob es einem intrinsischen (eingebauten) Befehl entspricht, etwa
set
oderecho
oderhelp
und schließlichexit
. Führe einen erkannten intrinsischen Befehl mit den Parametern aus (ggf. ein zugeordnetes System-Unterprogramm aufrufen). Auch Kontrollstrukturen wären im Skript-Modus denkbar. - Wenn Befehlswort unbekannt, durchsuche der Reihe nach die für ausführbare Programme vorgesehenen Dateipfade, ob sich darin eine ausführbare Datei befindet, deren Name dem Befehlswort entspräche. Wenn gefunden, führe dieses Programm mit den Parametern aus.
- Wenn nichts gefunden, dann Fehlermeldung.
- Analog ein SQL-Dialog, etwa mit dem guten alten dBase. Setze die Suche in der Datenbank um und führe ggf. Veränderungen aus; zeige Ergebnisse.
- Was lernt uns das?
- Es erfolgt nicht zwangsläufig eine Übersetzung in eine Maschinensprache oder eine ausführbare Programmeinheit. >> Doch, ALLES was auf dem Computer ausgeführt wird, ist - letztlich - Maschinencode!!
– Nee. Siehe unten. Der Maschinencode ist schon längst vorhanden. /P.C. - Interpreter können sowohl nach imperativem wie auch nach deklarativem Paradigma tätig werden. Entscheidend ist die sofortige Umsetzung nach Fütterung.
- Es erfolgt nicht zwangsläufig eine Übersetzung in eine Maschinensprache oder eine ausführbare Programmeinheit. >> Doch, ALLES was auf dem Computer ausgeführt wird, ist - letztlich - Maschinencode!!
- Kompilieren.
- Übersetze einfach nur in ein maschinennäheres Sprachniveau und hebe das Ergebnis hübsch auf; führe nichts aus.
- Objektorientiert.
- Das ist eher eine trickreiche und möglichst narrensichere Verwaltung, welche Funktion mit den Daten welchen Objekts ausgeführt werden soll. Sie hilft dem Menschen, den Durchblick zu behalten. Was letztlich ausgeführt wird, ist prozedural/imperativ; eine Funktion, gern auch Methode genannt: ein schlichtes klassisches Unterprogramm. >> Trotzdem: Läuft da beim Compilieren / Interpretieren etwas grundsätzlich anders? Was?
- Prozedural, algorithmisch, imperativ:
- Die Aktivitäten aus diesem Dunstkreis sind sehr ähnlich dem, was in weniger gut für Menschen lesbarer Form der Maschinencode ausführt. Das in einer Hochsprache geschriebene einzelne Statement wird (nach Optimierungen) in Maschinensprache übersetzt, sieht in der Struktur dem Quellcode relativ ähnlich.
- Deklarativ.
- Das ist ein ganz anderes Geschäft.
- Dazu gehört eigentlich immer ein sogenannter Solver, oder sowas Ähnliches (in manchen Bereichen Engine genannt). Er nimmt die Problembeschreibung entgegen und löst dann die damit verbundene Aufgabe. Dahinter können umfangreiche mathematische Verfahren stecken. Was dann als ausführbarer Maschinencode passiert, hat mit den Statements des Quellcode rein gar nichts mehr zu tun. Der wesentliche Teil des Maschinencode stammt aus den intern eingebauten Problemlösungstechniken; der Quellcode liefert eher Parameter und Daten für die Problemlösungsfunktion. >> Ja, sowas Ähnliches in 'artikelfähigem' Text wäre m.E. passend.
- Man könnte sagen: Bei Deklarativem Paradigma wird vom Menschen das (inverse?) Problem beschrieben; der Solver macht eine Invertierung, um sich den Lösungsalgorithmus quasi selbst zu schreiben. Hingegen wird beim Imperativen Paradigma der Lösungsalgorithmus direkt vom Programmierer hingeschrieben. >> Das ist schon bei Programmierparadigma so festgelegt. Was ist evtl. beim Compilieren anders?
- Es mag zwar eine kompilierende (syntaktische) Umformung eines deklarativen Quelltextes geben, etwa im Sinne einer Fehlerkontrolle und kompakteres Format, aber ein vergleichbares Kompilieren dürfte eher selten sein.
Zwecks Verständlichkeit jetzt etwas grob runtergebrochen und freihändig aus dem Ärmel geschüttelt; schönes Wochenende --PerfektesChaos 15:16, 11. Aug. 2012 (CEST)
- Hallo 'Perfektes Chaos', danke für die Anmerkungen. Die ToDo's sind (aus meiner Sicht) nur als Beitrag zu einer 'Top-Down-Vorgehensweise' gedacht, d.h. die einzelnen Punkte sind lediglich 'Merker', zu denen sich letztlich im Text des Artikels Aussagen, möglichst mit Beleg finden sollten. Solche Texte könnten/sollten im Abschnitt #Entwurfstexte (jeweils mit passender Überschrift oder Verweis zum Artikelabschnitt) eingestellt und ggf. noch diskutiert werden, und dann final in den Artikeltest wandern. Deine Inhalte können sicher dazu beitragen, aber du siehst sie in dieser Form wahrscheinlich auch nicht als Artikeltext - oder? Natürlich darf man auch über diese ToDo's diskutieren. Deshalb habe einige Anmerkungen meinerseits oben in deinen Texten eingefügt. Lass uns aber erst die ToDo-Liste fertigmachen und dann entsprechende Textpassagen formulieren.
- Schönen Sonntag wünscht: --VÖRBY (Diskussion) 18:21, 11. Aug. 2012 (CEST)
Zurzeit ist es erstmal nur ein internes Herausarbeiten der Sachverhalte. Dass daraus ein für die Außenwelt geeigneter Text wird, ergibt sich erst nach interner Klärung.
- Die momentane Hauptschwierigkeit liegt offenbar in der Abgrenzung Interpretierer ./. Compiler; ich probiere es daher noch einmal:
- Beim Interpretierer sind alle ausführbaren Aktivitäten schon Monate und Jahre vorher als Maschinencode der Zielplattform eingebaut worden und schlummern in fertigem Zustand. Wenn ein Anwender mit seinen interaktiven oder geskripteten Statements kommt, dann sind diese Zeichenketten nur Daten. Die geeigneten vorbereiteten Aktivitäten werden mit den aktuellen Parameterwerten befüllt und vom Interpreter als eigenständigem, ausführbarem Programm exekutiert. Irgendein neuer Code entsteht dabei nicht, und üblicherweise bleibt von der Aktivität des Anwenders auch nix über, zumindest nicht in Form von übersetzten Befehlscode-Dateien.
- Der Compiler übersetzt Statements (die identisch mit den soeben in den Interpretierer gefüllten sein können) von einem Sprachniveau in ein anderes, hier ein maschinengeeigneteres. Das Resultat wird als Datei zur weiteren Verwendung abgelegt. Dabei muss die Plattform der Sprachniveaus noch nicht einmal mit der aktuellen Plattform übereinstimmen. Ausgeführt wird nichts.
- Klipp und klar: Ein Interpreter ist kein Compiler. Beide machen etwas völlig anderes, bloß möglicherweise mit dem identischen Quellcode (selten).
- Objektorientierung verändert nichts Grundsätzliches an den Mechanismen von Interpretern und Compilern.
- Prinzipiell darf man bei deklarativen Sprachen von Compiler reden. Wenn ich die mir bekannten Fälle durchgehe, verwendet man aber seltener in diesem Zusammenhang die Vokabel „Kompilieren“. Bei Haskell als nicht-imperativ aber funktional noch am ehesten; auch LISP lässt sich funktional einsetzen, aber auch klassisch prozedural und wird kompiliert, wobei der Anwender separat die Lösungsprozedur schreiben müsste. Bei Prolog wird das konkrete Problem von einem Interpreter verarbeitet.
Hoffentlich wieder einen Schritt weiter --PerfektesChaos 20:24, 12. Aug. 2012 (CEST)
Interpreter vs deklarativer Code
(Fortsetzung vom vorherigen Abschnitt)
Danke für deine Anmerkungen. Dass das Interpretieren etwas ganz anderes ist als das Übersetzen, wird jetzt erst richtig sichtbar; im bisherigen Text ist z.B. von 'Befehl-für-Befehl' übersetzen oder von 'en-bloc' die Rede. Dagegen werden, wie du schreibst, ganze, schon vorhandene Programme ausgeführt - die die Sprachkonstrukte lediglich als Parameter verwenden. Es wird also wirklich nichts (Neues) erzeugt! Allerdings glaube ich, dass dieser Unterschied nicht zufällig von 'Kompilieren vs. Interpretieren' abhängig ist, sondern dass diese Art von Interpretieren einfach bei deklarativem Code praktiziert wird - und auch gar nicht anders möglich ist. Ich werde dazu hier noch ein Beispiel einfügen.
Insgesamt sind wir mit diesem Punkt wirklich 'einen Schritt weiter'. --VÖRBY (Diskussion) 08:47, 13. Aug. 2012 (CEST)
- Hier ergänze ich um Beispiele (Bezug: MS Access):
- Bei deklarativer Programmierung wird das WAS definiert. Da ein Computer aber nur einen Befehl nach dem anderen abarbeiten kann, braucht es eine Zwischenkomponente, die diese Art von WIE erzeugt.
- Beispiel Reportgenerator: Die Reportspezifikation definiert lediglich, wie der Report aussehen soll, seine Datengrundlagen etc. In der Laufzeitumgebung gibt es einen 'Eventmanager', der ein 'richtiges Programm' ist, das über das Betriebsswystem vom Prozessor ausgeführt wird, das zunächst mit dem einzelnen Report nichts zu tun hat, aber 'weiß', welcher Report ausgeführt werden soll. Bei Eintritt bestimmter Ereignisse (die es feststellt) bezieht sich dieses Programm auf die deklarativen Festlegungen und füllt (zum Beispiel) ein Datenfeld im Report (bzw. alle dort vorgesehenen Datenfelder) mit bestimmten Daten in bestimmten Formaten. Evtl. vorhandener VBA-Code (für ein bestimmtes Objekt/Ereignis) könnte dagegen Befehl für Befehl compiliert/interpretiert werden; das ist aber dann imperativer Code!
- Beispiel SQL: Ein mächtiges Datenbankprogramm der Laufzeitumgebung kann alle in SQL möglichen Funktionen ausführen. Es benutzt dazu die Angaben aus dem SQL-Code in seinen eigenen Befehlen als Quelle. 'Übersetzen' in Maschinenbefehle kann man SQL-Code nicht.
- In beiden Fällen wird der deklarative Code nicht 'übersetzt' sondern nur 'berücksichtigt' (also wie normale 'Daten' als Parameter verarbeitet). Das wäre also im Wortsinn 'interpretierter Code', aber keine 'Übersetzung' des Quellcodes in Maschinenbefehle, der Interpreter hier also kein 'Compiler'.
- Fazit:
- Es gibt wohl mehrere Arten von 'Interpretern': Befehl-für-Befehl umwandeln; Maschinencode en-bloc erzeugen (praktisch identisch mit Compilieren); Code lediglich interpretativ verwenden. Zumindest Letzteres ('Ausführung über Laufzeitumgebungen') sollte anders genannt und/oder aus der Definition von 'Compiler' abgegrenzt werden.
- Deklarativer Code wird gänzlich anders umgesetzt - als z.B. imperativer.
- Somit sollten wir die Lemma-Texte zu diesem ToDo entsprechend als Entwurf vorbereiten können. Magst du oder soll ich? Grüße von --VÖRBY (Diskussion) 11:26, 13. Aug. 2012 (CEST), ergänzt: --VÖRBY (Diskussion) 18:44, 13. Aug. 2012 (CEST)
Komplex-zu-Einfach
Ich würde gerne anführen, dass Compiler praktisch immer aus einer komplexen (Hoch-)Sprache in eine einfachere Sprache übersetzen. Und wenn nicht, dann werden in der Zeilsprache zumindest gleich-einfache oder einfachere Konstrukte verwendet als in der Quellsprache. Hat jemand dazu eine Quelle?
In der Optimierung wird (selten!) eine Komplexitäts-Erhöhung vorgenommen (z.B. Macro-OP-Fusion im Prozessor, oder Compiler#Einsparung von Maschinenbefehlen).
Dass in der Zielsprache tatsächlich komplexere Konstrukte verwendet werden, als in der Quellsprache, kenn' ich allenfalls aus (nichtmenschlichen) Übersetzern menschlicher Sprachen.
--arilou (Diskussion) 12:06, 13. Aug. 2012 (CEST)
- Oder: Ein Decompiler kann das, wenn zuvor bekannt ist, dass die ursprüngliche Quellsprache dieselbe war, wie die Zielsprache des Decompilers, und er das entsprechende Background-Wissen hat. Keine Ahnung, was ein Decompiler macht, wenn man versucht, ein Maschinenprogramm, das mal Pascal war, zu C-Code zu decompilieren... --arilou (Diskussion)
- Wird der erzeugte Code für den Quellbefehl 'A = B / (C(Index) / 100)' (mit evtl. erforderlichen Formatkonvertierungen und Kommastellen-Adjustierungen) tatsächlich 'einfacher' sein als dieser 'komplexe Ausdruck'? Man müsste also 'komplex' und 'einfach' irgendwie anders benennen.--VÖRBY (Diskussion) 18:44, 13. Aug. 2012 (CEST)
- Hm, es gibt gegenläufige Bedeutungsfelder:
- Schwierig für den Menschen zu verstehen (=komplex) vs. Einfach für den Menschen zu verstehen (=einfach). Dabei müsste eine Hochsprache immer als "einfach" gelten, und Assembler als "komplex/schwierig".
- Operationen mit viel Hintergrundwissen/-aktivitäten und viel Flexibilität (=komplex) vs. Befehle mit einfacher Bedeutung und fester Schnittstelle (=einfach). Dabei ist die Hochsprache dann "komplex", da ihre Operationen alle möglichen Checks, Wandlungen usw. im Hintergrund durchführen, wohingegen eine Assembler-Anweisung eine einfache, feste Bedeutung haben.
- Daher stimm' ich zu, dass die beiden Begriffe "komplex" und "einfach" problematisch sind.
- --arilou (Diskussion) 15:00, 14. Aug. 2012 (CEST)
- Hm, es gibt gegenläufige Bedeutungsfelder:
Aktionismus von Benutzer 0x
Hallo Leute, wir strampeln uns hier einen ab, um den Artikel zu verbessern. Dies alles interessiert 0x überhaupt nicht, sondern er ändert einfach nach seiner Meinung und verschiebt bereits diskutierte Textteile. Ich habe in seiner Diskussionsseite meine Kritik formuliert und überlasse es euch, daraus eure Schlüsse zu ziehen. Vielen Dank jedenfalls für die ernsthafte Mitdiskussion hier. Vorläufig steige ich aus diesem Lemma aus, so lohnt sich der Aufwand nicht. --VÖRBY (Diskussion) 11:22, 15. Aug. 2012 (CEST)
- Tut mir leid, wenn ich zu offensiv war. Habe auf meiner Disk auch geantwortet. Ich halte die Reaktion artikelmäßig aber für etwas übertrieben. Siehe meine Disk. ʘχ (Diskussion) 13:56, 15. Aug. 2012 (CEST)
Entwurfstexte
(sprachlich-stilistische Verbesserungen bitte ggf. direkt einstellen, inhaltliche Aspekte bitte unten diskutieren)). Bei Übernahme in den Artikeltext sind/wären je nach schon vorhandenem Text ggf. weitere Anpassungen erforderlich..
==Textfragmente zur Einleitung==
Entwicklungen in der Computertechnik wirkten auch auf die Compilierungsverfahren:
Die rasante Entwicklung in der Computertechnik, während der Verbesserungen in der Hardware neue Möglichkeiten in der Software erlaubten (die wiederum nach 'stärkerer' Hardware verlangte), wirkte auch auf die Softwaretechnik und die Programmiersprachen – die wiederum die Verfahren der Codekonvertierung beeinflussten. So sind bis heute ~hochgradig unterschiedliche Verfahren und auch Begriffe für den Sachverhalt 'Compilieren' im Einsatz. Gemeinsam ist all diesen Techniken, dass der vom Programmierer erzeugte Quelltext letztlich vom Rechner ausgeführt werden kann.
Komplex-zu_Einfach: (Lt. Anregung von Arilou hier)
Hier noch Textvorschlag / Textfragment einstellen
=== Teilfunktionen bei der Übersetzung ===
(Texte waren entfernt worden. Sie sind aber, besonders für Laien, relevant!)
Ohne auf Details zu bestimmten Programmiersprachen/Compilern einzugehen, wird beim Übersetzen des Quellcodes in Maschinencode im Wesentlichen folgende Funktionalität ausgeführt:
- Prüfung des Quellcodes: Die Einhaltung der Syntaxregeln der jeweiligen Sprache, die Verwendung gültiger Schlüsselwörter und gültiger Bezeichner wird überprüft. Festgestellte Fehler werden protokolliert, ein (gültiger) Zielcode wird nicht erzeugt.
- Protokollieren des Quellcode in Listenform, ggf. mit alphabetischem Inhaltsverzeichnis, Crossreferenz etc.
- Reservieren von Speicherplatz: Alle definierten Datenbereiche werden so angelegt wie sie im späteren internen Speicher liegen werden. Der Übersetzer 'kennt' für jedes Datenfeld die Position, die Länge und das Datenformat und verwendet diese Informationen beim Erzeugen der Befehle, die die einzelnen Felder ansprechen.
- Belegen der Inhalte von Konstanten
- Umwandeln der Befehle des Quellcodes in adäquate Befehle der Maschinensprache:
- Aus den sprachspezifischen Befehlscodes wird Maschinenbefehlscode
- Aus logischen Feldnamen in diesen Befehlen werden numerische Adress- und Längenangaben.
- In der Regel kann der Quelltext-Befehl nicht 1:1 umgewandelt werden, sondern erfordert in der Zielsprache mehrere Befehle - z. B. wenn Formatkonvertierung erforderlich ist, wenn Array-Adressen berechnet werden müssen, zur Zuweisung von Registeradressen etc.
- Für logische Ausdrücke im Quellcode (wie Klammern, Und/Oder, arithmetische Regeln (z. B. 'Punkt vor Strich'), Wenn/Dann/Sonst; auch mehrfach geschachtelt) werden alle erforderlichen Befehle erzeugt; für die korrekte Reihenfolge der Verarbeitung (z. B. bei alternativ auszuführenden Verarbeitungszweigen) werden entsprechende Sprungbefehle eingefügt.
- Für sprachspezifische oder funktionale, zur Ausführung erforderliche Subroutinen/Module werden Aufrufbefehle eingefügt – inkl. der Übergabe der formalen Parameter.
== Übersetzungsszenarien == vormals: >Zeitpunkt der Übersetzung > Ablaufprinzipien
(Texte waren aus dem Lemma entfernt worden; hier Wiedereinstellung nach Anpassung)
Bezüglich des Vorgangs der Übersetzung von Quellcode in Maschinencode – der zur Ausführung von Programmen grundsätzlich erforderlich ist – lassen sich die folgenden Grundszenarien unterscheiden:
- Ahead-of-time-Kompilierung: Die Übersetzung findet einmalig mit dem Programmtext als Ganzem statt, der erzeugte Code kann anschließend beliebig oft ausgeführt werden. Der Compiler liest als Dateneingabe den Programm-Quellcode und liefert als Datenausgabe den Maschinencode (z. B. Objectcode, EXE-Datei, „executable“) oder einen Zwischencode. Die Kompilierung findet in der Regel innerhalb der Prozesse des Releasemanagements statt.
- Just-in-time-Kompilierung: Der Programmtext wird direkt vor jedem Programmlauf neu übersetzt; die Erzeugung von Maschinencode kann 'Befehl-für-Befehl' erfolgen (mit sofort anschließender Ausführung der erzeugten Befehle) oder ebenfalls eine Komplett-Kompilierung sein. Vorteil: Die Compilierung kann bei Bedarf unterschiedliche Zielarchitekturen beliefern.
- Interpretation zur Laufzeit: Z. B. mit JVM, .NET CLR oder MS Access) wird der Programmcode während der Ausführung lediglich interpretiert. Man spricht von einer interpretierten Sprache, die Quellanweisungen werden nicht wirklich in eine andere Zielsprache übersetzt, sondern bei der Ausführung als Parameter berücksichtigt.
Daneben werden verschiedene Varianten dieser Grundkonzepte praktiziert:
- Zum Teil erzeugen Compiler einen noch nicht ausführbaren Programmcode, der von nachfolgenden Systemprogrammen zu ausführbarem Maschinencode umgeformt wird. Hier sind die Konzepte „plattformunabhängiger Zwischencode“ (z. B. im Rahmen der Software-Verteilung) und „plattformgebundener Objectcode“ (wird zusammen mit weiteren Modulen zu ausführbarem Code, z. T. Lademodul genannt, zusammengebunden) zu unterscheiden.
- Mit Precompilern können spezielle, in der Programmiersprache selbst nicht vorgesehene Syntax-Konstrukte (zum Beispiel Entscheidungstabellen) bearbeitet und, vor-übersetzt in die gewählte Programmiersprache, im Quellcode eingefügt werden.
Zur Steuerung des Übersetzens kann der Quelltext neben den Anweisungen der Programmiersprache zusätzliche spezielle Compiler-Anweisungen enthalten. Komplexe Übersetzungsvorgänge werden bei Anwendung bestimmter Programmiersprachen / Entwicklungsumgebungen durch einen Projekterstellungsprozess und die darin gesetzten Parameter gesteuert.
== Ablaufbeispiele: ==
Zum besseren Verständnis der möglichst allgemeingültig formulierten Beschreibung unter Übersetzungsszenarien werden nachfolgend konkrete Beispiele für den Ablauf der Übersetzung bei Einsatz bestimmter Entwicklungstechniken beschrieben.
===Szenario IBM-Großrechner mit 3GL===
Der Compiler übersetzt den per Texteditor erzeugten, optional von Precompilern ergänzten Quellcode für genau ein 'Programm' (PGM X) und erzeugt dabei prozessorspezifischen Objektcode. Soll das Programm direkt vom Betriebssystem aufrufbar sein, so wird dieser Code mit dem 'Linkage Editor' um sprachspezifische Systemmodule ergänzt und der Objektcode aufgerufener Unterprogramme hinzugebunden. Ergebnis ist ein ausführbares Lademodul für das 'Programm X'. Für nicht getrennt aufrubare Unterprogramme wird nur der Objektcode erzeugt - der nur beim Linken der sie aufrufenden Programme verwendet wird.
Im Quellcode können Befehle enthalten sein, die nicht zur Programmiersprache selbst gehören (z. B. SQL-Code) und aus denen eigener Objektcode erzeugt wird. Diese Befehle werden im Quellcode meist 'auskommentiert' und durch den Aufruf des adäquaten Unterprogramms ergänzt, das beim Linken und/oder bei der Ausführung aufgerufen wird.
===Szenario Datenbankanwendungssysteme ===
Anders als bei klassischen, meist imperativen Programmiersprachen wird bei Software, die mit Datenbankanwendungssystemen (hier im Beispiel MS Access) erstellt wird, keine Compilertechnik im Sinn von Codeübersetzung angewendet. Bei dieser Art von Software wird vom Softwareentwickler grundsätzlich nur definiert, WAS entstehen soll (z. B. Formulare, Reports etc.), keine Befehle im imperativen Sinn. Zum 'Programmablauf' wird die Datenbanksoftware (= Systemsoftware) ausgeführt, von der die 'programmierten' Spezifikationen beim Eintritt bestimmter Ereignisse lediglich 'berücksichtigt' werden. Nach ähnlichem Prinzip wird Software auch beim Einsatz von Reportgeneratoren verarbeitet.
Ausnahme: Falls in der Anwendung VBA-Anweisungen implementiert wurden, werden diese bei der ersten Ausführung der Anwendung (automatisch und einmalig) kompiliert, der optimierte Zwischencode, hier „P-Code“ genannt, wird in der MDB gespeichert und über einen Interpreter (Befehl für Befehl) ausgeführt.[1]
Die Datei mit dem 'Anwendungscode' (mit der Endung *.MDB) enthält alle spezifizierten Angaben wie Datendefinitionen, Datenzugriffe, VBA-Befehle, Makros usw.; optional können darin auch die Anwendungsdaten gespeichert werden.
== Einzelnachweise == temporär
Diskussionen zu Entwurfstexten
Allgemeines
Ich habe mal meine Meinung dazu geschrieben, allerdings unten als eigener Abschnitt. ʘχ (Diskussion) 14:39, 16. Aug. 2012 (CEST)
Access-Beispiel
Was sagt uns dieses Access-Beispiel bitte über Compiler aus? Ich sehe überhaupt nicht, was jetzt damit klar gemacht werden soll? --Chricho ¹ ² ³ 02:36, 14. Aug. 2012 (CEST)
- Als Klarstellung, dass es "vom Quellcode zur Ausführung" auch ein Szenario gibt, das nichts mit Compiler und Befehls-Interpreter zu tun hat - wie im letzten Satz auch ausgedrückt wird. Gruß von --VÖRBY (Diskussion) 20:45, 14. Aug. 2012 (CEST)
- Was macht denn die sogenannt „Laufzeitumgebung MS Access“ anderes als interpretieren (oder evtl. kompilieren)? --Chricho ¹ ² ³ 21:30, 14. Aug. 2012 (CEST)
- Ja, Chricho, du hast Recht. Aber im bisherigen Text war das JIT-Kompilieren und das Laufzeit-Interpretieren nicht ausreichend voneinander abgegrenzt. Beim JIT-Kompilieren werden Befehle des Programms übersetzt, bei Laufzeitumgebungen - z.B. bei Access - ist diese selbst 'Programm' (das z.B. Daten liest, Gruppenwechsel feststellt ...), das lediglich die definierten Properties (keine Befehle!) 'verwendet'. Im aktuellen Textentwurf ist diese Unterscheidung berücksichtigt, mit Klarstellung, dass hier keine Compilierung vorliegt - eber eben eine Variante "vom Quellcode zur Ausführung". --VÖRBY (Diskussion) 17:47, 16. Aug. 2012 (CEST)
- So eine "Access-Anwendung" überhaupt noch als "eigenständiges Programm" zu bezeichnen, geht auch so langsam richtung grenzwertig. Viele Anwendungen bieten die Möglichkeit, ihre Oberfläche anzupassen und zu konfigurieren, und mit Skripten Menüpunkte dazuzubauen. So einen Satz "Einstellungen und Skripte" als Datei zu speichern, ergibt nicht wirklich ein "ausführbares Programm". Access mag da etwas drüber hinausgehen, aber ~nuja~ grenzwertig eben.
- Aber das ist natürlich mein POV, und daher praktisch das Gegenteil von Ox' (sinnvollerweise geforderter) Vorgehensweise... --arilou (Diskussion) 09:07, 17. Aug. 2012 (CEST)
Hallo Arilou. Unsere Disk hier zeigt die Vielfalt des Lemmas. Dass mit Access 'Anwendungen' (~Programme) entwickelt werden (können), sollte außer Frage stehen. Erstens denke ich, das kann deutlich über das "Anpassen der Oberfläche" hinausgehen, zweitens wäre auch das, ggf. zusammen mit dazugebauten Menüpunkten jedenfalls eine Art von 'Softwareentwicklung' mit dem Ergebnis 'Software', die letztlich ausgeführt werden soll/muss. Um die Verfahren dazu geht es hier im Lemma. Was ist daran 'grenzwertig'? Es gibt eben diese ungeheuer große Bandbreite, und m.E. sollte das Lemma dies berücksichtigen, mindestens in der Form, dass man z.B. das Ausführen über LZ-Umgebungen vom Begriff 'Übersetzen/Compilieren' explizit abgrenzt. Grüße von --VÖRBY (Diskussion) 09:34, 17. Aug. 2012 (CEST)
Zu den Bildern
(Im folgenden spreche ich wohl eine etwas deutliche Sprache, es ist nicht persönlich gemeint.) Ich halte diese "Szenarien" für verfehlt. Das Wort "Laienverständlichkeit" wird als Totschlagargument benutzt, um quasi beliebig banale Beispiele heranzuziehen. Es müssen statt dessen allgemeine Prinzipien dargestellt werden.
Dennoch gehe ich auf die Bilder genauer ein:
- Großrechner-Bild: Es sagt über Compiler nichts aus, da der Compiler nur als Blackbox erscheint. Bestenfalls seine Position in einem Workflow wird sichtbar. Diese Information ist aber so banal, dass sie ein solches Bild nicht rechtfertigt.
- Access-Bild: a) Das Bild finde ich unverständlich. b) Aus informatischer Sicht, und das ist wohl eine sehr vernünftige Sicht in diesem Kontext, ist Access ein schlechtes Beispiel. Beispiele müssen so gewählt sein, dass sie typisch sind. Statt dessen kommt hier was ganz Spezielles, für das sich noch dazu kein Informatiker je interessiert hat. Da kommt halt wieder meine fundamentale Kritik zum Tragen, die ich unten geäußert habe. Und was ist das für ein Stapel aus CPU und Hauptspeicher, der da zu sehen ist? Von diesem Stapel habe ich noch nie gehört. Und oben drauf liegt Access, was auch immer das heißen mag.
So, jetzt bin ich mal auf Sachen eingegangen, aber wie ich bereits unten gesagt habe, ist mein Diskussionsbeitrag eigentlich nur "nein, so geht das nicht". Ich kann nur weiterhin auf dem Einhalten informatischer Standards rumreiten, auch wenn es nerven mag. ʘχ (Diskussion) 17:21, 18. Aug. 2012 (CEST)
- Deine Meinung ist also grundsätzlich ablehnend, dein Recht. Lass mich bitte meine Argumente aufzählen, vielleicht können dann auch Dritte ihre Meinung 'kundtun', woraus 'man' dann die Entscheidung JA/NEIN/Änderungen ableiten könnte:
- Laienverständlichkeit ist ein wichtiges Grundprinzip der Wikipedia.
- Banal: Das Ziel dieser Grafiken ist im Einleitungstext ihres Kapitels genannt: Neben den nur global beschreibbaren Grundvarianten des Lemmas (du nennst es allgemeine Prinzipien; die ja auch beschrieben sind) konkrete Beispiele darzustellen.
- Blackbox: Das Verständnis zu einem Begriff lässt sich nicht nur durch sein 'Innenleben' herstellen, sondern auch durch die Darstellung, wie er in seinem Umfeld eingebettet ist.
- Schlechtes Beispiel: Der Artikel wäre unvollständig, wenn diese Kategorie von 'Software' (und das ist eine Access-Anwendung ja wohl) nicht beschrieben wäre. Alle Reportgeneratoren etc. arbeiten nach diesem (dritten) Prinzip, bei dem 'Quelltext' (darin gibt es keine 'Befehle', abgesehen von VBA) NICHT zu Zielcode konvertiert, sondern nur 'benutzt' wird. Oder gilt diese Variante der Ausführung vom Begriff 'Compiler' als abgegrenzt? Dann muss man es zumindest so beschreiben.
- Informatiker und Access: Diese ist deine Meinung, von der man vermuten kann, dass du die für 'wissenschaftliche Arbeiten' erforderliche Neutralität und Objektivität nicht mitbringst. Man muss MS etc. nicht mögen, gegebene Fakten aber zur Kenntnis nehmen.
- CPU / Hauptspreicher: Grundlage aller Compiler ist die Tatsache, dass jeder Code final und physikalisch nur im Prozessor (= CPU) ausgeführt werden kann und dass sich die Befehle dabei im Hauptspeicher befinden. Nicht ein "dem Quellcode äquivalenter Zielcode" wird ausgeführt, sondern 'das Programm Access'. Das wird hier gezeigt, abgesehen davon, dass man solche Details auch diskutieren und ändern kann.
- Nun liegen also Argumente Pro und Contra vor. Irgendwie wird sich vielleicht eine Entscheidung finden lassen. Und Änderungen in den Texten und Grafiken sind ja auch möglich, mann müsste sie nur diskutieren - als Alternative zur grundsätzlichen Ablehnung. Schönen Sonntag wünscht --VÖRBY (Diskussion) 09:55, 19. Aug. 2012 (CEST)
- Klar ist Laienverständlichkeit ein wichtiges Prinzip, daran habe ich doch gar nicht gerüttelt. Ich habe aber gesagt, dass es als Totschlagargument benutzt wird!
- Informatiker und Access: Diese ist deine Meinung, von der man vermuten kann, dass du die für 'wissenschaftliche Arbeiten' erforderliche Neutralität und Objektivität nicht mitbringst. Man muss MS etc. nicht mögen, gegebene Fakten aber zur Kenntnis nehmen.
- Wie kommst du denn darauf, dass ich die Objektivität nicht mitbringe? Zum ersten schreiben wir hier keine wissenschaftliche Arbeit, sondern eine Enzyklopädie (zumindest bilden wir uns das manchmal ein), zum zweiten hat das nichts mit Microsoft zu tun, sondern mit der informatisch irrelevanten und uninteressanten Softwarekategorie des Reportgenerators. Hier geht es um Compiler! Also müssen hier die in dem Bereich üblichen Problemstellungen betrachtet werden, nicht Sachen aus der Wirtschaftsinformatik!
- CPU / Hauptspreicher: Grundlage aller Compiler ist die Tatsache, dass jeder Code final und physikalisch nur im Prozessor (= CPU) ausgeführt werden kann und dass sich die Befehle dabei im Hauptspeicher befinden. Nicht ein "dem Quellcode äquivalenter Zielcode" wird ausgeführt, sondern 'das Programm Access'. Das wird hier gezeigt, abgesehen davon, dass man solche Details auch diskutieren und ändern kann.
- Ich wollte mit meinem Hinweis nicht anzweifeln, dass die CPU für die Ausführung zuständig ist, sondern dass es keinen Stapel aus CPU und RAM gibt. Das Bild benutzt die Notation falsch. ʘχ (Diskussion) 13:26, 20. Aug. 2012 (CEST)
Die nachfolgenden Texte waren ursprünglich als eigene == Hauptabschnitte == erfasst worden. Da sie jedoch zu 'Zu viele Unterschiede' gehören und dort auch entstanden sind, wurden sie in der Gliederung um je 1 Stufe tiefer gesetzt. --VÖRBY (Diskussion) 14:41, 1. Sep. 2012 (CEST)
"C-Präprozessor ist ein Compiler"
// kopiert aus vorigen Abschnitten:
"So ein C-Präprozessor ist zweifelsohne ein Compiler für eine gewisse Sprache," von Benutzer:Chricho
- Hm, ein Präprozessor ist imo kein Compiler. Präprozessor-Anweisungen werden nicht "übersetzt", sondern ausgeführt, indem die entsprechenden Quellcode-Umbauten durchgeführt werden. Insofern kommt ein Präprozessor eher einem Interpreter gleich, der den Input (C-Quellcode) gemäß eingebetteter Anweisungen umbaut und als Output nun reinen C-Code weitergibt. --arilou (Diskussion) 11:31, 7. Aug. 2012 (CEST)
- [...] Ein Präprozessor ist definitiv ein Compiler, die Sprache, die der übersetzt, ist aber eben so angelegt, dass das Quellprogramm den Kompilierungsvorgang recht direkt steuert, das ist bei zahlreichen Sprachen mit Metaprogrammierungsfähigkeiten nicht anders. [... <Compiler vs. Translator> ...]Ein C-Präprozessor wäre aber zweifelsohne in beiden Fällen dabei, denn er ist nunmal kein Textverarbeitungstool sondern dient der Überführung in Richtung ausführbarer Code. Wie auch immer, wie ein Präprozessor heißt, ist gar nicht mal so wichtig: [...] von Benutzer:Chricho
- [...] Dann sagst du, ein C-Präprozessor gehöre 'zweifelsohne' dazu - und schreibst, dieser erzeuge Code 'in Richtung' ausführbarer Code. Das ist ein erheblicher Unterschied. [...] von VÖRBY
Man kann den C-Präprozessor auch alleine betreiben, ohne den Compiler dahinter, z.B. um in LaTeX-Dateien Makros zu ersetzen, und einzelne Dateien ineinader zu inkludieren.
Der (C-)Präprozessor ist natürlich kein Compiler, seine Anweisungen werden ja nicht übersetzt. Und bevor Chricho jetzt das Gegenteil behauptet, darf er mir mal erklären, in wechen C-Code bitteschön ein
#include xxx.c
ersetzt wird? In
FILE* f=fopen("xxx.c",r); // [...]
oder in was bitteschön? Und was wird aus
#define a 17
? Vielleicht der C-Code
const int a=17;
? Mitnichten. Die Präprozessor-Anweisungen werden ausgeführt wie bei einem Interpreter, es werden entsprechende Aktionen durchgeführt. Danach sind sie WEG und keine übersetzte "semantische Entsprechung" verbleibt im Output. --arilou (Diskussion) 14:02, 7. Aug. 2012 (CEST)
- Kann man so benutzen, dafür ist er aber nicht gedacht, es geht um die Intention. Ich kann auch einen C-Compiler als Entropiequelle benutzen, es bleibt ein Compiler. In welchen Code wird denn import blub; in einem Java-Programm übersetzt? Und dass das Kompilieren eine Ausführung von Makros beinhaltet ist keine Besonderheit, sondern elementar für Metaprogrammierung. Ich habe aber auch keine Lust darüber zu diskutieren, da das völlig nebensächlich ist, insbesondere für die Einleitung, die ist nämlich nicht für Negativlisten von irgendwelchen Sachen, die man in bestimmten Kontexten nicht mit dem Wort Compiler meint, gedacht, sondern für eine Definition. Und da müsste man sich erst einmal grundsätzlicher verständigen. Was ist z. B. mit einem TeX-Compiler? --Chricho ¹ ² ³ 18:03, 7. Aug. 2012 (CEST)
- Oder anders ausgedrückt: Muss das Ziel eine Ausführung sein, oder soll es allgemein um die Übersetzung in ein Äquivalent in einer anderen Sprache gehen? --Chricho ¹ ² ³ 18:07, 7. Aug. 2012 (CEST)
- Ja Leute, wir erfahren hier selbst, wie uneindeutig die Texte zu unserem Lemma sind. Wie so oft dürfte es auch hier wahrscheinlich Definitionen im engeren Sinn und solche in erweitertem Sinn geben. Als Compiler im erweiterten Sinn kann m.E. ein Precompiler (und wohl auch für mehrere andere 'Hilfsmittel') schon gelten, schließlich 'übersetzen' solche Werkzeuge ja ihre Anweisungen in einen anderen Code. Aber wir dürfen auch keine Theorien erfinden, sondern sollten uns auf Belege beziehen.
- Unabhängig davon ist das Beschreiben dieses Lemmas wegen der vielen verwendeten Technologien mit jeweils optionalen Komponenten eine knifflige Aufgabe. Ich halte deshalb die hier diskutierte Frage zwar für interessant, aber i.S. der Zielsetzung (Klarheit über alle Varianten?!) nur für einen 'kleinen Zipfel des Problems'. Es lohnt sich alsi nicht darüber weiter zu 'diskutieren'.
- Ein evtl. klarerer Ansatz könnte sein, relevante Szenarien ganz konkret zu beschreiben, ohne neutralisierende Begriffe und Relativierungen wie "z.B." anwenden zu müssen. Das könnten dann zwar einige Szenarien werden, die könnten dann aber klar zeigen was als Compiler und deren Umfeld (in/Out) gilt und was nicht. --VÖRBY (Diskussion) 19:38, 7. Aug. 2012 (CEST)
- Ja Leute, wir erfahren hier selbst, wie uneindeutig die Texte zu unserem Lemma sind. Wie so oft dürfte es auch hier wahrscheinlich Definitionen im engeren Sinn und solche in erweitertem Sinn geben. Als Compiler im erweiterten Sinn kann m.E. ein Precompiler (und wohl auch für mehrere andere 'Hilfsmittel') schon gelten, schließlich 'übersetzen' solche Werkzeuge ja ihre Anweisungen in einen anderen Code. Aber wir dürfen auch keine Theorien erfinden, sondern sollten uns auf Belege beziehen.
Begrifflicher Nebel nach einem halben Jahrhundert
- Die Vokabel „Compiler“ hat 60 Jahre IT-Geschichte auf dem Buckel. Das ist ähnlich wie bei Textverarbeitung, DTP, CAD – in jedem Jahrzehnt verstand man unter diesen Begriffen etwas anderes.
- Die geläufigste Bedeutung ist zweifelsfrei die Erzeugung von Maschinencode (oder zumindest Assembler).
- Auch die Gebilde zur Erzeugung von Zwischencode heißen aber Compiler.
- Der früheste Vertreter schon in den 1960er Jahren war LISP, durch das damals auch der Begriff Bytecode geprägt wurde.
- Die Quellcode-Übersetzer in Java und C# heißen ebenfalls „Compiler“.
- Jede Marketing-Abteilung verkauft ihr Produkt unter dem hochtechnisch klingenden Namen „Compiler“, auch wenn nur ein Dutzend RegExp dahintersteckt und eine banale Textersetzung erfolgt.
- Auch einen schlichten Minifier kann man als Precompiler verkaufen; man kann Kommentare und Whitespace rausnehmen, Präprozessor-Direktiven ausführen und konstante Ausdrücke vorab berechnen oder Syntaxoptimierung vornehmen.
- Nach mehr als einem halben Jahrhundert gibt es etliche Konzeptionen und Architekturen, Zwitter und Zwischenstadien, Mischformen und Übergangsstadien wie auch Doppelnutzungen. In das klassische Schema lassen sich nicht alle zwängen.
- In einer heute aufgefallenen Redundanzdisku hatte 2004 mal jemand einen Artikel Übersetzer (Informatik) vorgeschlagen.
- Das wäre gar nicht so ungeschickt, um in einer Übersicht die Gemeinsamkeit aller hier fallenden Begriffe darzustellen: Von einem tendenziell eher menschenlesbaren Quelltext zur nächsten Stufe eines maschinengeeigneteren Codes.
- Das kann über viele Zwischenstufen erfolgen:
- Quelltext → Präprozessor → Compiler → Assembler → Prozessorcode
- Quelltext → Compiler → Zwischencode → JIT-Compiler → Assembler → Prozessorcode
- Da kann man dann die Varianten von Compiler, Interpreter (auch kein fundamentaler Unterschied), Textersetzung usw. sauber aufdröseln.
- Linker lassen sich hingegen deutlich unterscheiden; sie lösen symbolische und relative Referenzen auf in weniger relative (bis absolute). Und ein wenig C&P und Bibliotheksindex. Mehr eigentlich nicht.
Liebe Grüße --PerfektesChaos 20:07, 7. Aug. 2012 (CEST)
- Ich stimme darin zu, dass es nach mind. 60 Jahren IT-Sprachgebrauch 'ne Menge Wandel und Vielfalt in der Bedeutung von "Compiler" gab, und auch heute vieles darunter fällt.
- Worin ich nicht zustimme, ist "TF -Artikel-Erstellen", auch wenn's "nicht ungeschickt [wäre], um in einer Übersicht die Gemeinsamkeit aller hier fallenden Begriffe darzustellen". Vielleicht ginge eine Aufsplittung ähnlich
- "Compiler (zu Maschinencode)"
- "Compiler (Sprache-zu-Sprache)"
- "Compiler (...)"
- aber mir fallen eigentlich keine guten Klammer-Inhalte ein.
- Im Moment seh' ich immernoch keine passable andere Möglichkeit, als das Problem hier, in nur einem Artikel, zu lösen (zu versuchen).
- --arilou (Diskussion) 09:44, 8. Aug. 2012 (CEST)
Aussage zu „interpretierte Sprache“, und überhaupt.
Vorsicht mit der Aussage
- spricht man von einer interpretierten Sprache. Das Programm wird in einer Laufzeitumgebung (z. B. JVM oder .NET CLR) interpretiert.
Das hat zwei Macken:
- Der Begriff „interpretierte Sprache“ ist ein eigen Ding, dazu gleich mehr.
- In der Laufzeitumgebung wie JVM oder in .NET wird nix interpretiert.
- Hier wird ein komplett als Zwischencode vorliegendes Programm in die plattformabhängige (maschinennahe) Sprache vollständig kompiliert und dann ausgeführt.
Das mit der „interpretierten Sprache“ wird oft palavert; es gibt aber weder interpretierte noch kompilierte Sprachen als solche. Vielmehr gibt dies unterschiedliche Verarbeitungsabläufe wieder, die mit ein und demselben Quellcode derselben Sprache betrieben werden können.
- Als „Interpretation“ bezeichnet man die Arbeitsweise, dass ein einzelnes Statement einer Programmiersprache (unter Berücksichtigung von Umgebungsbedingungen, etwa Variablen) vom Quelltext in eine ausführbare Form übersetzt und dann sofort ausgeführt wird.
- Insbesondere interaktiv kann man sich das Resultat dieser Ausführung anschauen und dann spontan entscheiden, was man als nächstes Statement haben möchte. Bekannt ist diese Arbeitsweise von Betriebssystem-Shells („Kommandozeilen-Interpreter“), aber auch Roboter (CNC) oder Malprogramme lassen sich so steuern, wie auch ein SQL-Dialog.
- Jedoch kann auch eine „kompilierte Sprache“ einzelschrittweise ausgeführt werden, etwa in einem interaktiven Debugger. Dann kann man die geänderten Variablen inspizieren. Hier lässt sich aber meist nicht während der Abarbeitung die nächste Zeile des Quellcodes verändern (ohne den Debugger zu beenden).
- Wenn man einen Stapel an zu interpretierenden Anweisungen zusammenfasst und mit Parametern versieht, bekommt man – Stapelverarbeitung. Jetzt auf einmal kann man auch „Skriptsprache“ dazu sagen; auch so ein schwammiger Begriff. Bei einer Skriptsprache kommen Kontrollstrukturen hinzu, die bei einer interaktiv interpretierten Arbeitsweise noch keinen Sinn haben.
- Niemand kann mich hindern, den Stapel an zu interpretierenden Anweisungen vorher zu übersetzen und nicht die gesammelten Einzelstatements des Skriptes zeilenweise zu übersetzen, sondern im Vorfeld den ganzen Block. Dann wäre es aber eine „kompilierte Sprache“.
- Die ganze Unterscheidung in diese Sprachen ist Humbug. PHP hat als „interpretierte Sprache“ angefangen und wird heute kompiliert; genauso diverse angebliche „Skriptsprachen“ (perl, py). Auch BASIC wurde zu Zeiten des Wohnzimmerfernsehers interpretiert; VisualBasic kompiliert. So what?
- Nach typischen Anwendungsgebieten werden die Sprachen pauschal in Schubladen gesteckt, ohne dass diese eine Begründung in den Eigenschaften der Sprache selbst hätte.
Was das jetzt mit deklarativer Programmierung zu tun haben soll, erschließt sich mir rein gar nicht.
Liebe Grüße --PerfektesChaos 16:54, 10. Aug. 2012 (CEST)
- Ja, Interpretiertheit ist in der Tat keine Spracheigenschaft. Wo steht etwas von Deklarativem? Im Beiträg von VÖRBY? Ja sehe ich jetzt auch nicht, worauf er damit hinaus wollte. --Chricho ¹ ² ³ 17:02, 10. Aug. 2012 (CEST)
- Ich weiß auch nicht, warum sich diese Formulierungen so hartnäckig halten, aber vielleicht deshalb, weil das jeder Privatmensch in seinem Online-Tutorial zu seiner Lieblingsprogrammiersprache nicht zu erwähnen vergisst, zu denen der Zugang einfacher als zu einem Buch ist, und schließlich auch Leute vom Fach das übernehmen, um die Lücken im Text zu füllen. Ein Paradebeispiel für die Unzuverlässigkeit des Webs als Quelle. [3] [4] [5]
- Vielleicht hilft ein Vergleich mit natürlichen Sprachen. "Interpreter" ist englisch für "Dolmetscher". Und dass man Englisch, Deutsch oder auch isiZulu nur am Stück übersetzen, aber nicht dolmetschen könne, oder umgekehrt, würde so leicht keiner bereit sein zu glauben und nachzuplappern. --Zahnradzacken (Diskussion) 17:35, 10. Aug. 2012 (CEST)
- Ja, Leute, das mit imperativ vs. deklarativ war 'auf meinem Mist' gewachsen und kommt von meiner Erfahrung, dass neuere Sprachen, die häufig in Laufzeitumgebungen ausgeführt werden (und zu großen Teilen deklarativ sind), in die Interpreterschublade gehören sollten. Da das auch ohne Beleg ist, nehme ich die beiden Aussagen wieder raus.
- Unabhängig davon meine ich aber, dass diese Sprachekategorien (-Paradigmen) doch auch mehr oder weniger starke Unterschiede in den Übersetzungsmechanismen haben müssten - und also im Artikel erwähnt werden sollten. Wer könnte dazu mit Text beitragen?
- Ansonsten sehe ich nach wie vor und immer mehr die Notwendigkeit zur Qualitätsverbesserung hier im Lemma. Siehe #ToDo's. Grüße von --VÖRBY (Diskussion) 19:36, 10. Aug. 2012 (CEST)
So klappt das nicht
Zu den "Entwurfstexten"
Ich sehe bezüglich der oben diskutierten "Entwurfstexte" folgende Probleme:
- Der Stil ist journalistisch, nicht enzyklopädisch.
- Der Inhalt orientiert sich nicht an den fachlichen Begriffen, sondern an einer bloßen, mehr oder weniger laienhaften Phänomenologie, das heißt der Frage: Wie nimmt man als Außenstehender die Tätigkeit eines Compilers wahr? Ein Artikel aus dem Bereich Informatik hat sich jedoch Regeln zu unterwerfen. Er muss sich an den Standards der wissenschaftlichen Disziplin messen. Das heißt, er muss insbesondere:
- sich gemäß der in der Disziplin üblichen Standards strukturieren,
- sein Lemma diesen Standards folgend definieren und erklären,
- und mit entsprechender begrifflicher Präzision vorgehen.
Solange die Standards der Disziplin grob verletzt werden, sehe ich keine Diskussionsgrundlage, denn die Grundlagen der Informatik diskutiert man nicht, sondern liest sie nach (oder besucht Vorlesungen, wie auch immer). (Ich hoffe, es fordert mich jetzt niemand auf, diese "Standards" oder Grundlagen zu definieren, denn die kann man recherchieren, und diese Verantwortung hat auch jeder Autor für sich selbst.)
- Ich finde deine Ansicht zu binär. Auf Grundlage des Arguments, dass man die Grundlagen der Informatik beherrscht genau dann, wenn man ein Thema enzyklopädisch aufbereitet, beteiligst du dich gar nicht an der Diskussion, um auf Fehler oder Irrwege hinzuweisen, sondern revertierst und willst auch weiter nicht diskutieren, bis die Fähigkeiten der Mitautoren deinen Vorstellungen entsprechen? Die Theorie und Praxis von Compilern ist sehr umfangreich, was der Artikel überhaupt nicht widerspiegelt. Ich sehe deshalb ein deutliches Qualitätsproblem und jeder, der zur Besserung beiträgt, sollte Gehör finden.
- Ich finde die Entwürfe auch nicht rund und die Vorgehensweise überrumpelt mich, weshalb ich mich auch nicht weiter beteiligen wollte. Aber die Diskussionsgrundlage ist vorhanden. Um mit einem binären Schlusswort zu enden: Entweder, der Compiler-Artikel kann in Kürze Lehrbuch-Qualität erreichen, oder es wird wegen fehlender Qualitätsgrundlage ein
LAQS-Antrag notwendig. </ironie> --Zahnradzacken (Diskussion) 21:52, 16. Aug. 2012 (CEST)
Theoriefindung
Die Diskussion ist mir insgesamt zu stark in ein "Gespräch im Bierzelt" und WP:TF abgeglitten. Anstatt sich an den üblichen Begriffen und Definitionen zu orientieren und diese im Artikel darzustellen, wird philosophisch darüber debattiert, welche Begriffsbestimmungen und Klassifikationen man vornehmen könnte. (Siehe etwa "Begrifflicher Nebel", manche Fragen bei den "ToDos", Diskussionen dazu, "C-Präprozessor".) Davon haben wir aber nichts, denn die dabei entstehenden Theorien können wir ohnehin nicht in den Artikel einbauen. @VÖRBY: Das ist dir hier ja auch aufgefallen, denn du schreibst: Aber wir dürfen auch keine Theorien erfinden, sondern sollten uns auf Belege beziehen.
Wenn wir uns über einen Begriff uneins sind, dann müssen wir den eben recherchieren. Aber hier rumspekulieren nach dem Motto: "Hm, was hat es wohl mit dem Begriff auf sich... könnte man nicht... ist es nicht so, dass..." -- das hat für den Artikel keinen Nutzen.
Unterm Strich: Was ich hier mache, ist kein Aktionismus (@VÖRBY). Das sollte auch aus meinen Änderungen hervorgehen. Ich bin bei der WP, nicht um zu stören, sondern um mitzuarbeiten; aber aus den genannten Gründen kann ich man an dieser Diskussion in dieser Form nicht beteiligen. Lasst uns am Artikel arbeiten, und zwar unter Wahrung enzyklopädischer und informatischer Standards und ohne eigene Theorien über die auftretenden Begriffe aufzustellen. ʘχ (Diskussion) 14:39, 16. Aug. 2012 (CEST)
Zunächst diskutieren wir hier
Hallo ʘx. Ich akzeptiere Deine Anmerkungen voll und ganz. Allerdings sind wir hier nicht im Artikeltext, sondern bewusst in der Diskussion. Die Texte sollen und müssen noch angepasst werden, 'TF' passt also nicht zum aktuellen Status der Texte. Gerne kannst du dabei mithelfen. Was du (wohl 'abfällig') 'Bierzeltgespräch' nennst, sehe ich unter dem Ziel Laientauglichkeit - die im Artikel aktuell 'zu kurz kommt'. Besonders die Notizen in den ToDo's sind (wie in der Einleitung beschrieben) bewusst locker formuliert, um die offenen Fragen zum Lemma passend zu beschreiben. Nach Diskussion darüber (die bisher eigentlich nur zum Thema Access stattfand), sollten die jeweiligen Texte in den Entwürfen vorformuliert und ebenfalls diskutiert / verbessert werden, wozu dann auch Quellennachweise gehören würden. Dabei denke ich, dass jede Art von Fragestellung zum Lemma (Es gibt keine dummen Fragen!) in irgendeinem 'schlauen Buch' beschrieben sein müsste; wenn das dort anders oder unter anderen Begriffen der Fall ist, dann lässt sich das ja anpassen. Wie schon festgestellt, dürfte die Problematik sauberer Beschreibungen auch von der langen Historie und der Unterschiedlichkeit der 'Systeme' verursacht sein; ein Lösungsansatz dazu sollten die 'konkreten Beispiele' sein.
Klar, wir beide haben wohl sehr unterschiedliche Vorstellungen von diesem Thema und besonders auch von der Vorgehensweise (die zugegebenermaßen 'Bottom-Up' ist, was ich aber nicht als minderwertig sehe). Jedenfalls sind im Lemma so viele Fragestellungen 'irgendwie offen' (siehe auch Diskussionen oben), dass es absolut Sinn macht, die Veränderungen vorher zu diskutieren und erst das Resultat, sowohl korrekt als auch (für Laien) verständlich als auch lexikalisch einigermaßen passend in den Artikel einzuarbeiten. Grüße von --VÖRBY (Diskussion) 18:29, 16. Aug. 2012 (CEST)
- Ich weiß nicht, ob dein Bottom-Up-Ansatz mit einer To-Do-Liste, die lauter Kleinigkeiten enthält, irgendjemanden motiviert. Mich leider nicht, aber Compiler sind auch kein besonders großes Interessensgebiet von mir. Meiner Meinung nach braucht der Artikel erst eine solide Grundlage, die laienverständlich gemacht werden kann – oder beim Schaffen der Grundlage wird für Laienverständlichkeit gesorgt. Man kann dabei aus der Laienperspektive die Fragen stellen, die beantwortet werden sollen. Aber die Antworten können nicht aus dem Bauch heraus kommen. Das ist wegen der Größe des Themas aber ein Problem. Ich glaube, dass das am besten durch eine Auftragsarbeit (gibt es das noch?) gelöst werden könnte – oder jemand mit Interesse und Sachkenntnis fasst sich ein Herz. --Zahnradzacken (Diskussion) 22:02, 16. Aug. 2012 (CEST)
- Ich bin eher Ox' Meinung. Die Disku-Seite wird zu einer ewig langen Durchmischung von
- "neuer Seitenentwurf"
- "alternative Vorschläge"
- "Diskussionen zu 1) und 2)"
- "Diskussionen zum eigentlichen Artikel"
- "Diskussion zum Vorgehen an sich" (dieser Satz ist rekursiv *g*)
- Vielleicht wär's doch besser, entweder den aktuellen Artikel direkt zu verbessern, und hier zu diskutieren (wie in WP eigentlich vorzugehen geplant ist), oder einen neuen Artikel im Benutzernamensraum zu verfassen, und somit zumindest obige Punkte 1) und 2) aus Diskussion:Compiler draußen zu halten.
- --arilou (Diskussion) 09:16, 17. Aug. 2012 (CEST)
- Ich bin eher Ox' Meinung. Die Disku-Seite wird zu einer ewig langen Durchmischung von
- 'Direkt zu verbessern' halte ich bei der aktuellen Lage für einen Blindflug. Bisher sind die in der Disk (bei ToDo's) vermerkten Vorschläge für Änderungen noch mehr oder weniger 'meine Privatansicht' - was so nicht gedacht war. Ich habe deshalb bei den ToDo's eine Relevanzbeurteilung vorbereitet. Denn: Solange wir nicht wissen, WAS geändert werden sollte, brauchen wir um die DETAILS nicht zu diskutieren.
- Eine grundsätzliche Neuerstellung des Lemmas halte ich für nicht erforderlich. 'Man' kann m.E. die Schwächen nachträglich bereinigen - aber es sind eben mehrere Punkte. --VÖRBY (Diskussion) 10:09, 17. Aug. 2012 (CEST)
- Nein, meiner Meinung nach kann man durchaus direkt verbessern, wenn man weiß, was man tut. Denn es gibt sicherlich Autoren mit genug Sachkenntnis, um zu wissen, was fehlt und was falsch ist und wie verbessert werden kann. Ich weiß auch nicht, wie deine Vorschläge ungeplant zu deiner Privatansicht werden konnten. War dir das beim Schreiben nicht klar? Aber es ist besser, jemand diskutiert, als dass der Artikel unbemerkt und ungepflegt bleibt. Insgesamt stimme ich aber arilous Beurteilung zu und unterlasse ab nun Punkt 5. --Zahnradzacken (Diskussion) 16:11, 17. Aug. 2012 (CEST)
- 'Ungeplant' heißt, auch andere Leute sollten bei den ToDo's Einträge vornehmen und diese ergänzen / aktualisieren / diskutieren. Stattdessen begannen sofort inhaltliche Diskussionen - mit den oben sichtbaren, von Protesten begleiteten Ergebnissen. WER tut also jetzt WAS? --VÖRBY (Diskussion) 17:55, 17. Aug. 2012 (CEST)
Zum Diskussionsstil hier
Mir kommen langsam Zweifel, VÖRBY, ob du tatsächlich eine echte Diskussion anstrebst. Du sagst und betonst zwar in jedem zweiten Satz, man müsse dieses oder jenes diskutieren, aber letztendlich antwortest du auf die Einwände keineswegs mit inhaltlichen Argumenten, sondern wiederholst nur deinen Standpunkt und sagst wiederum, man müsse alles "diskutieren". So geht das im Kreis: Du sagst "diskutieren", jemand antwortet, du sagst wieder "diskutieren" und immer so weiter. Das ist in der Regel ein untrügliches Zeichen, dass in Wirklichkeit keine Diskussion angestrebt wird, sondern nur ein Durchsetzen der eigenen Sichtweise, die sich allerdings als diplomatisch und kompromissbereit tarnt. Geradezu passiv aggressiv. Auf diese Weise wird die Diskussionsseite immer länger und mit Debatten über Debatten angefüllt, und am Artikel tut sich nichts. Sowas wie das hier habe ich noch nie erlebt, und ich bin schon länger in der WP dabei, als mein Anmeldedatum vermuten lässt. So will ich das nicht! Das hat keinen Wert! ʘχ (Diskussion) 13:27, 20. Aug. 2012 (CEST)
- Deine Zweifel kann ich nur 1:1 zurückgeben. Den in Deinen letzten Anmerkungen (zu den Bildern) enthaltenen Anmerkungen habe ich lediglich meine Argumente entgegengestellt - mit dem Hinweis, dass nun wohl andere entscheiden müssten, ob diese Beiträge in den Artikel passen oder nicht. Was ist daran aggresssiv? Ich bin aber mit diesem Lemma nicht 'verheiratet', ich will weitere Zeit auch nicht investieren/verschwenden und überlasse deshalb weitere Aktivitäten gerne anderen; meinen Beitrag dazu habe ich (über die Notizen in den ToDo's und den Textentwürfen) geleistet. --VÖRBY (Diskussion) 17:49, 20. Aug. 2012 (CEST)
- Es ist für mich schlicht nicht nachvollziehbar, wie du mir vorwerfen kannst, ich wolle meine persönlichen Ansichten durchsetzen, wo ich ja schließlich die ganze Zeit darauf herumreite, dass man sich eben nur und ausschließlich an den in der Disziplin üblichen Begriffen, Definitionen und Problemen orientieren sollte, also alles Sachen, die ja gerade nicht auf meinem eigenen Mist gewachsen sind. Und dass man sich in einem Artikel aus dem Bereich Informatik an informatischen Standards orientiert, ist ja wohl nicht gerade meine persönliche, exotische Privatmeinung. (Ich hoffe, ich erlebe jetzt keine Überraschung.) Analog verfährt man in den anderen Bereichen der WP ja auch, egal ob z.B. Mathematik, Physik, Chemie, Biologie oder sonstwas, Und ich habe bisher noch nicht von dir gehört, ich läge falsch und in Wirklichkeit sei es so und so (denn *das* wäre eine Diskussionsgrundlage, wenn überhaupt), dennoch bleibst du bei deinen Vorschlägen, die jedoch den meinen genau entgegengesetzt sind.
- Wenn tatsächlich irgendwann eine Mehrheit von Leuten der Ansicht sein sollte, dass es angebracht ist, im Artikel Compiler willkürlich herausgegriffene Szenarien aus einem ebenfalls willkürlich gewählten Bereich der Wirtschaft einzubauen und das mit Laienverständlichkeit zu rechtfertigen (wobei diese Themen mit Informatik nichts zu tun haben und ich übrigens sicher bin, dass ein Laie sich nichts unter einem Reportgenerator oder dem System/360 vorstellen kann), statt eine wichtige Problemstellung der Informatik an den üblichen Minimalbeispielen darzustellen, wie es sich gehört und wo inhaltliche und begriffliche Klarheit, Präzision, Korrektheit und Vollständigkeit zusammenfallen, dann brauche ich wohl eine Therapie, ok. Bis dahin aber muss ich den Artikel, wenn schon nicht verbessern, so doch wenigstens gegen schwere Eingriffe, die ihm offensichtlich schaden würden, verteidigen. (Wobei einem Verbessern prinzipiell auch nichts im Wege steht, nur mit den jetzigen Bedingungen komme ich nicht klar.) ʘχ (Diskussion) 22:43, 20. Aug. 2012 (CEST)
Ich konnte gar nicht behaupten, Deine Vorschläge seien falsch - denn du hast hier überhaupt nichts vorgeschlagen. Es ist umgekehrt: Meine Absicht, den Artikel um einige Aspekte zu erweitern und zu präzisieren, die m.E. für das Verständnis des Lemmas von Bedeutung sein können (siehe ToDo's und Entwurfstexte) lehnst du vehement ab. Du hast m.E. eine zu enge, technologische Sicht auf das Innenleben von Compilern; meine Ergänzungsvorschläge dagegen versuchten, den Begriff in seinem Umfeld und Einsatzzweck (und für weniger excellent 'informatisch' gebildete Leute als du es bist) zu beschreiben. Belege dazu sollten gem. den ToDo's noch eingefügt werden. Die Gesamtaktion ist aber aus meiner Sicht "cancelled". --VÖRBY (Diskussion) 10:03, 21. Aug. 2012 (CEST)
- Ich habe nichts vorgeschlagen? Wenn du all das, was ich gesagt habe, einfach nicht werten willst, dann ist das doch nur eine Bestätigung meiner Äußerung, dass dir an einer Diskussion eigentlich gar nicht gelegen war. Denn ich habe mehrfach und auch mit Begründung vorgeschlagen, deine Entwürfe zu verwerfen. ʘχ (Diskussion) 11:52, 21. Aug. 2012 (CEST)
- Genau! "Verwerfen" war Deine Leistung, eigene Vorschläge - nichts. Es ist alles gesagt. --VÖRBY (Diskussion) 15:45, 21. Aug. 2012 (CEST)
Damit alle hier geposteten Texte (zu gegebener Zeit) gemeinsam archiviert werden, habe ich die zeitlich letzten Abschnitte um eine Stufe tiefer gesetzt. Da die Diskussion abgebrochen wurde, blieb der Artikel selbst unverändert; mehrfach festgestellter Verbesserungsbedarf blieb unbearbeitet.--VÖRBY (Diskussion) 14:41, 1. Sep. 2012 (CEST)
Relevanzeinträge nachgeholt (nirgends Feedback); 1 Grammatikfehler behoben; Baustein 'nicht archivieren' gesetzt: --VÖRBY (Diskussion) 13:11, 28. Sep. 2012 (CEST)
Folgediskussionen 'Unterschiede'
Die folgenden Abschnitte waren von Mitdiskutanten im Kontext zum obigen Hauptthema ('Zu viele Unterschiede') als eigene Hauptabschnitte angelegt worden. Damit sie gemeinsam archiviert werden können, habe ich sie heute zu einem Hauptkapitel zusammengefasst. Zusammen mit jener Hauptdiskussion gelten diese Abschnitte ebenfalls als ERLEDIGT. --VÖRBY (Diskussion) 09:53, 2. Nov. 2012 (CET)
Definitionen
Diskussion war im Kontext 'Zu viele Unterschiede' entstanden und ist eine Fortsetzung davon. --VÖRBY (Diskussion) 18:56, 1. Nov. 2012 (CET)
So, ich habe endlich eine Quelle aufgetrieben, welche die Begriffe Übersetzer, Compiler, Assembler und Interpreter in dem mir geläufigen Sinne definiert. Es handelt sich leider um eine etwas "populäre" Quelle, nämlich der dtv-Atlas zur Informatik, geschrieben von einem Physiker, aber dennoch sind die Definitionen korrekt und meiner Meinung nach auch geeignet, allgemein akzeptiert zu werden.
- Übersetzer
- sind Programme, die eine Quellsprache in eine Zielsprache übersetzen.
- Compiler
- sind Programme, die eine problemorientierte Quellsprache (eine Hochsprache) in Assembler- oder Maschinensprache übersetzen.
- Assembler
- sind Programme, die eine Assemblersprache in Maschinensprache übersetzen.
- Interpreter
- sind Programme, die ein Programm Schritt für Schritt in Maschinensprache übersetzen und jeden einzelnen Schritt von einer dahinterstehenden Maschine unmittelbar ausführen lassen (also nicht warten, bis das komplette Programm übersetzt ist).
Ich beginne mal mit etwas Artikelarbeit. ʘχ (Diskussion) 12:30, 30. Sep. 2012 (CEST)
- Gern; aber bitte beachte, dass sich die Reale Welt schon seit Jahrzehnten nicht an den dtv-Atlas zur Informatik hält. Die Byte-Compiler gibt es seit den 1960ern, heißen auch so und übersetzen in Bytecode; javac usw. heißen auch „Compiler“ und übersetzen ebenfalls nicht in Assembler- oder Maschinensprache.
- Der Rest ist unverfänglich.
- Viel Erfolg --PerfektesChaos 12:43, 30. Sep. 2012 (CEST)
- (BK) Nachtrag: Ach ja, und in den JRE etc. gibt es ein Dingsda, das in Assembler- oder Maschinensprache übersetzt, jedoch nicht aus einer Quell- oder Hochsprache.
- Die Begriffsdefinition des Lemma mit einem halben Jahrhundert Geschichte bleibt tückisch. Deshalb wurde in dieser Disku ein Weg gefunden: „… von einer menschennäheren zu einer maschinennäheren …“.
- (BK): javac übersetzt übrigens gerade nicht in irgendeine Art von Maschinensprache; das ist ja eben der Witz an der Sache.
- LG --PerfektesChaos 12:53, 30. Sep. 2012 (CEST)
- Na ja, der dtv-Atlas ist aus den 90ern, da gab es Bytecode bekanntlich schon lange. Und btte denk dran, dass javac sehr wohl in Maschinensprache übersetzt. ʘχ (Diskussion) 12:47, 30. Sep. 2012 (CEST) (nochmal korrigiert *ächz* ʘχ (Diskussion) 12:50, 30. Sep. 2012 (CEST))
- (Zu deinem Nachtrag, bzgl Java) Das halte ich so wirklich für falsch. ʘχ (Diskussion) 13:01, 30. Sep. 2012 (CEST)
- Dann lies es bitte nach:
javac
und analog C# übersetzen aus der Hochsprache in Zwischencode; das ist ein Maschinen-unabhängiger proprietärer Code. Ähnlich schon LISP in den 1960ern unter dem Namen „Bytecode“ durch ein „byte-compile“. - Einen dtv-Atlas aus den 1990ern würde ich besser nicht als Beleg in die WP einführen.
- --PerfektesChaos 13:06, 30. Sep. 2012 (CEST)
- Dann lies es bitte nach:
- Ob dieser Code proprietär ist, ist doch gar nicht von Belang. Außerdem ist dieser Code nicht maschinenunabhängig, ich weiß auch gar nicht, wie du überhaupt auf diese Idee kommen kannst, ist doch wirklich offensichtlich falsch.
- Die Entwicklungen, die du da nennst, waren in den 90ern bereits 30 Jahre alt, sind also durchaus in dem Buch berücksichtigt. ʘχ (Diskussion) 13:10, 30. Sep. 2012 (CEST)
- Nachtrag: Ich stimme zu, dass man prinzipiell vorsichtig sein muss mit einem Buch von 1995. Allerdings sind die Defs in diesem Falle unverfänglich, würde ich sagen. ʘχ (Diskussion) 13:42, 30. Sep. 2012 (CEST)
- javac produziert einen plattform- und maschinenunabhängigen Zwischencode/Bytecode; so auch bei C# und anderen. Dieser wird verteilt. Auf der Zielplattform wird dieser Zwischencode/Bytecode innerhalb JRE, virtueller Maschine oder wie immer geheißen erneut compiliert. Die im angegebenen dtv-Atlas zur Informatik gegebene Definition trifft hierauf definitiv nicht zu. Soviel zum Offensichtlichen; nebenbei benutze ich javac seit 15 Jahren und habe auch hin und wieder mal in eine .class-Datei geschmult.
- Die im dtv-Atlas angegebene Schlicht-Definition traf schon damals nur den simplen Trivialfall, wenngleich der seinerzeit weitaus häufigste. Den damaligen Ausnahmefall (LISP, Prolog und andere) erwischte sie schon nicht, aber das mag damals verzeihlich gewesen sein. Heute wird aber vielfältig von komplexeren Architekturen Gebrauch gemacht, die von diesem simplen Spezialfall nicht korrekt beschrieben werden. Insofern ist die dtv-Definition für den ersten Einstieg und für ein elementares Grundverständnis ganz nett, wird aber der Wirklichkeit nicht gerecht.
- --PerfektesChaos 13:58, 30. Sep. 2012 (CEST)
- javac produziert einen plattform- und maschinenunabhängigen Zwischencode/Bytecode Das ist falsch, da gibts nichts zu deuteln.
- Erstens ist der Java-Bytecode der Maschinencode der Java-Maschine, er läuft dort und NUR dort. Von Maschinenunabhängigkeit kann also keine Rede sein. Dass man auf allen möglichen Plattformen Emulatoren dieser Maschine hat, macht den Code nicht unabhängig. Es gibt schließlich auch x86-Emulatoren, die x86-Bytecode auf allen möglichen anderen Plattformen ausführen. Also ist x86-Code wohl maschinenunabhängig, was? Der Begriff der Maschinenunabhängigheit macht nur in Bezug auf Quellcode Sinn (wo er auch entsprechend definiert ist), aber niemals auf Bytecode.
- Zweitens gibt es sogar CPUs, die den Java-Bytecode als Befehlssatz verwenden, man kann also noch nichtmal behaupten, der Javacode sei rein abstrakt, und es gäbe keine konkrete Entsprechung.
- Es macht auch keinen Sinn, zu sagen, die Definition werde der Wirklichkeit nicht gerecht, nur weil man Fälle kennt, wo der Begriff anders benutzt wird. Das ist bei nicht-formalen Begriffen normal und so gut wie nicht zu vermeiden. ʘχ (Diskussion) 14:09, 30. Sep. 2012 (CEST)
- javac produziert einen plattform- und maschinenunabhängigen Zwischencode/Bytecode Das ist falsch, da gibts nichts zu deuteln.
- Erst mal zur Definition, wenn schon dieser thread so heißt: Wenn wir hier von einer „Maschine“ reden, dann meinen wir Hardware. Genau dies ist auch in deinem antiquierten Lexikon gemeint mit „Assembler- oder Maschinensprache“ – das steht für die Chips und nicht die Salsa.
- Die JVM ist nicht mit einem Chip zu verwechseln, auch wenn man dieser Art von Software spaßigerweise den Namen „Virtuelle Maschine “gegeben hat.
- Es ist eine groteske Verdrehung der Begrifflichkeiten, dieses Java (Technik) als „Emulatoren“ zu bezeichnen. Es ist das grundlegende Architekturprinzip, das von Java eingeführt wurde und inzwischen mehrfach nachgeahmt wurde.
- Dass man ein Jahrzehnt später auch den Java-Prozessor hinzuentwickelt hat und es eine Handvoll eher experimenteller Anwendungen gibt (wohl noch keine flächendeckend verbauten Großserien), ist nur wieder ein Sonderfall in den vielfältigen Architekturen. Es ist nicht das Grundprinzip von Java.
- --PerfektesChaos 14:39, 30. Sep. 2012 (CEST)
- Erst mal zur Definition, wenn schon dieser thread so heißt: Wenn wir hier von einer „Maschine“ reden, dann meinen wir Hardware. Und wie kommst du darauf, dass wir das so meinen? Seit wann versteht die Informatik unter einer Maschine nur etwas mit Drähten?
- Die Begriffe, um die es hier geht, sind nicht-formal und nur unscharf definiert. Es gibt keine feste und allgemein akzeptierte Def. Es ist sehr witzlos, reinzurufen "ich habs aber auch schon anders gesehen!". Äh, natürlich hat man das. Es dürfte kaum möglich sein, das zu vermeiden. ʘχ (Diskussion) 15:00, 30. Sep. 2012 (CEST)
Du hast diesen Thread damit begonnen „ich habe endlich eine Quelle aufgetrieben, welche die Begriffe Übersetzer, Compiler, Assembler und Interpreter in dem mir geläufigen Sinne definiert.“
- Ich habe vorsorglich darauf verwiesen, dass diese Einzelmeinung nicht die gesamte Bandbreite des Begriffes abdeckt.
- Insbsondere ist der einfache Fall des dort beschriebenen Compilers hinsichtlich des Lemmas unzureichend. Er ist sicher ein populärer und häufiger Fall, aber die Welt ist komplizierter. Bereits damals war die Definition schon nicht allgemein und umfassend genug gewesen.
- Die im hoffentlich inzwischen aktualisierten dtv-Atlas verwendete Interpretation von „Assembler- oder Maschinensprache“ ist diejenige, die in den 1960ern bis 1990ern gebräuchlich war; nämlich Hardware.
- Es kam im weiteren Verlauf heraus, dass ein Lexikon mit dieser Definition wohl inhaltlich zwei Jahrzehnte alt und damit hoffnungslos veraltet ist. Inzwischen sind sehr viel komplexere Architekturen verbreitet.
Wenn du also eine einzelne Quelle aufgetrieben hast, die endlich mal in dem dir geläufigen Sinne definiert, dann scheint mir das daran zu liegen, dass es sich dabei nicht um die heute ansonsten übliche Sichtweise handelt; dies deshalb für eine Verbesserung des Artikels ungeeignet ist.
--PerfektesChaos 15:33, 30. Sep. 2012 (CEST)
- Es ist mir wirklich neu, dass man "heutzutage" eine andere Sichtweise auf Compiler hätte. Und das liegt nicht daran, dass ich nicht informiert wäre. ʘχ (Diskussion) 15:36, 30. Sep. 2012 (CEST)
Interessant, eure Diskussion hier. Aber das hatten wir schon früher mal: Es gibt einerseits allgemeingültige Aussagen zu diesem 'Begriff' (ja, im Prinzip hat sich da wohl nichts verändert), aber ebenso gibt es (zwischenzeitlich) viele, viele Varianten (was sich aus der Entwicklung der P-Sprachen ergeben hat). Wenn man das nicht auseinanderhält, wird man immer wieder diese 'Debatten' führen müssen. Mein Vorschlag dazu (siehe oben) war, sowohl das Allgemeine zu beschreiben als auch die Varianten - und zwar möglichst jeweils jede Variante für sich, sonst gibt es wieder 'Kuddelmuddel'. Ich habe aber nicht die Absicht, mich hier nochmal intensiv einzubringen. --VÖRBY (Diskussion) 18:31, 30. Sep. 2012 (CEST)
- @ʘx: Schade, dass dir das neu ist. Natürlich gibt es „heutzutage“ eine andere Sichtweise.
- In den 1970ern und 1980ern, auf die sich der angegebene dtv-Atlas stützt, gab es praktisch nur den nach außen einstufigen Kompilierungsprozess. Exoten wie LISP und etwas Prolog oder so lagen nicht im Blickfeld; insofern mag die damalige Definition hingehen.
- Heute gibt es den mehrstufigen Kompilierungsvorgang in wesentlichen Bereichen von außen wahrnehmbar. Der einstufige ist heute immer noch häufig, aber nur noch eine von mehreren Möglichkeiten. Im Prinzip sind auch mehr als zweistufige Ketten möglich, wenn auch heute exotisch.
- Bei der angesprochenen Java-Technik gibt es einen Compiler (javac) zum Übersetzen von Menschen-Hochsprache in Zwischencode=Bytecode, einen weiteren („JIT-Compiler“) in der JRE→JVM zur Erzeugung der plattformabhängigen Maschinensprache. Heute exotisch ist der Fall, dass man nach zehn Jahren vereinzelt Prozessoren passend zum spezifischen Bytecode zusammengelötet hat und damit dieser Bytecode auch eine Maschinensprache geworden ist. Das zeigt aber die Komplexität der heutigen Welt; kein Vergleich mit den simplen Konzepten des letzten Jahrhunderts, wie sie sich im dtv-Atlas niederschlugen.
- --PerfektesChaos 09:44, 1. Okt. 2012 (CEST)
- Wenn ich mich (als Inhaber einer Lehrstuhls für Programmiersprachen und Übersetzer) mal kurz einmischen darf: Ich kann die Unterscheidung zwischen Übersetzer und Compiler nicht nachvollziehen, und ich kenne keinen Kollegen, der da einen Unterschied macht. Darüber hinaus kann ich mir nicht vorstellen, dass die Unterscheidung, so wie sie jetzt im Artikel steht, einem Laien weiterhilft. Allerdings gehört der dtv-Atlas auch nicht zu den Lehrbüchern, die wir hier verwenden... --Herbert Klaeren (Diskussion) 10:20, 1. Okt. 2012 (CEST)
- Ähm, sorry, Chricho, darf ich mal wörtlich zitieren: Drachenbuch, 2., aktualisierte deutsche Auflage, Pearson 2008, Seite 3: „Einfach gesagt, handelt es sich bei einem Compiler um ein Programm, das ein Programm in einer Sprache - der Quellsprache - lesen und in ein gleichwertiges Programm einer anderen Sprache - der Zielsprache - übersetzen kann.“ Und wo bitte ist da die Unterscheidung Übersetzer-Compiler?? --Herbert Klaeren (Diskussion) 11:00, 1. Okt. 2012 (CEST)
- Chricho, kannst du die Defs mal aus dem Drachenbuch zitieren, damit wir uns darauf beziehen können?
- @Herbert Klaeren: Ja, der dtv-Atlas hat auf jeden Fall das Problem, kein Fachbuch im engeren Sinne zu sein. Aber davon abgesehen halte ich die Definitionen selbst für akzeptabel, und das wäre ja auf jeden Fall schon einmal ein Anfang. Wie ich bereits angemerkt habe, gibt es ja leider zu den Begriffen Compiler etc. viele verschiedene Ansichten, und hier im Artikel müssen wir uns auf etwas einigen, womit wenigstens die meisten, die etwas vom Thema verstehen, sich abfinden können. ʘχ (Diskussion) 10:38, 1. Okt. 2012 (CEST)
- Nachtrag @Perf. Chaos: Also, was du da auflistest, ist in keiner Weise eine neue Sichtweise auf Compiler. Das ist alles dasselbe wie vorher. Du machst da willkürlich eine Unterscheidung, wo es gar nichts zu unterscheiden gibt. ʘχ (Diskussion) 10:42, 1. Okt. 2012 (CEST)
- @ʘx: Schade, dass dir das neu ist. Natürlich gibt es „heutzutage“ eine andere Sichtweise.
„Programming languages are notations for describing computations to people and to machines. The world as we know it depends on programming languages, because all the software running on all the computers was written in some programming language. But, before a program can be run, it first must be translated into a form in which it can be executed by a computer. The software systems that do this translation are called compilers.“
Davon abgegrenzt werden language translators und language processors (letzterer Begriff schließt Interpreter, Präprozessor, Linker oder Assembler mit ein im Gegensatz zum Compiler).
„In this preliminary chapter, we introduce the different forms of language translators[…]“
Danach wird das Buch im Abschnitt Applications of Compiler Technology nochmal deutlicher:
„Compiler design is not only about compilers[…] Compiler technology has other important uses as well.[…] While we normally think of compiling as a translation from a high-level language to the machine level, the same technology can be applied to translate between different kinds of languages.“
D. h. die Anwendbarkeit von compiler technology für andere Übersetzer wird dargestellt, der egtl. Compilerbegriff bleibt aber der Übersetzung einer Hochsprache in eine Maschinensprache (VMs mit eingeschlossen) vorbehalten. Völlig klare Definitionen werden nicht gegeben, aber die Unterscheidungen sind da. Die englische Wikipedia unterscheidet übrigens ebenfalls, habe aber im Moment keinen Eindruck von der Qualität des dortigen Artikels. @Herbert Den von dir zitierten Satz würde ich nicht definitorisch verstehen, sondern nur als beschreibend, der restliche Text macht klar, dass unter einem Compiler etwas spezielleres verstanden wird. --Chricho ¹ ² ³ 11:18, 1. Okt. 2012 (CEST)
Ich habe in der Einleitung die Aussage 'ausführen durch einen Computer' präzisiert um 'd.h. dessen Prozessor'. Dabei geht es mir nicht darum, ob wir Prozessor oder Hardware oder CPU schreiben, vielmehr denke ich, dass in dieser allgemeinen Form die Aussage 'ausführbar durch einen Computer' für jede Art von Programmcode unterstellt werden könnte. V.a. der Laie würde für jede Form von Programmcode selbstverständlich erwarten, dass ihn "der 'Computer' ausführen kann"; er unterscheidet da nicht zwischen Software und Hardware und auch nicht danach, ob das in einem oder in mehreren Schritten erfolgt. Deshalb ist die Ergänzung zweckmäßig. --VÖRBY (Diskussion) 12:44, 1. Okt. 2012 (CEST)
"Programmcode"
Diskussion war im Kontext 'Zu viele Unterschiede' entstanden und ist eine Fortsetzung davon. --VÖRBY (Diskussion) 18:57, 1. Nov. 2012 (CET)
Abschnitt "Compiler#Einordnung verschiedener Compiler-Arten":
Müsste es nicht "Maschinencode" statt "Programmcode" heißen? --arilou (Diskussion) 13:43, 1. Okt. 2012 (CEST)
(PS: Es ist sehr erfreulich, dass nun ein Lehrstuhlinhaber für Übersetzer hier mitschreibt. Dann werde ich mich wieder mehr auf die WP:OmA-Verträglichkeit zurückziehen.)
- An anderen Textstellen hier ist vom 'Zielcode' die Rede. Das scheint mir allgemeingültiger zu sein und lässt die Möglichkeit offen, dass Compiler etwas anderes als Maschinencode erzeugen. Wenn ja, sollte das also 'Zielcode' heißen, sonst 'Maschinencode'. --VÖRBY (Diskussion) 15:33, 1. Okt. 2012 (CEST)
- Ich dachte, dass der Zusatz "nativ" immer bedeutet, dass der erzeugte Code maschinenspezifisch, also Maschinencode, ist. Sonst wär's ein Bytecode, und selbiger nicht mehr "nativ", oder?
- Analog übersetzt ein Crosscompiler doch in einen Zielcode, der spezifisch für die Zielplattform ist, also ebenfalls maschinenspezifisch.
- Hm, theoretisch wäre es allerdings auch möglich, dass ein Crosscompiler z.B. von z.B. "Java (allgemein)" nach "C speziell für MIPS xxx" übersetzt. Dass jedoch ein "nativer" Compiler nicht nach Maschinencode (oder maschinenspezif.Assembler) übersetzt, dürfte dann doch sehr seltener sein.
- --arilou (Diskussion) 16:07, 1. Okt. 2012 (CEST)
- Geht das Spekulieren schon wieder los? Au ja, wunderbar.
- "Nativ" ist immer bezüglich einer bestimmten Maschine zu verstehen. Code ist also niemals "nativ", sondern immer nur "nativ bzgl. einer bestimmten Maschine". x86-Code ist nativ bzgl. einer x86-CPU, Java-Bytecode ist nativ bzgl. der Java-Maschine. ʘχ (Diskussion) 16:24, 1. Okt. 2012 (CEST)
- (BK)
- Die Kennzeichnung als „nativ“ bedeutet nur, dass es die gleiche Plattform ist, aber nicht zwangsläufig schon auf der Ebene des Maschinencodes. Dabei ist „Plattform“ eine Ebene drüber und könnte auch ein Betriebssystem-Niveau bedeuten.
- Der von einem nativen Compiler erzeugte Code könnte in der gleichen System-Umgebung ausgeführt werden; der eines Cross-Compilers nicht. Woran genau das liegt, bleibt aber offen und ist letztlich egal.
- Die Vokabel „Zielcode“ wäre geeigneter, weil keine Festlegung über die genaue Art des Codes erfolgt und möglich wäre.
- Sonnigen Feierabend --PerfektesChaos 16:33, 1. Okt. 2012 (CEST)
- (BK)
Dann wäre dieses Detail aus der Frage von Arilou ja geklärt: 'Zielcode' scheint hier genau passend: Nicht zu allgemein (wie der hier ungeeignete Ausdruck 'Programmcode') und nicht ausschließlich 'Maschinencode' meinend. Ob diese Feinheiten der Leser aber bemerkt, sei dahingestellt. Zu Cross-Compiler fehlt mir im Text das Wort 'auch'; so wie ich das lese, "kann" er für fremde Plattformen Code erzeugen - was aber sicher nicht heißen muss, dass er das für seine eigene Plattform nicht kann. 'Freiwillige vor' zur Korrektur des Artikels! --VÖRBY (Diskussion) 18:23, 1. Okt. 2012 (CEST)
- +1 "Zielcode", das lässt offen, was das genau ist. Die anderen Begriffe sind meistens erklärungsbedürftig. Unter "Programmcode" verstehen manche auch den Sourcecode. Und "Maschinencode" ist einfach zu eng. --RobTorgel (Diskussion) 15:22, 2. Okt. 2012 (CEST)
- Genauso ist es. Bei Nativ-Compiler stand leider immer noch 'Programmcode', wie auch in ca. 4-5 anderen Stellen für die Bedeutung 'Zielcode'. 'Programmcode' ist dann korrekt, wenn aus dem Satzzusammenhang heraus klar ist, welche Code-Art gemeint ist - was auch einige Male der Fall ist. Ich werde entsprechend auf 'Zielcode' korrigieren. Wo der Zielcode tatsächlich Maschinencode ist, sollte man das danach vielleicht nochmal aktualisieren. --VÖRBY (Diskussion) 17:58, 2. Okt. 2012 (CEST)
- Beim Maschinencode ist vielleicht noch zu unterscheiden, ob das ein fertiger "Dump" ist (wie früher beim Dos die .com-files) oder ein .exe, das einen Loader braucht oder überhaupt ein .obj, das zus. vorher noch einen Linker braucht. (Fällt mir ein, da war doch noch das exe2bin, das aus einem exe bei Einhaltung gewisser Regeln ein .com oder .sys machte. jöö, ist das schon wieder her) --RobTorgel (Diskussion) 19:51, 2. Okt. 2012 (CEST)
- Genauso ist es. Bei Nativ-Compiler stand leider immer noch 'Programmcode', wie auch in ca. 4-5 anderen Stellen für die Bedeutung 'Zielcode'. 'Programmcode' ist dann korrekt, wenn aus dem Satzzusammenhang heraus klar ist, welche Code-Art gemeint ist - was auch einige Male der Fall ist. Ich werde entsprechend auf 'Zielcode' korrigieren. Wo der Zielcode tatsächlich Maschinencode ist, sollte man das danach vielleicht nochmal aktualisieren. --VÖRBY (Diskussion) 17:58, 2. Okt. 2012 (CEST)
- +1 "Zielcode", das lässt offen, was das genau ist. Die anderen Begriffe sind meistens erklärungsbedürftig. Unter "Programmcode" verstehen manche auch den Sourcecode. Und "Maschinencode" ist einfach zu eng. --RobTorgel (Diskussion) 15:22, 2. Okt. 2012 (CEST)
- Nee, EXE etc. sind nur die Formate von Dateien, die den Code speichern. Das hat mit dem Code selbst nix zu tun. ʘχ (Diskussion) 22:32, 2. Okt. 2012 (CEST)
- Das stimmt schon. Nur, der Output eines Compilers ist nun einmal eine File, die ein bestimmten Anspüchen genügen muss. Und in dem Fall sind absolute Sprung- und Datenadressen einfach nicht vollständig. --RobTorgel (Diskussion) 08:06, 3. Okt. 2012 (CEST)
- Nein, das hat damit wirklich nichts zu tun. Ob absolute oder relative Adressen ist für den Compiler wurscht (will heißen, das erfordert keine grundlegend unterschiedlichen Methoden). ʘχ (Diskussion) 13:16, 3. Okt. 2012 (CEST)
- Das stimmt schon. Nur, der Output eines Compilers ist nun einmal eine File, die ein bestimmten Anspüchen genügen muss. Und in dem Fall sind absolute Sprung- und Datenadressen einfach nicht vollständig. --RobTorgel (Diskussion) 08:06, 3. Okt. 2012 (CEST)
- Nee, EXE etc. sind nur die Formate von Dateien, die den Code speichern. Das hat mit dem Code selbst nix zu tun. ʘχ (Diskussion) 22:32, 2. Okt. 2012 (CEST)
Kann jetzt archiviert werden, war ursprünglich im falschen Hauptabschnitt archiviert worden.
Interpreter
Der Interpreter (in reiner Form) erzeugt überhaupt keinen Code. Er beinhaltet a priori eine Reihe von fertigen Funktionen u. Subroutinen, die durch den Sourcecode parametrisiert und in der Abfolge gesteuert werden. Während des Ablaufes werden "Tabellen" von Einsprungstellen und Datendefinitionen aufgebaut, in der Folge, wie sie beim Abarbeiten vorgefunden werden. Dadurch sind Vorwärtsreferenzen nicht möglich. Klassisch und puristisch: die Basicinterpreter der frühen Home-Computer bis zu den ersten PC-Generationen, die auch Teil der "Betriebssystems" waren.
- Mit etwas Liebe kann man da die div. Shells bzw. Commandline-Executer durchaus dazurechnen.
Wesentliches Merkmal: Der Interpreter muss zum Laufzeitpunkt geladen sein und stellt selbst das gewünschte Anwendungsprogramm dar. Beim Aufruf wird kein User-Programm geladen, sondern der Interpreter, mit dem Parameter der Sourcefile. --RobTorgel (Diskussion) 12:11, 3. Okt. 2012 (CEST)
- Was soll uns das sagen? Oben in der Diskussion (#Compiler vs Interpreter) wurde das schon mal behandelt. Doch ist nach wie vor nicht klar, ob I. nun eine Art von Compiler/Übersetzer sind oder ein Gegensatz zu Compilern. Siehe oben (ToDo's).
- Das "Merkmal" für I. ist nicht, dass ein I. geladen werden muss; auch ein Compiler muss erst geladen werden. Und auch ein Compiler liest den Quellcode - als was auch immer. Der Unterschied muss woanders liegen.
- Ich glaube aber, dieses Thema ist schon 'durch'; die vorherige Riesendiskussion wurde 'cancelled'. --VÖRBY (Diskussion) 12:45, 3. Okt. 2012 (CEST)
- Es ist richtig, dass ein Interpreter keinen Code erzeugt. Aber der Rest macht so keinen Sinn. "Fertige Funktionen" existieren immer, ob mit oder ohne Interpreter. ʘχ (Diskussion) 13:31, 3. Okt. 2012 (CEST)
- Ja, das ist aber zu allgemein. Der Compiler hat "fertige" Templates, die er modifiziert in den Zielcode einfügt. Beim Interpreter sind das Funktionen, die auch tatsächlich durchlaufen werden.
- Das "Merkmal" für I. und der Unterschied zum C. ist, dass ein I. während der gesamten Laufzeit geladen bleiben muss. Der C. offensichtlich nicht.
- Art vs. Gegensatz kannst du an der Zielsetzung festmachen. Den C. startest du, um Code umzuwandeln, den I., um eine Anwendung auszuführen. Das betrachte ich als Gegensatz.
- Soweit es um das Sourcecode-Verständnis geht, mag ja der I. eine Art Übersetzer sein, aber das muss auch ein sprachspezifischer Editor können. Damit ist hier nix anzufangen.
- PS:Wir sollten uns nicht damit befassen, dass man Programme auch laden muss --RobTorgel (Diskussion) 14:22, 3. Okt. 2012 (CEST)
- Ich muss da wieder widersprechen. Der wesentliche Unterschied zwischen Interpreter und Compiler ist nicht, dass der eine zur Laufzeit geladen ist und der andere nicht, sondern, dass sie völlig unterschiedlichen Klassen angehören. Ein Compiler ist ein Übersetzer, ein Interpreter nicht. ʘχ (Diskussion) 15:02, 3. Okt. 2012 (CEST)
- Seh' ich weniger Widerspruch. Aber egal. Worauf ich eigentlich hinaus wollte: Interpreter versus Compiler ist imo ein Gegensatz. C. übersetzt den Sourcecode in einen Zielcode, I. führt ihn direkt aus. Das schiene mir insbes. für Laien der maßgebliche Unterschied. Dass beide intern z.T. ähnliche oder auch gleiche Probleme lösen müssen, halte ich nicht für den Punkt, den man in einem Compiler-Artikel breit ausführen müsste. --RobTorgel (Diskussion) 15:40, 3. Okt. 2012 (CEST)
Leute, wir sind schon wieder 'mitten im Wald'. Könnte vielleicht jemand (statt wieder hundertmal hin- und herzudiskutieren) einen oder zwei Sätze formulieren, die hier im Artikel 'Compiler' festlegen und erklären, ob Interpreter ein Gegensatz/Komplement/Ausschluss zu Compilern oder eine 'Art' von Compilern sind - und warum.
PS: So war das mit '#Entwurfstexte' gemeint. :-( --VÖRBY (Diskussion) 16:53, 3. Okt. 2012 (CEST)
- Genau das habe ich gerade getan, mitten im Wald stehe ich sicherlich nicht.
- @RobTorgel: Ein Gegensatz ist das nicht. Das Gegenteil von "Ausführen" ist nicht "Code erzeugen", sondern "nicht Ausführen". Aber wie dem auch sei: Interpreter sind im Compilerartikel falsch. ʘχ (Diskussion) 18:52, 3. Okt. 2012 (CEST)
- (*schmunzel*) Bevor wir uns in den Unterschied zwischen Gegensatz und Gegenteil verbeissen, stellen wir den Konsens der letzten Aussage fest: Da wir ja nicht definieren müssen, was ein Compiler nicht ist und es einen "Interpreter"-Artikel ja gibt, genügt es hier, wenn überhaupt, sowas wie
- "Anders als ein Interpreter übersetzt ein Compiler den Sourcecode in einen Zielcode....etc."
- zu schreiben.
- (*schmunzel*) Bevor wir uns in den Unterschied zwischen Gegensatz und Gegenteil verbeissen, stellen wir den Konsens der letzten Aussage fest: Da wir ja nicht definieren müssen, was ein Compiler nicht ist und es einen "Interpreter"-Artikel ja gibt, genügt es hier, wenn überhaupt, sowas wie
--RobTorgel (Diskussion) 19:31, 3. Okt. 2012 (CEST)
Beispiele vllt?
Ein paar Beispiele für Compiler wären hilfreich(eigentlich ist damit gemeint ein IDE) bspw. Visual Studio usw. (nicht signierter Beitrag von 134.108.245.4 (Diskussion) 16:12, 5. Jun. 2013 (CEST))
- Hallo, sowas in der Art wurde schon mal vorgeschlagen - und es gibt dazu auch schon Entwurfstexte; siehe '== Ablaufbeispiele ==' im Archiv. Nach dazu sehr kontrovers geführten Diskussionen (siehe ebenfalls dort) wurde auf die Beispiele verzichtet. Du musst sie dir also woanders suchen. Leider! --VÖRBY (Diskussion) 16:31, 5. Jun. 2013 (CEST)
- IDEs sind keine Compiler. Sie bieten lediglich ein Interface zu ihnen (wobei das nur eine Funktionalität unter vielen ist). ʘχ (Diskussion) 18:10, 5. Jun. 2013 (CEST)
- (BK) Nach BK: dito. --Plankton314 (Diskussion) 18:14, 5. Jun. 2013 (CEST)
- Was BK bedeutet, kann ich nicht erkennen. Die WP-Hilfe hilft auch nicht.
- Eurer Ablehnung stimme ich NICHT zu und begründe nochmal: Der Artikel heißt 'Compiler'. Er behandelt aber alle Varianten der "Übersetzung von Programmcode in Richtung Ausführung" (wie das auch in der seinerzeitigen Diskussion festgestellt wurde) - inkl. Assembler, Interpreter und Linker. Er ist auch das Ziel aus der BKS 'Übersetzer' - was im Artikel als Überbegriff für Compiler ("übersetzt in einen Zielcode" als allgemeine Aussage) oder als Synonym für Compiler beschrieben wird. Aus dieser Sicht gibt es in allen Arten von Software (inkl. IDE) solche 'Übersetzer' resp. Übersetzungen. Gerade wegen dieser Vielfalt täte dem Artikel also eine klarere Abgrenzung dieser Begriffe gut (wie das hier vorgeschlagen war), der Wunsch nach Beispielen zeigt, dass der Artikel das Lemma nicht klar genug darstellt. "Besonders begabte und fähige Benutzer" (so werden bestimmte Leute hier genannt) brauchen das möglicherweise nicht. --VÖRBY (Diskussion) 12:59, 6. Jun. 2013 (CEST)
- BK bedeutet genau das, was du selbst verlinkt hast. ʘx und ich hatten gleichzeitig editiert - nur er war schneller :) und dann habe ich meine inhaltsgleiche Antwort gekürzt.
- Es mag sein, dass es sich irgendwo zwischen der Umgangssprache und der Fachsprache eingebürgert hat, Entwicklungsumgebungen wie das VStudio einfach "Compiler" zu nennen - falsch ist es dennoch, da die IDE selbst keinerlei Übersetzung vornimmt. Die beiden teilen sich auch keine Aufgabe, sondern ergänzen einander. Insofern halte ich es für falsch, dieses Missverständnis durch eine Erläuterung zu IDEs hier noch zu bestärken.
- MMn. kommen Leute die Beispiele für IDEs fordern einfach mit der falschen Vorstellung zu diesem Artikel. Nämlich das hier irgendwas über das VStudio, Eclipse o. ä. stünde.
- Compiler sind ein komplexes Thema und ich glaube, dass es zweckdienlicher wäre eine gut verständliche Erklärung und auch Abgrenzung in der Einleitung zu haben (ggf. samt Verweis auf die IDE-Thematik), anstatt an dieser Stelle lemma-übergreifende Beispiele zu liefern.
- Ich bin mir gerade nicht sicher, war es das, was du ohnehin meinstest?--Plankton314 (Diskussion) 14:01, 6. Jun. 2013 (CEST)
- Ja, das meinte ich unter Anderem: Klare Abgrenzungen verwandter Begriffe. --VÖRBY (Diskussion) 18:13, 6. Jun. 2013 (CEST)
- Es mag sein, dass es sich irgendwo zwischen der Umgangssprache und der Fachsprache eingebürgert hat, Entwicklungsumgebungen wie das VStudio einfach "Compiler" zu nennen Ich hoffe, nicht. Wer sich auch nur halbwegs auskennt, wird diese beiden Dinge niemands durcheinanderwerfen, denn da bestehen keine Unklarheiten.
- Insofern halte ich es für falsch, dieses Missverständnis durch eine Erläuterung zu IDEs hier noch zu bestärken. Sehr richtig. Da könnte man ja gleich bei allen Artikeln eine Sektion einbauen: "Was dieses Lemma alles nicht ist". Das wäre aber Unfug. Denn aus der Beschreibung und Definition des Lemmas muss ja hervorgehen, um was es geht. Wenn man nach dem Lesen der Compiler- und IDE-Artikel immer noch in der Lage wäre, einen Compiler mit einer IDE zu verwechseln, dann wären die Artikel für die Tonne. ʘχ (Diskussion) 16:02, 6. Jun. 2013 (CEST)
- Auch der Fragesteller ist nicht doof, und niemand verwechselt eine IDE mit einem Compiler! Aber die Frage sollte ja erlaubt sein, wie ein IDE-Programm tatsächlich (im Prozessor) 'ausgeführt' wird. Irgendeine 'Übersetzung' (oder mehrere) muss es da ja wohl geben. Und diese interessierte den Beitragsinitiator offensichtlich. Nochmal: Da der Artikel HIER auch für andere Arten von Übersetzung steht (s.o., siehe BKS Übersetzer), wäre die Beschreibung unterschiedlicher Szenarien hier nützlich. Ich fürchte aber, dass diese Sicht die "fähigen Benutzer" nicht überzeugt - und die unfähigen somit mit ihren Fragen im Dunkel bleiben. Danke. --VÖRBY (Diskussion) 18:13, 6. Jun. 2013 (CEST)
Kleiner Drache
Den Inhalt habe ich gem. den drei Meinungen unten gelöscht.
Er ist ggf. aus der Versionsgeschichte rekonstruierbar. --VÖRBY (Diskussion) 09:53, 11. Jun. 2013 (CEST)
>>> gelöscht <<< (nicht signierter Beitrag von 2.205.207.213 (Diskussion) 13:04, 10. Jun. 2013)
- Was will/soll der vorhergehende Diskussionsbeitrag sagen?? --VÖRBY (Diskussion) 13:17, 10. Jun. 2013 (CEST)
- Er sagt: Löscht mich, denn ich trage nicht zur Artikelarbeit bei. --Plankton314 (Diskussion) 13:23, 10. Jun. 2013 (CEST)
- Stimmt, ich hab's auch gehört --RobTorgel (Diskussion) 13:52, 10. Jun. 2013 (CEST)
- Er sagt: Löscht mich, denn ich trage nicht zur Artikelarbeit bei. --Plankton314 (Diskussion) 13:23, 10. Jun. 2013 (CEST)
Eigener Artikel für 'Übersetzer' als Überbegriff
(Fortsetzung aus der vorherigen Diskussion (#Beispiele vllt?)
Eine Alternative zu den hier möglichen Beispielen / Abgrenzungen etc. sehe ich darin, den Artikel 'Compiler' als Spezialvariante von 'Übersetzer' zu belassen bzw. den Inhalt entsprechend zu reduzieren. Das Lemma 'Übersetzer' wäre dann keine WLS mehr, sondern der übergeordnete Begriff, der auf die Spezialformen verweist. Dort könnten ggf. auch die Begriffsabgrenzungen und auch die Beispiele untergebracht werden. --VÖRBY (Diskussion) 14:32, 8. Jun. 2013 (CEST)
- Ja, das würde ich unterstützen.
- Ich halte es nicht für ratsam, den Begriff "Compiler" durch "Übersetzer" aufzuweichen. Dann entsteht die Problematik, dass auf einmal Vieles als "übersetzen" erklärt werden kann, was eigentlich doch nicht "kompilieren" ist. Nach meinem Verständnis sollte "Compiler" - soweit es geht - auch von anderen Arten des Übersetzens/Interpretierens/Parsens klar abgrenzbar sein. Grundsätzlich würde ich den Begriff "Compiler" hier so - und nur so - auslegen, wie es im ersten Satz der Einleitung steht. Der zweite Absatz gibt ja mMn. vor, was ein Übersetzer ist und was somit hier nicht geschrieben stehen sollte.
- Welches Lemma bzw. übergeordneten Begriff meinst du? Die Übersetzer-BKS?
- Und inwiefern würdest du den Inhalt des aktuellen Artikels reduzieren? Soweit ich beim Darüberschauen gesehen habe, steht hier eigentlich nur Compiler-spezifisches (im eigentlichen Sinn). --Plankton314 (Diskussion) 21:38, 10. Jun. 2013 (CEST)
- Übersetzer i.S. Computer ist alles, was Code "in Richtung Ausführen" konvertiert oder aufbereitet. Die BKS Übersetzer (Begriffsklärung) verweist aber nur auf Compiler. Diesen Verweis würde ich ersetzen wollen durch ein neues Lemma 'Übersetzer (~Programmcode)'. Dort sollten nach einer Einleitung alle Grundvarianten beschrieben werden: Assemblieren, Kompilieren in Zwischencode, Kompilieren in Maschinencode, Linken, Parsen, Interpreter (ggf. getrennt Befehle-für-Befehl oder 'blockweise'); evtl. gibt es weitere Grundvarianten?
- Die vom Disk-Initiator vorgeschlagenen Beispiele, ggf. für alle wichtigen Programmierspreachen/-Systeme, würden dort folgen können - ähnlich den beiden schon vorhandenen Entwürfen.
- Ja, der bisherige Artikel behandelt i.W. den Compiler in Reinform. Mit 'Reduzieren' hatte ich irrtümlich die hier diskutierten / vorgeschlagenen Aspekte (dort wurde auch 'Interpreter' ausführlich diskutiert) gemeint. Aber die waren ja nicht in den Artikel eingeflossen. Man muss also HIER nicht viel ändern. --VÖRBY (Diskussion) 09:18, 11. Jun. 2013 (CEST)
Habe soeben festgestellt: Einen Abschnitt 'Übersetzer' gibt es auch in Programmiersprache. Diesen könnte man evtl. auch als 'Überbegriff' sehen und verlinken; besser wäre aber m.E. ein eigenes Lemma wie oben erwähnt. Wobei man Inhalte aus Programmiersprache verwenden, dort kürzen und per 'Hauptartikel' dorthin verweisen sollte. PS: Ich denke, die 'Überarbeitung' in diesem Artikel kann als erledigt gelten.--VÖRBY (Diskussion) 12:51, 11. Jun. 2013 (CEST)
- Ich denke, dass das dann der Ansatzpunkt wäre. Ggf. dort erstmal ausbauen und falls es zuviel wird in einen eigenständigen Artikel auslagern.
- Auf der BKS wäre es dann IMO auch sinnvoller den Verweis erstmal auf Programmiersprache#Übersetzer zu setzen oder zu ergänzen.
- Im Abschnitt Übersetzer findet sich auch schon eine Erwähnung von IDEs. Aber so ganz bin ich mir noch nicht darüber im Klaren, wie das dann am Ende aussehen soll - aber wir werden ja sehen. --Plankton314 (Diskussion) 13:16, 11. Jun. 2013 (CEST)
Entwurf 'Übersetzer'
(Grundlage: Text aus Programmiersprache#Übersetzer)
Zieldokument: Neues Dokument ~Übersetzer oder aktualisiert in Programmiersprache#Übersetzer
Auch in Computerprogramm#Übersetzung und Ausführung gibt es ähnliche Texte. Redundanz beseitigen?
Änderungsnachweise:
Vorbereitung zur Ausarbeitung des Textes: --VÖRBY (Diskussion) 19:02, 11. Jun. 2013 (CEST)
Rohschema eingefügt: --VÖRBY (Diskussion) 10:03, 12. Jun. 2013 (CEST)
Verallgemeinerung: --VÖRBY (Diskussion) 10:53, 12. Jun. 2013 (CEST)
Allgemeine Grafik: --VÖRBY (Diskussion) 11:21, 13. Jun. 2013 (CEST)
Texte aus Hauptartikel, zT angepasst --VÖRBY (Diskussion) 11:07, 14. Jun. 2013 (CEST)
AOT-Compiler ergänzt: --VÖRBY (Diskussion) 11:02, 15. Jun. 2013 (CEST)
Notiz zu evtl. Redundanz: --VÖRBY (Diskussion) 09:45, 16. Jun. 2013 (CEST)
Hinweise von PerfektesChaos eingearbeitet / u.a.: --VÖRBY (Diskussion) 11:32, 17. Jun. 2013 (CEST)
Texte aus belegten Quellen benutzt: --VÖRBY (Diskussion) 13:13, 29. Jun. 2013 (CEST)
Lader als Hilfsmittel ergänzt: --VÖRBY (Diskussion) 09:42, 30. Jun. 2013 (CEST)
Zwei Bedeutungen für 'Übersetzer': --VÖRBY (Diskussion) 11:01, 1. Jul. 2013 (CEST)
Texte in eigenen Artikel übernommen: --VÖRBY (Diskussion) 16:01, 3. Jul. 2013 (CEST)
Der Text wurde heute in das neue Lemma Übersetzer (Programmierung) übernommen und hier gelöscht. Letzter Stand siehe Versionsgeschichte. --VÖRBY (Diskussion) 16:01, 3. Jul. 2013 (CEST)
Diskussion zum Entwurf
- Ehrlich gesagt, bin ich damit nicht so richtig glücklich und sehe in den letzten Tagen keine Verbesserung.
- Einen Artikel 'Compilieren' sehe ich nicht, auch nicht in gebräuchlicherer Rechtschreibung Kompilieren. Sobald es ihn geben würde, erhielte er postwendend einen Redundanzbaustein mit der Aufforderung, ihn wegen weitgehender inhaltlicher Überschneidung mit Compiler zusammenzulegen. Im Übrigen gibt es eine zehn Jahre bewährte Regel zur Lemma-Wahl (etwa hier zusammengefasst), nicht gleichzeitig ein Verb und ein Substantiv als unterschiedliche Lemata anzulegen, sondern sie als Weiterleitung anzulegen. Wie das momentan Kompilieren auch korrekt handhabt.
- Die hinter beiden Neuformulierungen steckende Aussage hinsichtlich Maschinencode ist ein Konzept aus den 1970er Jahren, das damals schon nicht durchgängig richtig war (LISP) und mittlerweile eher Ausnahme denn Regel. Gerade alle modernen Sprachen und Konzepte schreiben beinm Kompilieren eben nicht mehr Maschinencode, sondern einen plattformunabhängigen Zwischencode (der an die Endnutzer verteilt wird), und erst im letzten Schritt auf der Zielplattform wird – angepasst an die Hardware des Endgerätes – Maschinencode daraus. Das Gegenteil der Definition ist heutzutage zutreffend.
- Wir hatten bereits in vorangegangenen Diskussionen festgestellt, dass Vokabeln, die über 60 Jahre für 10.000 Software-Produkte von 100.000 hochkompetenten Fachleuten aus 200 Ländern benutzt werden, heute nicht mehr exakt trennscharf auseinanderzuhalten sind. Gerade der Versuch, schulbuchmäßig eine einzige richtige Definition vorzuschreiben, ist TF und nuked einen in die Steinzeit der IT, als es auch praktisch nur eine Realisierung gegeben hatte.
- Weil die heutige IT-Welt ja so furchtbar kompliziert und vielschichtig geworden ist, ist es keine Lösung, einfach die Konzepte aus der guten alten Zeit hervorzukramen, weil das damals alles so einfach war und man mit viel simpleren Definitionen auskam.
LG --PerfektesChaos 12:07, 12. Jun. 2013 (CEST)
- Hallo, vielleicht gibts hier Missverständnisse:
- Der vorgenannte Text (derzeit Entwurf) soll entweder ein eigenes neues Lemma oder der Text im Abschnitt 'Übersetzer' von Programmierspreache werden. Siehe vorhergehende Diskussion.
- Man kann in 'Pr-Spr' nicht einfach schreiben, dass alles Übersetzen 'Kompilieren' sei.
- Gerade weil sich in den vergangenen Jahrzehnten so Vieles verändert hat, sollte man alle möglichen Varianten und auch Begrifflichkeiten hier aufführen. Inkl. IDE! Denn dies war diesmal der Ursprung der Diskussionen. Siehe oben.
- Dass letztlich nur Maschinencode ausgeführt werden kann, wirst ja auch du so sehen!?
- Die Schreibweisen lass bitte im derzeitigen Stadium außen vor, die können wir noch aktualisieren.
- Was du mit schulbuchmäßig und trennscharf und Steinzeit und 'herauskramen' meinst, kann ich derzeit nicht erkennen; es geht um das Darstellen möglichst aller Varianten von 'Übersetzung'.
- Sicher kann (und muss) man im Wording noch Vieles anpassen. Aber die gängigen Verfahren sollten klar beschrieben und möglichst auch mit ihren Bezeichnungen (inkl. Synonyme) benannt werden.
- Es wäre schön, wenn du deine Kenntnisse aktiv in die Texte einbringen würdest; im derzeitigen Stadium zu perfekt sein zu wollen, ist nicht zielführend. --VÖRBY (Diskussion) 12:33, 12. Jun. 2013 (CEST)
- Hallo, vielleicht gibts hier Missverständnisse:
- PerfektesChaos hat recht. Im von ihm verlinkten Diff ist keine Verbesserung eingetreten, nur eine Verschlechterung. Verwirrung der Begriffe, selbstgemachte Definitionen, TF, manchmal sogar falsche Behauptungen. Auch hier wird es nicht besser. Ich (und sicher auch niemand sonst) hab keine Lust, jedes Mal aufs neue Listen zu schreiben, was alles im Detail nicht stimmt ist und welche Begriffe falsch verwendet werden. Zeitverschwendung. Das hatten wir auch alles schon. Bitte, bitte, wende dich doch Dingen zu, von denen du etwas verstehst und lass die Compiler und Programmiersprachen in Ruhe! ʘχ (Diskussion) 13:02, 12. Jun. 2013 (CEST)
- Wir hatten diese Diskussion in der Tat doch vor einem guten Jahr schon einmal bis zur völligen Erschöpfung geführt; weder meine Zeit noch das schöne Wetter erlauben es mir, alle erzielten Ergebnisse einfach zu vergessen und noch einmal bei Adam und Eva und 1970 anzufangen und alles erneut durchzukauen.
- Zu IDE: Die haben hier nichts, aber auch rein überhaupt nichts mit zu tun.
- Das I in IDE steht für integrated. Das ist eine Zusammenfassung von Einzelwerkzeugen, die meist interaktiv, aber auch skriptgesteuert/automatisch benutzt werden können. Ohne irgendwelche Compiler wird es nicht abgehen; das ist aber schon alles.
- Zur IDE gehören:
- Editier-Werkzeuge für den Quellcode ein oder mehrerer Programmiersprachen
- Analyse und Aufbereitung des Quellcodes; auch grafisch, etwa als Baumstrukturen mit Objekten und Vererbungen und Methoden.
- Ein oder mehrere Compiler, auch unterschiedliche pro Programmiersprache, die mit ihrer Eingabe (Quellcode usw.) und ihrem Output (Objektcode, Fehlermeldungen) an die IDE angedockt sind.
- Darstellung der gemeldeten Fehlermeldungen (Zeilennummer) im Editier-Werkzeug nach 1.
- Makefiles oder analoge Strukturen zum Bau höherer abgeleiteter Codes (Bibliothek, package, EXE); Abhängigkeiten und Propagierung
- Verwaltung von Versionen für Quellcode wie auch generierter Codes; als Alpha, Beta, Release usw.
- Skriptsprache zur Automatisierung; Konfigurationseinstellungen für Projekt, Version, Benutzer
- Dokumentationswerkzeug/e
- Hilfs- und Analysetools
- Der grundlegende Denkfehler ist und war es, für über ein halbes Jahrhundert mit mittlerweile einer Vielzahl von Architekturen und Konzeptionen simple, schulbuchmäßige Definitionen durch die deWP vorzugeben, an die sich dann gefälligst weltweit -zigtausende von Produkten zu halten haben.
- Ich kann mich gern über Nacht hinsetzen und die breit genug gehaltenen Definitionen aus der vorangegangenen Diskussion heraussuchen für Übersetzer, Compiler, Assembler, Interpreter. Jetzt lacht die Sonne.
- VG --PerfektesChaos 13:16, 12. Jun. 2013 (CEST)
- Wie kommst du darauf, dass sich der Rest der Welt an irgendwelche Definitionen die hier im Wiki stehen zu halten habe? Kann sein, dass einige Leute in dem Irrglauben leben, dass hier im Wiki die absolute Wahrheit propagiert würde und Definitionen von hier globale Gültigkeit hätten, dieser Anspruch wird hier jedoch nirgends erhoben.
- Um kurz zur Problematik der Unterscheidung zwischen Compiler/Interpreter zurückzukommen: Irgendwo muss eine mehr oder minder scharfe Linie zwischen Compiler und Interpreter gezogen werden.
- Oder aber man stellt sich dieser "Wahrheit" im Sinne der Normativität des Faktischen, führt die Artikel Compiler und Interpreter zusammen und stellt dar, dass es früher Unterschiede gab und sie heute fließend ineinander übergehen. --Plankton314 (Diskussion) 13:30, 12. Jun. 2013 (CEST)
- Ich führte gerade aus, dass sich die Welt da draußen eben nicht an schlichte Definitionen halten wird, was die deWP erlaubt „Compiler“ zu nennen und was nicht.
- Gerade zwischen Compiler/Interpreter gibt es zur Abwechlung mal eine scharfe und auch allgemein eingehaltene Trennlinie: Interpreter führen immer aus, Compiler nie. Nun ausgerechnet diese beiden zusammenschmeißen zu wollen, wäre hanebüchen. Das Problem ist vielmehr der über Jahrzehnte völlig unscharfe und insofern undefinierte Begriff „Übersetzer“, und die Frage, was wer schon zu den Compilern zählen möchte und was nicht.
- VG --PerfektesChaos 10:10, 13. Jun. 2013 (CEST)
- Warum bist du dann dagegen, diese beiden Begriffe, ggf. auch ihre Synonyme und Varianten, an einer Stelle aufzuführen und kurz zu erläutern (wie hier vorgeschlagen) und dann zum konkreten Instrument zu verlinken? Wie gesagt, Formulierungen sind derzeit offen.--VÖRBY (Diskussion) 11:07, 13. Jun. 2013 (CEST)
- Ich hatte eins drüber versprochen, bei hinreichender Kühle mich dranzusetzen und die belastbaren „Definitionen“/Erklärungen aufzuschreiben. Wobei die Definition von etwas Schwammigem eigentlich keine ist. Im Moment sind mir die Abende zu schön für Wikipedia; spätestens beim nächsten Regenguss. VG --PerfektesChaos 11:20, 13. Jun. 2013 (CEST)
- Danke für die Bereitschaft. Ich stelle mir hier (vorlfg im Entwurfstext) für jeden aufgezählten Begriff (die aber vollständig sein sollten!) nur eine ganz kurze Erläuterung vor - mit Link zum Hauptartikel. Der untere Textteil (alt) bräuchte m.E. im Artikel gar nicht mehr erscheinen, das gehört zu Compiler. Vielleicht passt auch die Absatzüberschrift (bisher Übersetzer) nicht mehr. --VÖRBY (Diskussion) 13:00, 13. Jun. 2013 (CEST)
- Ich hatte eins drüber versprochen, bei hinreichender Kühle mich dranzusetzen und die belastbaren „Definitionen“/Erklärungen aufzuschreiben. Wobei die Definition von etwas Schwammigem eigentlich keine ist. Im Moment sind mir die Abende zu schön für Wikipedia; spätestens beim nächsten Regenguss. VG --PerfektesChaos 11:20, 13. Jun. 2013 (CEST)
- @PerfektesChaos: Ja, der Trennlinie mit der Ausführung stimme ich zu, ich dachte auch, dass in dem Edit etwas herausgestellt zu haben. Die Problematik mit dem Begriff "Übersetzer" sehe ich auch so und hat uns wohl erst hierher geführt.
- Die Aussage, dass der Interpreter "Programmtext während der Ausführung übersetzt" finde ich jedoch eher unglücklich, weil das dann eher ein JIT-Compiler wäre. Hier einfach zu schreiben "der Programmtext ausführt" o. ä., wäre mE. exakter. --Plankton314 (Diskussion) 11:35, 13. Jun. 2013 (CEST)
@perfektesChaos + Ox:
Ihr seht die Diskussion wieder mal aus der rein technokratischen Brille. Und nehmt nicht zur Kenntnis, was hier diskutiert wird. Auf die Argumente in "18:13, 6. Jun. 2013" und "13:16, 11. Jun. 2013" und "12:33, 12. Jun. 2013" geht ihr einfach nicht ein.
Nochmal (ob's hilft?):
- Es geht hier NICHT um den Text zu Compiler.
- Vielmehr soll dargestellt werden, dass zwischen dem ersten Code (~Quellcode) und der tatsächlichen Ausführung 'irgendwelche Konvertierungen' (~Übersetzungen) erforderlich sind, damit sie der 'Computer' (= Prozessor) ausführen kann. Nichts sonst führt Programme physisch aus.
- Das ist unabhängig von Programmiersprachen und hat auch nichts mit 'Steinzeit' zu tun; es ist einfach immer so - auch bei IDE's.
- Und die technische Entwicklung hat viele Varianten davon mit sich gebracht. Was die Übersicht nicht einfacher macht.
- Die Anfrage des IP-Benutzers bezog sich auf IDE's etc. Wobei die Disk unter 'Compiler' zugegebenermaßen nicht passend war. Aber inhaltlich unberechtigt war sie nicht.
- Genau an diesem Punkt diskutierte ich weiter, zuletzt mit Plankton314 im Konsens: Es gibt derzeit keinen Artikel, in dem alle für diese Konvertierung verfügbaren Hilfsmittel beschrieben werden. Auch die BKS 'Übersetzer' verweist nur auf 'Compiler' - was auch lt. derzeitigem Text in Compiler falsch ist.
- Nachdem es hier im Thema wohl keine einheitlichen Begrifflichkeiten gibt (wie ihr auch feststellt), halte ich den Verbleib in Programmiersprachen#Übersetzer für die bessere Lösung als ein neues Lemma. Allerdings ist der derzeitige Text dort zu einseitig auf 'Compiler' ausgerichtet.
- Dies soll der o.g. Entwurf ergänzen; dass er derzeit inhaltlich und begrifflich noch unvollständig ist, liegt in der Natur der Sache 'Diskussion'. "Überwiegend rumfauchen gegen meine Formulierungen" (wie ein anderer Benutzer mal festgestellt hatte) halte ich deshalb für nicht angebracht.
Ob Ihr beide dabei Lust habt mitzumachen, wage ich nicht mehr zu hoffen. --VÖRBY (Diskussion) 09:44, 13. Jun. 2013 (CEST)
Rohmaterial zur Diskussion und als Grundlage für Artikelverbesserungen:
- Übersetzer
- Übersetzer übersetzen einen Block mit Code einer formalen Sprache in einen anderen Block mit Code einer formalen Sprache.
- Formale Sprache kann dabei alles sein von der höheren Programmiersprache bis zum Maschinencode.
- In der Regel handelt es sich bei der Zielsprache um eine andere formale Sprache. Gelegentlich kann es auch die gleiche Syntax sein, aber ein deutlich anderes Format.
- Es muss sich nicht zwingend um eine Programmiersprache handeln; es kämen auch Daten-/Schnittstellen-Beschreibungs-Sprachen in Frage.
- Quell- und Zielcode haben im Wesentlichen gleiche Funktionalität und Informationsgehalt.
- Ist das anders, würde man von Generierern oder Extraktoren sprechen; etwa das Generieren von Schnittstellenbeschreibungen oder Dokumentationen aus Programm-Code.
- Übersetzer führen niemals den behandelten Code aus.
- Dieser Begriff ist englisch/deutsch durch sechs Jahrzehnte für so viele Sachen benutzt worden, dass es TF wäre, wenn die deWP die Definition einengen würde.
- Ein weitgehend synonymer Begriff wäre Konvertierer. Das meint im Wesen das Gleiche, ist aber in manchen Bereichen gebräuchlicher, ohne dass es irgendeinen systematisch abgrenzbaren Unterschied gäbe.
- Übersetzer übersetzen einen Block mit Code einer formalen Sprache in einen anderen Block mit Code einer formalen Sprache.
- Compiler
- Compiler sind Übersetzer, die Programm-Code von einer menschennäheren in eine maschinennähere und effizientere Stufe überführen.
- Das kann rein einstufig vom Original-Quellcode in Maschinencode geschehen.
- Dies war (zumindest mit
AssemblerMaschinencode als Zielsprache) in den ersten Jahrzehnten der Regelfall gewesen.
- Dies war (zumindest mit
- In modernen Architekturen bevorzugt man zunächst einen effizienten plattformunabhängigen Zwischencode, der verteilt wird. Auf dem Endgerät des Anwenders wird dies dann je nach Hardware und Betriebssystem in Maschinencode kompiliert.
- Das Ergebnis beim Anwender kann in einem Cache gespeichert bleiben, der so lange gültig bleibt, bis sich der Zwischencode ändert.
- Arbeitet man ohne Cache, heißt das Just-in-time-compiling.
- Das kann rein einstufig vom Original-Quellcode in Maschinencode geschehen.
- Um den Compiler herum gibt es weitere Werkzeuge, die integriert oder separat ähnliche Aufgaben wahrnehmen: Minimierer, Präprozessor, Precompiler, Optimierer, Parallelisierer, Obfuscator.
- Früher war in C der Präprozessor ein eigenes Tool, das in einem vorangeschalteten Arbeitsgang lief; heute geschieht das integriert im selben Lauf. Optimierer sind meist im Compiler integriert; es gibt sie auch einzeln.
- Durch die separaten Werkzeuge könnten weitere Zwischenstufen entstehen.
- Die Abgrenzung von Precompiler und Compiler ist letztlich willkürlich, und zwischen Präprozessor und Compiler war sie auch nicht von ewiger Dauer.
- Compiler sind Übersetzer, die Programm-Code von einer menschennäheren in eine maschinennähere und effizientere Stufe überführen.
- Assembler
- Assembler gehören zur Familie der Compiler. Sie übersetzen von einer halbwegs menschenlesbaren prozessornahen Form in Maschinencode. Insbesondere ist der Quellcode als menschenlesbare Form des Maschinencodes anzusehen, da ein Assembler immer genau 1 Quellcode-Befehl in genau 1 Maschinenbefehl übersetzt, was zugleich die Abgrenzung zu (Hochsprachen-)Compilern darstellt.
- Seit über einem halben Jahrhundert ist es üblich, hierfür ausschließlich die Vokabeln „Assembler“ und „assemblieren“ zu verwenden und nie „Compiler“ oder „kompilieren“.
- Interpreter
- Interpreter führen Anweisungen einer Programmiersprache sofort aus, sobald die einzelne Anweisung fertig eingelesen wurde.
- Dies kann interaktiv oder automatisiert (=Skript) geschehen.
- Es gibt keine „Interpretersprachen“ oder „Skriptsprachen“. Jede solche Sprache (ein aus ihren Anweisungen zusammengestelltes Skript) kann auch vorab kompiliert werden, ohne es auszuführen. Kompilierung wäre damit jede effizientere Aufbereitung des Quellcodes. „Skriptsprache“ ist eine gebräuchliche und sinnvolle pragmatische Benennung für eine Gruppe von Sprachen, hat aber keinerlei Verankerung in der Sprache selbst; es gibt in ihr praktisch keine Merkmale, an denen sich das ablesen ließe.
- Interpretieren ./. Kompilieren sind lediglich zwei verschiedene Arten, was man mit einem Block an Sprachcode anstellt.
- Von wegen die notiz weiter oben, daran wäre etwas falsch, und Verweis auf den Hauptartikel. Dort heißt es korrekt im Einleitungsabschnitt: „sondern den Quellcode einliest, analysiert und ausführt“.
Pflicht erfüllt --PerfektesChaos 21:16, 15. Jun. 2013 (CEST)
- Danke für deine Beiträge. Wie du gesehen hast, habe ich im Textentwurf zwischenzeitlich Kurztexte aus den Hauptartikeln eingestellt - und wo nötig verkürzt/angepasst. Ich versuche noch, Angaben von dir zu verwenden, will aber dabei bleiben, nur 1 oder 2 Sätze je Tool (eine Art Kurzdefinition) zu beschreiben und auf die Hauptartikel verweisen.
- Interpreter / falsch: Meine Meinung ist, dass nur der Prozessor TATSÄCHLICH 'ausführt'. Ein Interpreter 'lässt nur ausführen'. Da aber 'ausführen' umgangssprachlich (in en:WP bei 'Execution (computing)#Interpreter' heißt es 'Loosely speaking') auch für Interpreter gilt, sollte man das so tolerieren/akzeptieren.--VÖRBY (Diskussion) 09:43, 16. Jun. 2013 (CEST)
Ich habe m.E. wesentliche Aspekte von (21:16, 15. Jun.) im Entwurf berücksichtigt. Der hier besprochene Abschnitt soll nur einen Überblick über alle Varianten der 'Konvertierung' (vom Quellcode bis zur Ausführung im Prozessor) vermitteln. Ist die Aufzählung vollständig?
Viele eurer beschriebenen Details finden sich in den jeweiligen Hauptartikeln - oder so sollte es wenigstens sein. Offen wäre noch, ob dieser Überblick in Programmiersprache oder in Computerprogramm besser reinpasst; im anderen Artikel sollte dann Redundanz abgebaut werden. --VÖRBY (Diskussion) 12:31, 17. Jun. 2013 (CEST)
- Ich denke, der umkastelte Text ist groß genug für 'nen eigenen Artikel, hm, z.B. "Programmausführung" oder von mir aus auch "Übersetzer (Informatik)". Die anderen Artikel können dann darauf verweisen.
- --arilou (Diskussion) 10:05, 18. Jun. 2013 (CEST)
- Ich werden den Entwurfstext also im Artikel 'Codeübersetzung (Programmierung)' neu anlegen und in der BKS Übersetzer (Begriffsklärung einbinden. Das Lemma 'Übersetzer' halte ich für unpassend, weil dieser Ausdruck - auch - als Synonym für Compiler gilt. Alternative: 'Übersetzung (..)? Dass die einzelnen Artikel, auf die ein Hauptartikelverweis zeigt, auf ihn zurückverlinken, ist aus meiner Sicht nicht nötig. In den beim Textentwurf genannten Artikeln könnte/sollte der Text anschließend aus Gründen der Redundanzverringerung gekürzt werden.--VÖRBY (Diskussion) 09:12, 28. Jun. 2013 (CEST)
Es sind beim Stichwort Compiler wieder die beiden Stufen falsch. Sowohl Quell- wie auch Zieldatei sind viel zu stark eingegrenzt und geistig wieder auf die 1970er Jahre zurückgefallen.
- Ausgangspunkt muss mitnichten eine Hochsprache sein. Auch Nicht-Hochsprachen werden kompiliert. Ausgangspunkt ist eine menschenverständliche(re) Programmiersprache. >>> So steht/stand das im zweiten Absatz von Compiler. VÖRBY
- Endpunkt ist schon lange kein Maschinencode mehr.
- Ein Endpunkt wäre Zwischencode. Das ist eben genau kein Maschinencode, was plattform- und Hardware-abhängig ist. >>> So steht das im zweiten Absatz des Entwurfstextes. VÖRBY
- Oben hat mir arilou in meinen Text hineinredigiert, Assembler und Maschinencode wäre 1:1 das Gleiche. Auch das ist schlicht falsch. Ich hatte bewusst geschrieben: „Dies war (zumindest mit Assembler als Zielsprache)“. Der zunächst aus der Programmiersprache generierte Assemblercode kann sehr wohl bei der Assemblierung noch durch Optionen und Parameter unterschiedlichen Maschinencode für unterschiedliche Hardware (Chips) erzeugen. Aus diesem Grund hatten schon in den 1970er Jahren die besseren Compiler eben keinen Maschinencode mehr ausgegeben, sondern Assemblercode. Damit war über die Assemblersprache zwar schon die System- und Prozessorfamilie festgelegt, aber in einer zweiten Stufe noch die Anpassung an einzelne Varianten möglich. Siehe etwa auch unseren Artikel zu parametrisierbaren Anweisungen, wobei der Compiler diese Parametrisierung für bestimmte Chips noch offenlässt. Genau deshalb ist auch die Behauptung von arilou falsch, ein Assemblerbefehl würde immer genau einem Maschinenbefehl entsprechen. >>> Das sind Details, die nicht zum Text HIER gehören. Das '1:1' zwischen Ass- und Maschinenbefehl wird auch in Assemblersprache so ähnlich formuliert. VÖRBY
- Die im Entwurfstext aufgeschriebene Definition des Compilers widerspricht sich sogar selbst: Bei der JIT- und AUT-Compilierung des Zwischencodes ist die Eingabesprache eben keine angebliche „höhere Programmiersprache“ mehr, sondern für Menschen kaum noch nachvollziehbarer Zwischencode.
- Genau deshalb schrieb ich „von einer menschennäheren in eine maschinennähere und effizientere“.
Im Entwurfstext heißt es, der Zielcode wäre von „identischem Informationsgehalt“. Das ist zu einschränkend und dadurch falsch. Ich schrieb hingegen dazu: „im Wesentlichen gleiche Funktionalität und Informationsgehalt.“ Grund: Schon durch Optimierung, Parallelisierung, Zufügen von Debugging-Informationen, aber vor allem Informationsverluste von in der Zielsprache nicht vorhandenen Sprachelementen kann es sehr wohl und sehr oft zu etwas unterschiedlichem Informationsgehalt kommen, der sich aber nur geringfügig unterscheidet. Die wesentliche Funktionalität bei der späteren Ausführung bleibt hingegen gleich.
Gute Nacht --PerfektesChaos 23:34, 28. Jun. 2013 (CEST)
- Besonders aufgrund Deiner Einwände zu Compiler (Hochsprachen) werde ich die Entwurfstexte nochmal auf Formulierungen aus belegten Quellen verändern. Zu Details aus deinem Beitrag habe ich in deinem Text direkt >>> Antworten in dieser Schriftart eingefügt. Magst du aus der Sicht, dass HIER nur ein Überblick gegeben werden soll (wie schon mit <12:33, 12. Jun. 2013> und <09:44, 13. Jun. 2013> festgestellt wurde), nochmal kurz 'drüber schauen'? Danke.--VÖRBY (Diskussion) 13:00, 29. Jun. 2013 (CEST)
Weitere Diskussionen ggf. im neuen Artikel. --VÖRBY (Diskussion) 16:01, 3. Jul. 2013 (CEST)
Elimination toten Programmcodes
Diese Überschrift "Elimination toten Programmcodes" ist wohl nicht ganz klar. Müsste es nicht richtiger heißen: "Elimination von toten Programmcodes" oder altern. "Elimination toter Programmcodes"? –--Horst bei Wiki (Diskussion) 16:30, 13. Mai 2014 (CEST)
- Nein, denn man spricht von totem Code, nicht toten Codes. Code ist hier bereits ein Plural. --Echoray (Diskussion) 17:52, 13. Mai 2014 (CEST)
- Jein, eigentlich nein. "Code" ist hier natürlich kein Plural.
- Das Wort "Code" hat zwei Bedeutungen:
- Programmcode = viele Textzeilen, die Anweisungen, Definitionen u.ä. enthalten (Annahme: Quellcode ist gemeint)
- Schlüsselcode = ein einzelner (Zahlen-)Wert
- In dem Abschnitt ist Bedeutung 1 gemeint, und damit steht das Wort im Genitiv Singular, in der Bedeutung "viele Zeilen Anweisungen".
- --arilou (Diskussion) 09:44, 15. Mai 2014 (CEST)
- Programmcode ist männlich. Niemand sagt "die Programmcode ist schlecht". Also genitiv singular maskulin: "Elimination toten Programmcodes" oder besser "Elimination des toten Programmcodes". --Sebastian.Dietrich ✉ 11:32, 15. Mai 2014 (CEST)
- Danke für die Präzisierung, das hatte ich einfach als bekannt vorausgesetzt ~ es war ja vor allem die Frage nach Singular vs. Plural. --arilou (Diskussion) 12:07, 15. Mai 2014 (CEST)
Dann wär's doch gut, wir setzten den Text von Sebastian.Dietrich, der unter "oder besser" steht, dort rein: "Elimination des toten Programmcodes". Und schon verstehen alle, was dort gemeint ist. --Horst bei Wiki (Diskussion) 12:25, 15. Mai 2014 (CEST)–
- Die "des"-Variante finde ich schlechter, da sie unterstellt, es gäbe 'einen' toten Programmcode. Tatsächlich kann es ja mehrere Programmcode-Abschnitte an verschiedenen Stellen geben, die entfernt werden. Wie "Abholzen toten Walds" - das können viele Stellen sein, "toten Walds" stellt eine -hm- Gattungsbeschreibung dar. "Abholzen des toten Walds" deutet an, es gäbe genau 1 solchen Wald, und selbiger werde abgeholzt.
- Also: -1, die bisherige Überschrift ist gut, genau so wie sie lautet.
- --arilou (Diskussion) 13:49, 15. Mai 2014 (CEST)
- +1
- Ein "des" suggeriert mir auch, dass es "den einen" toten Code gibt.
- Ggf. mit unbestimmtem Artikel: "Eliminiation von totem Programmcode"? (Wie es bereits in der ersten AW von Echoray formuliert wurde.)--Plankton314 (Diskussion) 13:57, 15. Mai 2014 (CEST)
- Zustimmung zu beiden Vorrednern: Das halte ich auch nicht für besser, weil gemeint ist, "jeglichen, evt. vorhandenen toten Programmcodes". Außerdem wird dieser Auisdruck hier als Aufzählungspunkt (Überschrift) und deshalb als substantiviertes Verb benutzt. Und wird hier als Bezeichnung für eine Funktion verwendet, nicht für eine (individuell denkbare) Tätigkeit. Die Aussage "... des ..." wäre mE möglich, wenn der Sachverhalt "toter Code" vorher im Text behandelt worden wäre. Evtl. liegt hier aber auch ein "Zählen von Erbsen", nicht ein "Zählen der Erbsen" vor. ;-) --VÖRBY (Diskussion) 14:05, 15. Mai 2014 (CEST), ergänzt 'Bezeichnung': --VÖRBY (Diskussion) 17:55, 15. Mai 2014 (CEST)
- +1 für "Eliminiation von totem Programmcode" --Sebastian.Dietrich ✉ 14:42, 15. Mai 2014 (CEST)
- -1 für "Eliminiation von totem Programmcode"
- Weil: Der Dativ ist dem Genitiv sein Tod.
- Nieder mit dem Dativ! Werft den Purschen zu Poden!
- --arilou (Diskussion) 16:03, 15. Mai 2014 (CEST)
- Klingt als Argument immer gut, hat aber hier nichts mit Dativ/Genitiv zu tun.--Plankton314 (Diskussion) 16:16, 15. Mai 2014 (CEST)
- Eigentlich schon, aber in den Genitivregeln ist ausdrücklich davon die Rede, dass man in verschiedenen Situationen auch im Dativ (hier mit 'von') formulieren kann, z.B. heißt es 'Regierung von Oberbayern', nicht 'Oberbayerns Regierung'. Auch spielt die Landsmannschaft eine Rolle: Wo wird wie gesprochen? Da hier im Beispiel aber schon der Ausdruck 'Codes', auch hinsichtlich Plural/Singular zu Missverständnissen führen kann, bin ich auch für "Eliminieren von totem Programmcode". Insgesamt aber wirklich 'Erbsenzählerei'. Hoffentlich beginnt jetzt nicht eine neue Diskussion um die '...ion'-Form. --VÖRBY (Diskussion) 17:55, 15. Mai 2014 (CEST)
- Tja... alles für die Enzyklopädie.
- Habs jetzt (nachdem sonst auch nix mehr kam) mal geändert und denke, man kann das hier erl'en.--Plankton314 (Diskussion) 20:54, 20. Mai 2014 (CEST)
- Eigentlich schon, aber in den Genitivregeln ist ausdrücklich davon die Rede, dass man in verschiedenen Situationen auch im Dativ (hier mit 'von') formulieren kann, z.B. heißt es 'Regierung von Oberbayern', nicht 'Oberbayerns Regierung'. Auch spielt die Landsmannschaft eine Rolle: Wo wird wie gesprochen? Da hier im Beispiel aber schon der Ausdruck 'Codes', auch hinsichtlich Plural/Singular zu Missverständnissen führen kann, bin ich auch für "Eliminieren von totem Programmcode". Insgesamt aber wirklich 'Erbsenzählerei'. Hoffentlich beginnt jetzt nicht eine neue Diskussion um die '...ion'-Form. --VÖRBY (Diskussion) 17:55, 15. Mai 2014 (CEST)
- Klingt als Argument immer gut, hat aber hier nichts mit Dativ/Genitiv zu tun.--Plankton314 (Diskussion) 16:16, 15. Mai 2014 (CEST)
Inline-Ersetzung = Makro
Ich bin schon der Ansicht, dass es bis auf winzige Details auf dasselbe hinausläuft, ob man Makros oder Inline-Ersetzung verwendet. Und diese Makros sind ja bitteschön nicht nur im Assembler-Bereich verbreitet, sondern auch zahlreich in den Include-Files der C- und C++-Sources. --PeterFrankfurt (Diskussion) 04:51, 22. Mai 2014 (CEST)
- Das mag sein. Aber im Text steht jetzt, dass der Aufwand zum Aufruf ("ähnlich wie bei einem Makro") stärker ins Gewicht falle. Das ist aber bei bestimmten Makros nicht der Fall, dort fällt Null Aufrufaufwand an, weil der Compiler die Auflösung besorgt. In manchen Fällen stimmt das Gesagte so also nicht. --VÖRBY (Diskussion) 08:38, 22. Mai 2014 (CEST)
- Hier gibt es vor allem einen fundamentalen Unterschied:
- Ein Makro läuft (nach üblicher Begriffsverwendung) vorher ab; genauer: in einem Präprozessor.
- Es handelt sich um eine reine Textersetzung.
- Daraus wird zuvor der eigentliche Quellcode generiert, und nur den bekommt der eigentliche Compiler zu sehen, erst recht eine Code-Optimierung.
- Das gilt unbeschadet dessen, dass etwa moderne C/C++-Compiler preprocessing und compiling in ein und demselben Arbeitsgang erledigen.
- Die Syntax der Makros gehört der Präprozessor-Sprache an.
- Inline-Ersetzung wird durch Anweisungen im eigentlichen Quellcode oder aber automatisiert bei der Optimierung ausgelöst. Sie wird vom Compiler und (selten) einem nachgeschalteten Optimierer ausgeführt.
- Wenn sie manuell vorgegeben wird, gehört die Syntax der Quellcode-Sprache an.
- Ein Makro läuft (nach üblicher Begriffsverwendung) vorher ab; genauer: in einem Präprozessor.
- Der Sinn der Aussage „ähnlich wie bei einem Makro“ ist allerdings kryptisch und erschließt sich mir nicht.
- Was ist da mit wem ähnlich? Der Aufwand? Ist das viel oder wenig, gut oder schlecht?
- Vielleicht ist im Lauf der Formulierungsbastelei mal der Sinn verlorengegangen. Ursprünglich könnte es mal geheißen haben: „Inline ist sowas ähnliches wie Makro“.
- Das Prinzip ist gleich, und die Effizienz des fertigen Codes ist auch gleich. Der Unterschied ist, dass das Makro vor der Kompilierung den Quellcode geschickt so umformt, dass der häufiger benötigte komplizierte Berechnungsausdruck schon im Statement steht, und bei der Funktionsersetzung im Moment der Kompilierung oder nachgeschaltet der Code einer Funktion anhand aktueller Parameter aufgelöst direkt in das Maschinencode-Statement geschrieben wird.
- Maßgeblich für die Effizienz ist das ausgeführte Programm. Ob der Kompilierungsvorgang für die Auflösung eines Makros oder eine simple Optimierung ein paar Millionstel Sekunden mehr oder weniger dauert, ist irrelevant.
- VG --PerfektesChaos 09:44, 22. Mai 2014 (CEST)
- VG --PerfektesChaos 09:44, 22. Mai 2014 (CEST)
- Es gibt zwei Möglichkeiten, immer wiederkehrende Befehlsfolgen zu behandeln: Ein Unterprogramm/Funktion---Oder ein Makro. Mit letzterem erreiche ich als Nebeneffekt Inlining. So wird das ursprünglich gemeint worden sein, nehm' ich an. --RobTorgel 10:00, 22. Mai 2014 (CEST)
- Hier gibt es vor allem einen fundamentalen Unterschied:
- Wie PerfektesChaos bereits schrieb, sind Makros und Inline-Funktionen zwei grundverschiedene Dinge. Die Unterschiede, die mir spontan (noch) einfallen sind:
- Makros sind global (was meistens schlecht ist)
- Makros sind Präprozessor-Befehle (reine Textersetzung, s.o.)
- Makros lassen keine statische Typprüfung beim Aufruf zu
- Der Compiler kann nicht nach eigener (Kosten/Nutzen-)Analyse entscheiden kann, ob er den Code inline't oder nicht, da er bereits im Vorfeld überall ersetzt wird
- Gibt es außer C (und Konsorten) und anscheinend LISP (siehe Makro) überhaupt Programmiersprachen, in denen man Makros in dieser Form zum Inlining missbrauchen kann?--Plankton314 (Diskussion) 16:22, 22. Mai 2014 (CEST)
- Wie PerfektesChaos bereits schrieb, sind Makros und Inline-Funktionen zwei grundverschiedene Dinge. Die Unterschiede, die mir spontan (noch) einfallen sind:
Dass der Aufrufaufwand - bei Makros - 'verhältnismäßig' hoch ist, trifft zumindest nicht auf alle Makros zu. Eher schon die Tatsache, dass auch bei Makros Inline-Code eingefügt werden kann. Ich habe deshalb den Halbsatz an diese entsprechende Textstelle verschoben.
Allerdings 'zieht' das Argument 'Aufrufaufwand' heutzutage wohl nicht mehr wirklich; denn dann dürfte man auch keine Hochsprachen verwenden. Interessant wäre aus meiner Sicht für diesen Abschnitt die Nennung anderer Kriterien, nach denen dieses Inlining praktiziert oder nicht praktiziert wird. Die Größe allein (bzw. das Verhältnis von Aufruf- zu Verarbeitungsaufwand) scheint mir jedenfalls nicht geeignet. Insofern wäre es wohl sinnvoll, dem Aufruf einen Parameter mitzugeben, ob Inlining stattfinden soll oder nicht. Zumindest müsste das UP wohl in derselben Sprache vorliegen; sollte/könnte auch erwähnt werden. Viele FAspekte, über die Minisache mit dem Makro hinausgehend. --VÖRBY (Diskussion) 12:23, 22. Mai 2014 (CEST)
- Auch wenn heutige CPUs einen Großteil ihrer Zeit mit Prefetching verbringen, lohnt es sich immer noch. Daneben gibt es aber auch noch einen Haufen kleinerer (eingebettete) Systeme, die einen Prozessor an Bord haben, der das nicht die ganze Zeit tut (oder tun möchte).
- I.d.R. werden bei einem Funktionsaufruf die Register gesichert und der Stack eingerichtet (enter/leave). Das ist nicht viel, sind aber doch ein paar Befehle. Wenn die aufgerufene Funktion dann nur aus einem oder zwei Befehlen besteht, ist es gut möglich, dass mehr Code für das Vor- und Nachbereiten des Funktionsaufrufs benötigt wird, als für die eigentliche Funktion.
- Und wenn das ganze dann noch zig mal in einer Schleife gemacht wird, lässt sich leicht eine Beschleunigung auf das Doppelte und Dreifache erreichen.
- Deshalb ist es zB. ein Mythos, dass explizite get/set-Methoden in C++ für Klassenattribute ineffizient wären, weil sie ohnehin ge"inline"t werden.--Plankton314 (Diskussion) 16:22, 22. Mai 2014 (CEST)
- Ich würde nicht so tief in die technischen Details einsteigen. PeterFrankfurt wollte wahrscheinlich nur ein Vergleichsbeispiel für das Inlinen einstellen, und dazu sind ihm Makros eingefallen - was ja i.W. (siehe Korr dazu [6]) nicht ganz falsch ist. Damit sollte DIESER Aspekt m.E. ERLEDIGT sein.
- Ob der Abschnitt um weitere Aussagen erweitert werden könnte (z.B. WER steuert das Inlining WIE und WARUM?), wäre eine andere Sache - weshalb man z.B. mit (== Inline-Ersetzung - wie und warum ==) einen neuen Disk-Abschnitt beginnen könnte, wenn man will. --VÖRBY (Diskussion) 19:31, 22. Mai 2014 (CEST)
Code
Die laut Compiler#Einsparung von Maschinenbefehlen mögliche Optimierung verlangsamt Code um etwa den Faktor 4.
Auführungszeiten auf Online-C-Compiler:
0 instructions + loop (no exchange): 3.970 clocks/round 1 instruction + loop (reg exchange): 4.403 clocks/round 6 instruction + loop (mem exchange): 23.029 clocks/round 4 instruction + loop (mem exchange): 23.039 clocks/round 3 instruction + loop (mem exchange): 94.210 clocks/round Das ist der optimiert Code mit nur 3 Befehlen
Der dazugehörige Code (x86-64):
/******************************************************************************
Online C Compiler.
Code, Compile, Run and Debug C program online.
Write your code in this editor and press "Run" button to compile and execute it.
*******************************************************************************/
#include <stdio.h>
static __inline__ unsigned long long rdtsc(void)
{
unsigned long lo, hi;
asm( "rdtsc" : "=a" (lo), "=d" (hi) );
return lo | ((long long)hi << 32);
}
int a = 1;
int b = 2;
static void Code_Dummy() // Liefert Ausführungszeit für die leere Schleife
{
printf ("%u %u\n", a, b);
long long const T1 = rdtsc();
asm ("push %rdx");
asm ("push %rbx");
asm ("push %rax");
asm ("mov $1000000001, %edx");
asm ("mov a, %eax");
asm ("mov b, %ebx");
asm (".lbl9:");
asm ("dec %edx");
asm ("jnz .lbl9");
asm ("mov %eax, a");
asm ("mov %ebx, b");
asm ("pop %rax");
asm ("pop %rbx");
asm ("pop %rdx");
long long const T2 = rdtsc();
printf ("%u %u\n", a, b);
printf ("0 instructions + loop (no exchange): %6.3f clocks/round\n", (T2-T1)/1000000001.0);
}
static void Code0() // Austausch zweier Register
{
printf ("%u %u\n", a, b);
long long const T1 = rdtsc();
asm ("push %rdx");
asm ("push %rbx");
asm ("push %rax");
asm ("mov $1000000001, %edx");
asm ("mov a, %eax");
asm ("mov b, %ebx");
asm (".lbl0:");
asm ("xchg %eax, %ebx");
asm ("dec %edx");
asm ("jnz .lbl0");
asm ("mov %eax, a");
asm ("mov %ebx, b");
asm ("pop %rax");
asm ("pop %rbx");
asm ("pop %rdx");
long long const T2 = rdtsc();
printf ("%u %u\n", a, b);
printf ("1 instruction + loop (reg exchange): %6.3f clocks/round\n", (T2-T1)/1000000001.0);
}
static void Code1() // Austausch zweier RAM-Zellen, 6 Befehle wie in WP
{
printf ("%u %u\n", a, b);
long long const T1 = rdtsc();
asm ("push %rdx");
asm ("push %rbx");
asm ("push %rax");
asm ("mov $1000000001, %edx");
asm (".lbl1:");
asm ("mov a, %eax");
asm ("mov %eax, %ebx");
asm ("mov b, %eax");
asm ("mov %eax, a");
asm ("mov %ebx, %eax");
asm ("mov %eax, b");
asm ("dec %edx");
asm ("jnz .lbl1");
asm ("pop %rax");
asm ("pop %rbx");
asm ("pop %rdx");
long long const T2 = rdtsc();
printf ("%u %u\n", a, b);
printf ("6 instruction + loop (mem exchange): %6.3f clocks/round\n", (T2-T1)/1000000001.0);
}
static void Code2() // Austausch zweier RAM-Zellen, 4 Befehle wie eher üblich
{
printf ("%u %u\n", a, b);
long long const T1 = rdtsc();
asm ("push %rdx");
asm ("push %rbx");
asm ("push %rax");
asm ("mov $1000000001, %edx");
asm (".lbl2:");
asm ("mov a, %eax");
asm ("mov b, %ecx");
asm ("mov %eax, b");
asm ("mov %ecx, a");
asm ("dec %edx");
asm ("jnz .lbl2");
asm ("pop %rax");
asm ("pop %rbx");
asm ("pop %rdx");
long long const T2 = rdtsc();
printf ("%u %u\n", a, b);
printf ("4 instruction + loop (mem exchange): %6.3f clocks/round\n", (T2-T1)/1000000001.0);
}
static void Code3() // Austausch zweier RAM-Zellen, 3 Befehle, optimiert laut WP
{
printf ("%u %u\n", a, b);
long long const T1 = rdtsc();
asm ("push %rdx");
asm ("push %rbx");
asm ("push %rax");
asm ("mov $1000000001, %edx");
asm (".lbl3:");
asm ("mov a, %eax");
asm ("xchg b, %eax");
asm ("mov %eax, a");
asm ("dec %edx");
asm ("jnz .lbl3");
asm ("pop %rax");
asm ("pop %rbx");
asm ("pop %rdx");
long long const T2 = rdtsc();
printf ("%u %u\n", a, b);
printf ("3 instruction + loop (mem exchange): %6.3f clocks/round\n", (T2-T1)/1000000001.0);
}
int main()
{
Code_Dummy();
Code0();
Code1();
Code2();
Code3();
return 0;
}
--2003:C3:6713:D200:DC3F:78DE:1ACC:DB28 01:11, 26. Mai 2020 (CEST)
- Im Artkel wird 'XCHG' nicht ein einziges Mal genannt. Im kritisierten Abschnitt steht: "Mit der Optimierung werden statt 6 nur noch 4 Assemblerbefehle benötigt". Die "optimiert laut WP"-Variante entspricht deiner Methode Code2, und die ist zumindest nicht langsamer als die unoptimierte Version (im Rahmen der Messgenauigkeit).
- Ich kann im Artikel nirgends lesen, dass sich dessen Aussagen speziell auf die x86-Welt beziehen würden.
- Es wird von "Optimierungsmöglichkeiten" gesprochen, sowie "in Abhängigkeit von den Eigenschaften der Hardware". Dass bestimmte Maschinenbefehle ggf. nur noch aus Kompatibilitätsgründen vorhanden und langsam sind, ist ja wohl eine Eigenschaft der Hardware/Architektur.
- Somit sehe ich nicht einen einzigen Satz, nicht eine einzige Aussage, die im Artikel irgendwie zu ändern wäre. Stimmt alles genau so, wie's dort steht.
- --arilou (Diskussion) 10:04, 26. Mai 2020 (CEST)
- Nachtrag: Deine "6 Befehle"-Variante ist ebenfalls falsch umgesetzt. Die WP-Version sieht vor, dass 'hilf' eine Variable, also eine Speicherstelle im Hauptspeicher ist. Also
- Lade a(Hauptspeicher) -> Register1
- Speichere Register1 -> hilf(Hauptspeicher)
- Lade b(Hauptspeicher) -> Register1
- Speichere Register1 -> a(Hauptspeicher)
- Lade hilf(Hauptspeicher) -> Register1
- Speichere Register1 -> b(Hauptspeicher)
- Du hast stattdessen für 'hilf' ein Register verwendet, was bereits eine Optimierung darstellt.
- --arilou (Diskussion) 10:13, 26. Mai 2020 (CEST)
- Und wenn ich schon mal beim Kritisieren bin: In einer Schleife immer wieder dieselben 3 Speicherstellen (für a, b und hilf) anzusteuern, ist praktisch optimal für Caching. In einem realen Programm dürfte ein eingesparter Ram-Zugriff auf 'hilf' mit ggf. notwendigem Cache-Umladen deutlich größeres Einspaar-Potential ergeben.
- --arilou (Diskussion) 10:25, 26. Mai 2020 (CEST)