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 von stdio.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)

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)

[[2]] -- Arist0s 22:26, 12. 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)

Erledigt 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. --DF5GO 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" />

,

<code />

oder ähnlichem.

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

oder so ähnlich. v0 ist das Ergebnis.

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)

Dieser Abschnitt kann archiviert werden. VÖRBY (Diskussion) 19:01, 1. Nov. 2012 (CET)

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)

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.

Dieser Abschnitt kann archiviert werden. VÖRBY (Diskussion) 18:40, 1. Nov. 2012 (CET)

Zu viele Unterschiede

Dieser Abschnitt kann archiviert werden. VÖRBY (Diskussion) 18:48, 1. Nov. 2012 (CET)

(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)

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.