Ein Bearbeiter ist ein Computerprogramm (oder Satz von Programmen), der Quellcode umgestaltet, der auf einer Programmiersprache (die Quellsprache) in eine andere Computersprache (die Zielsprache geschrieben ist, häufig eine binäre Form als Gegenstand-Code wissen lassend). Der allgemeinste Grund dafür, Quellcode umgestalten zu wollen, soll ein rechtskräftiges Programm schaffen.

Der Name "Bearbeiter" wird in erster Linie für Programme verwendet, die Quellcode von einer Programmiersprache auf höchster Ebene bis eine Sprache der niedrigeren Ebene (z.B, Zusammenbau-Sprache oder Maschinencode) übersetzen. Wenn das kompilierte Programm auf einem Computer laufen kann, dessen Zentraleinheit oder Betriebssystem von demjenigen verschieden sind, auf dem der Bearbeiter läuft, ist der Bearbeiter als ein Quer-Bearbeiter bekannt. Ein Programm, das von einer Sprache der niedrigen Stufe bis ein höheres Niveau übersetzt, ist man ein Dekompilierer. Ein Programm, das zwischen höheren Programmiersprachen übersetzt, wird gewöhnlich einen Sprachübersetzer, Quelle dem Quellübersetzer oder Sprachkonverter genannt. Ein Sprachwiederschriftsteller ist gewöhnlich ein Programm, das die Form von Ausdrücken ohne eine Änderung der Sprache übersetzt.

Ein Bearbeiter wird wahrscheinlich viele oder alle folgenden Operationen durchführen: Lexikalische Analyse, Aufbereitung, Syntaxanalyse, semantische Analyse (Syntax-geleitete Übersetzung), codiert Generation und Codeoptimierung.

Durch das falsche Bearbeiter-Verhalten verursachte Programm-Schulden können sehr schwierig sein, ausfindig zu machen und ringsherum zu arbeiten; deshalb investiert Bearbeiter implementors bedeutende Anstrengung, die Genauigkeit ihrer Software zu sichern.

Der Begriff Bearbeiter-Bearbeiter wird manchmal gebraucht, um sich auf einen parser Generator zu beziehen, ein Werkzeug hat häufig gepflegt zu helfen, den lexer und parser zu schaffen.

Geschichte

Die Software für frühe Computer wurde in erster Linie auf der Zusammenbau-Sprache geschrieben. Höhere Niveau-Programmiersprachen wurden nicht erfunden, bis die Vorteile des im Stande Seins, Software auf verschiedenen Arten von Zentraleinheiten wiederzuverwenden, angefangen haben, bedeutsam größer zu werden, als die Kosten, einen Bearbeiter zu schreiben. Die beschränkte Speicherkapazität von frühen Computern hat zu wesentlichen technischen Herausforderungen geführt, als sie die ersten Bearbeiter entworfen hat.

Zum Ende der 1950er Jahre wurden maschinenunabhängige Programmiersprachen zuerst vorgeschlagen. Nachher wurden mehrere experimentelle Bearbeiter entwickelt. Der erste Bearbeiter wurde von Grace Hopper 1952 für die a-0 Programmiersprache geschrieben. Die FORTRAN Mannschaft, die von John Backus an IBM geführt ist, wird allgemein als eingeführt den ersten ganzen Bearbeiter 1957 geglaubt. COBOL war eine frühe Sprache, die auf vielfachen Architekturen 1960 zu kompilieren ist.

In vielen Anwendungsgebieten hat die Idee, eine höhere Niveau-Sprache zu verwenden, schnell Anklang gefunden. Wegen der dehnbaren Funktionalität, die durch neuere Programmiersprachen und die zunehmende Kompliziertheit von Computerarchitekturen unterstützt ist, sind Bearbeiter komplizierter geworden.

Frühe Bearbeiter wurden auf der Zusammenbau-Sprache geschrieben. Der erste Selbstbewirtungsbearbeiter - fähig dazu, seinen eigenen Quellcode auf einer höheren Programmiersprache zu kompilieren - wurde 1962 für das Lispeln von Tim Hart und Mike Levin an MIT geschaffen. Seit den 1970er Jahren ist es übliche Praxis geworden, um einen Bearbeiter auf der Sprache durchzuführen, die es kompiliert, obwohl sowohl Pascal als auch C populäre Wahlen für die Durchführungssprache gewesen sind. Das Gebäude eines Selbstbewirtungsbearbeiters ist ein Urladeverfahren-Problem — der erste derartige Bearbeiter für eine Sprache muss entweder mit der Hand oder durch einen Bearbeiter kompiliert werden, der auf einer verschiedenen Sprache, oder (als in Hart und dem Lispeln-Bearbeiter von Levin) geschrieben ist, kompiliert durch das Laufen des Bearbeiters in einem Dolmetscher.

Bearbeiter in der Ausbildung

Bearbeiter-Aufbau und Bearbeiter-Optimierung werden an Universitäten und Schulen als ein Teil eines Informatik-Lehrplans unterrichtet. Solche Kurse werden gewöhnlich mit der Durchführung eines Bearbeiters für eine Bildungsprogrammiersprache ergänzt. Ein gut dokumentiertes Beispiel ist der PL/0 Bearbeiter von Niklaus Wirth, den Wirth gepflegt hat, Bearbeiter-Aufbau in den 1970er Jahren zu unterrichten. Trotz seiner Einfachheit hat der PL/0 Bearbeiter mehrere einflussreiche Konzepte ins Feld eingeführt:

1. Programm-Entwicklung durch die schrittweise Verfeinerung (auch der Titel eines 1971-Vortrages von Wirth)
2. Der Gebrauch eines rekursiven Abstiegs parser
3. Der Gebrauch von EBNF, um die Syntax einer Sprache anzugeben
4. Ein Codegenerator, der tragbaren P-Code erzeugt
5. Der Gebrauch von T-Diagrammen in der formellen Beschreibung des Urladeverfahren-Problems

Kompilation

Bearbeiter haben die Entwicklung von Programmen ermöglicht, die maschinenunabhängig sind. Vor der Entwicklung von FORTRAN (Formel-Übersetzer), die erste Sprache des höheren Niveaus, in den 1950er Jahren, wurde maschinenabhängige Zusammenbau-Sprache weit verwendet. Während Zusammenbau-Sprache mehr wiederverwendbar und relativierbare Programme erzeugt als Maschinencode auf derselben Architektur, muss es modifiziert oder umgeschrieben werden, wenn das Programm auf der verschiedenen Computerhardware-Architektur durchgeführt werden soll.

Mit dem Fortschritt von Programmiersprachen auf höchster Ebene, die FORTRAN, wie COBOL, C, und GRUNDLEGEND gefolgt sind, konnten Programmierer maschinenunabhängige Quellprogramme schreiben. Ein Bearbeiter übersetzt die Quellprogramme auf höchster Ebene in Zielprogramme auf Maschinensprachen für die spezifische Hardware. Sobald das Zielprogramm erzeugt wird, kann der Benutzer das Programm durchführen.

Struktur eines Bearbeiters

Quellprogramme der Compilers Bridge auf höheren Programmiersprachen mit der zu Grunde liegenden Hardware. Ein Bearbeiter verlangt 1) Bestimmung der Genauigkeit der Syntax von Programmen, 2) das Erzeugen richtigen und effizienten Gegenstand-Codes, 3) Laufzeitorganisation und 4) Formatierung der Produktion gemäß dem Monteur und/oder der linker Vereinbarung. Ein Bearbeiter besteht aus drei Hauptrollen: der frontend, das mittlere Ende und der backend.

Das Vorderende überprüft, ob das Programm in Bezug auf die Programmiersprache-Syntax und Semantik richtig geschrieben wird. Hier werden gesetzliche und ungesetzliche Programme anerkannt. Fehler, werden falls etwa, auf eine nützliche Weise ausgegeben. Datentypprüfung wird auch durch das Sammeln der Typ-Information durchgeführt. Der frontend erzeugt dann eine Zwischendarstellung oder IR des Quellcodes, um bis zum mittleren Ende in einer Prozession zu gehen.

Die Mitte des Mais ist, wo Optimierung stattfindet. Typische Transformationen für die Optimierung sind Eliminierung von nutzlosem oder unerreichbarem Code, Entdeckung und Fortpflanzung von unveränderlichen Werten, Wiederposition der Berechnung zu einem weniger oft durchgeführten Platz (z.B, aus einer Schleife), oder Spezialisierung der auf dem Zusammenhang gestützten Berechnung. Das mittlere Ende erzeugt einen anderen IR für den folgenden backend. Die meisten Optimierungsanstrengungen werden auf diesen Teil eingestellt.

Das Zurückende ist dafür verantwortlich, den IR vom mittleren Ende in den Zusammenbau-Code zu übersetzen. Die Zielinstruktion (En) wird für jede IR Instruktion gewählt. Register-Zuteilung teilt Verarbeiter-Register für die Programm-Variablen wo möglich zu. Der backend verwertet die Hardware dadurch sich zu belaufen, wie man parallele Ausführungseinheiten beschäftigt hält, Verzögerungsablagefächer und so weiter füllend. Obwohl die meisten Algorithmen für die Optimierung in NP sind, werden heuristische Techniken gut entwickelt.

Bearbeiter-Produktion

Eine Klassifikation von Bearbeitern ist durch die Plattform, auf der ihr erzeugter Code durchführt. Das ist als die Zielplattform bekannt.

Ein heimischer oder veranstalteter Bearbeiter ist derjenige, den Produktion beabsichtigt ist, um auf demselben Typ des Computers und Betriebssystems direkt zu führen, auf dem der Bearbeiter selbst läuft. Die Produktion eines bösen Bearbeiters wird entworfen, um auf einer verschiedenen Plattform zu laufen. Böse Bearbeiter werden häufig verwendet, wenn man Software für eingebettete Systeme entwickelt, die nicht beabsichtigt sind, um eine Softwareentwicklungsumgebung zu unterstützen.

Die Produktion eines Bearbeiters, der Code für eine virtuelle Maschine (VM) erzeugt, kann oder darf auf derselben Plattform wie der Bearbeiter nicht durchgeführt werden, der es erzeugt hat. Aus diesem Grund werden solche Bearbeiter als heimische oder böse Bearbeiter nicht gewöhnlich klassifiziert.

Die Sprache der niedrigeren Ebene, die Ziel eines Bearbeiters ist, kann selbst eine Programmiersprache auf höchster Ebene sein.

C, der häufig als eine Art tragbarer Monteur angesehen ist, kann auch die Zielsprache eines Bearbeiters sein.

Z.B: Cfront, der ursprüngliche Bearbeiter für C ++ hat C als Zielsprache verwendet.

Kompiliert gegen interpretierte Sprachen

Programmiersprachen des höheren Niveaus erscheinen gewöhnlich mit einem Typ der Übersetzung im Sinn: entweder entworfen als kompilierte Sprache oder interpretierte Sprache. Jedoch in der Praxis gibt es selten irgendetwas über eine Sprache, die verlangt, dass es exklusiv kompiliert oder exklusiv interpretiert wird, obwohl es in Entwurfsprachen möglich ist, die sich auf die Umdeutung in der Durchlaufzeit verlassen. Die Kategorisierung widerspiegelt gewöhnlich, dass die populärsten oder weit verbreiteten Durchführungen einer Sprache - zum Beispiel, GRUNDLEGEND manchmal eine interpretierte Sprache und C ein kompilierter, trotz der Existenz von GRUNDLEGENDEN Bearbeitern und C Dolmetschern genannt wird.

Interpretation ersetzt Kompilation völlig nicht. Es verbirgt es nur vor dem Benutzer und macht es allmählich. Wenn auch ein Dolmetscher selbst interpretiert werden kann, ist ein direkt durchgeführtes Programm irgendwo an der Unterseite vom Stapel erforderlich (sieh Maschinensprache). Moderne Tendenzen zu gerade rechtzeitig der Kompilation und bytecode Interpretation in Zeiten verschmieren die traditionellen Kategorisierungen von Bearbeitern und Dolmetschern.

Einige Sprachspezifizierungen legen das dar Durchführungen müssen eine Kompilationsmöglichkeit einschließen; zum Beispiel, Allgemeines Lispeln. Jedoch gibt es nichts Innewohnendes der Definition des Allgemeinen Lispelns, das es verhindert, interpretiert zu werden. Andere Sprachen haben Eigenschaften, die sehr leicht sind, in einem Dolmetscher durchzuführen, aber das Schreiben eines Bearbeiters viel härter zu machen; zum Beispiel erlauben APL, SNOBOL4 und viele scripting Sprachen Programmen, willkürlichen Quellcode an der Durchlaufzeit mit regelmäßigen Schnur-Operationen zu bauen, und dann diesen Code durch den Übergang davon zu einer speziellen Einschätzungsfunktion durchzuführen. Um diese Eigenschaften auf einer kompilierten Sprache durchzuführen, müssen Programme gewöhnlich mit einer Laufzeitbibliothek verladen werden, die eine Version des Bearbeiters selbst einschließt.

Hardware-Kompilation

Die Produktion von einigen Bearbeitern kann Computerhardware an einer sehr niedrigen Stufe, zum Beispiel Field Programmable Gate Array (FPGA) oder strukturierter Anwendungsspezifischer Einheitlicher Stromkreis (ASIC) ins Visier nehmen. Wie man sagt, sind solche Bearbeiter Hardware-Bearbeiter oder Synthese-Werkzeuge, weil der Quellcode, den sie effektiv kompilieren, die Endkonfiguration der Hardware kontrolliert, und wie es funktioniert; die Produktion der Kompilation ist nicht Instruktionen, die in der Folge - nur eine Verbindung von Transistoren oder Nachschlagetabellen durchgeführt werden.

Zum Beispiel ist XST das Xilinx Synthese-Werkzeug, das verwendet ist, um FPGAs zu konfigurieren. Ähnliche Werkzeuge sind von Altera, Synplicity, Synopsys und anderen Verkäufern verfügbar.

Bearbeiter-Aufbau

In den frühen Tagen hat die ins Bearbeiter-Design gebrachte Annäherung gepflegt, durch die Kompliziertheit der Verarbeitung, die Erfahrung der Person (En) direkt betroffen zu werden, die es und der verfügbaren Mittel entwirft.

Ein Bearbeiter für eine relativ einfache von einer Person geschriebene Sprache könnte ein einzelnes, monolithisches Stück der Software sein. Wenn die Quellsprache groß ist und komplizierte und hohe Qualitätsproduktion erforderlich ist, kann das Design in mehrere relativ unabhängige Phasen gespalten werden. Getrennte Phasen zu haben, bedeutet, dass Entwicklung in kleine Teile aufgeteilt und verschiedenen Leuten gegeben werden kann. Es wird auch viel leichter, eine einzelne Phase durch eine verbesserte zu ersetzen, oder neue Phasen später (z.B, zusätzliche Optimierungen) einzufügen.

Die Abteilung der Kompilationsprozesse in Phasen wurde durch das Produktionsqualitätsprojekt des Bearbeiter-Bearbeiters (PQCC) an der Universität von Carnegie Mellon verfochten. Dieses Projekt hat das Begriff-Vorderende, die Mitte des Mais und Zurückendes eingeführt.

Alle außer dem kleinsten von Bearbeitern haben mehr als zwei Phasen. Jedoch werden diese Phasen gewöhnlich betrachtet als, ein Teil des Vorderendes oder des Zurückendes zu sein. Der Punkt, an dem sich diese zwei Enden treffen, ist für die Debatte offen. Wie man allgemein betrachtet, ist das Vorderende, wo syntaktische und semantische Verarbeitung, zusammen mit der Übersetzung zu einer niedrigeren Ebene der Darstellung stattfindet (als Quellcode).

Die Mitte des Mais wird gewöhnlich entworfen, um Optimierungen auf einer Form außer dem Quellcode oder Maschinencode durchzuführen. Diese Quellcodetransparenz des Codes/Maschine ist beabsichtigt, um allgemeinen Optimierungen zu ermöglichen, zwischen Versionen des Bearbeiters geteilt zu werden, der verschiedene Sprachen und Zielverarbeiter unterstützt.

Das Zurückende nimmt die Produktion von der Mitte. Es kann mehr Analyse, Transformationen und Optimierungen durchführen, die für einen besonderen Computer sind. Dann erzeugt es Code für einen besonderen Verarbeiter und OS.

Diese Front-End/middle/back-End-Annäherung macht es möglich, Vorderenden für verschiedene Sprachen mit Zurückenden für verschiedene Zentraleinheiten zu verbinden. Praktische Beispiele dieser Annäherung sind die GNU-Bearbeiter-Sammlung, LLVM und der Amsterdamer Bearbeiter-Bastelsatz, die vielfache Vorderenden, geteilte Analyse und vielfache Zurückenden haben.

Einpass gegen Mehrpass-Bearbeiter

Das Klassifizieren von Bearbeitern durch die Zahl von Pässen hat seinen Hintergrund in den Hardware-Quellenbeschränkungen von Computern. Das Kompilieren ist mit dem Durchführen von viel Arbeit verbunden, und frühe Computer hatten genug Gedächtnis nicht, um ein Programm zu enthalten, das ganze diese Arbeit getan hat. So wurden Bearbeiter in kleinere Programme aufgeteilt, die jeder einen Pass über die Quelle (oder etwas Darstellung davon) gemacht hat, etwas von der erforderlichen Analyse und den Übersetzungen durchführend.

Die Fähigkeit, in einem einzelnen Pass zu kompilieren, ist als ein Vorteil klassisch gesehen worden, weil sie den Job vereinfacht, einen Bearbeiter zu schreiben, und Einpass-Bearbeiter allgemein Kompilationen schneller durchführen als Mehrpass-Bearbeiter. So, teilweise gesteuert durch die Quellenbeschränkungen von frühen Systemen, wurden viele frühe Sprachen spezifisch entworfen, so dass sie in einem einzelnen Pass (z.B, Pascal) kompiliert werden konnten.

In einigen Fällen kann das Design einer Spracheigenschaft verlangen, dass ein Bearbeiter leistet, mehr als ein übertragen die Quelle. Denken Sie zum Beispiel eine Behauptung, die online 20 der Quelle erscheint, die die Übersetzung einer Behauptung betrifft, die online 10 erscheint. In diesem Fall muss der erste Pass Information über Behauptungen sammeln, die nach Behauptungen erscheinen, dass sie mit der wirklichen Übersetzung betreffen, die während eines nachfolgenden Passes geschieht.

Der Nachteil des Kompilierens in einem einzelnen Pass ist, dass es nicht möglich ist zu leisten, mussten viele der hoch entwickelten Optimierungen hohen Qualitätscode erzeugen. Es kann schwierig sein, genau zu zählen, wie viele Pässe ein Optimierungsbearbeiter macht. Zum Beispiel können verschiedene Phasen der Optimierung einen Ausdruck oft analysieren, aber nur einen anderen Ausdruck einmal analysieren.

Sich einen Bearbeiter in kleine Programme scheiden zu lassen, ist eine Technik, die von für das Produzieren interessierten Forschern verwendet ist, nachweisbar korrigieren Bearbeiter. Der Beweis der Genauigkeit von einer Reihe kleiner Programme verlangt häufig weniger Anstrengung als Beweis der Genauigkeit eines größeren, einzelnen, gleichwertigen Programms.

Während der typische Mehrpass-Bearbeiter-Produktionsmaschinencode von seinem Endpass, es mehrere andere Typen gibt:

• Ein "Quelle-zu-Quelle-Bearbeiter" ist ein Typ des Bearbeiters, der eine hohe Sprache als sein Eingang und Produktionen eine hohe Sprache nimmt. Zum Beispiel wird ein automatischer parallelizing Bearbeiter oft in einem hohen Sprachprogramm als ein Eingang nehmen und dann den Code umgestalten und es mit parallelen Codeanmerkungen kommentieren (z.B. OpenMP) oder Sprachkonstruktionen (z.B die Behauptungen von Fortran).
• Bühne-Bearbeiter, der in die Zusammenbau-Sprache einer theoretischen Maschine, wie einige Einleitungsdurchführungen kompiliert
• Diese Einleitungsmaschine ist auch bekannt als die Abstrakte Maschine von Warren (oder WAM).
• Bearbeiter von Bytecode für Java, Pythonschlange, und noch viele sind auch ein Subtyp davon.
• Gerade rechtzeitig Bearbeiter, der durch Systeme von Plausch und Java, und auch durch den.NET's von Microsoft Common Intermediate Language (CIL) verwendet ist
• Anwendungen werden in bytecode geliefert, der zum heimischen Maschinencode gerade vor der Ausführung kompiliert wird.

Vorderende

Das Vorderende analysiert den Quellcode, um eine innere Darstellung des Programms, genannt die Zwischendarstellung oder IR zu bauen. Es führt auch den Symbol-Tisch, eine Datenstruktur, die jedes Symbol im Quellcode zur verbundenen Information wie Position, Typ und Spielraum kartografisch darstellt. Das wird über mehrere Phasen getan, der etwas vom folgenden einschließt:

1. Linienrekonstruktion. Sprachen, die ihre Schlüsselwörter abziehen oder willkürliche Räume innerhalb von Bezeichnern erlauben, verlangen eine Phase vor der Syntaxanalyse, die die Eingangscharakter-Folge zu einer kanonischen zum parser bereiten Form umwandelt. Das verfeinernde, der rekursive Abstieg, tabellengesteuerter parsers verwendet lesen in den 1960er Jahren normalerweise die Quelle ein Charakter auf einmal und haben keine getrennte tokenizing Phase verlangt. Atlas-Autocode und Teufelchen (und einige Durchführungen des Algols und Corals 66) sind Beispiele von abgezogenen Sprachen, welche Bearbeiter eine Linienrekonstruktionsphase haben würden.
2. Lexikalische Analyse bricht den Quellcodetext in kleine Stücke genannt Jetons. Jeder Jeton ist eine einzelne Atomeinheit der Sprache, zum Beispiel ein Schlüsselwort, Bezeichner oder Symbol-Name. Die Scheinsyntax ist normalerweise eine regelmäßige Sprache, so kann ein von einem regelmäßigen Ausdruck gebauter Zustandsautomat verwendet werden, um es anzuerkennen. Diese Phase wird auch lexing oder Abtastung genannt, und die Software, die lexikalische Analyse tut, wird einen lexikalischen Analysator oder Scanner genannt.
3. Aufbereitung. Einige Sprachen, z.B, C, verlangen eine Aufbereitungsphase, die Makroersatz und bedingte Kompilation unterstützt. Normalerweise kommt die Aufbereitungsphase vor der syntaktischen oder semantischen Analyse vor; z.B im Fall von C manipuliert der Vorverarbeiter lexikalische Jetons aber nicht syntaktische Formen. Jedoch einige Sprachen wie Schema-Unterstützung Makroersetzungen auf syntaktischen Formen gestützt.
4. Syntax-Analyse ist mit Syntaxanalyse der Scheinfolge verbunden, um die syntaktische Struktur des Programms zu identifizieren. Diese Phase baut normalerweise einen Syntaxanalyse-Baum, der die geradlinige Folge von Jetons mit einer Baumstruktur gebaut ordnungsmäßig einer formellen Grammatik ersetzt, die die Syntax der Sprache definieren. Der Syntaxanalyse-Baum wird häufig analysiert, vermehrt, und dadurch umgestaltet später führt den Bearbeiter stufenweise ein.
5. Semantische Analyse ist die Phase, in der der Bearbeiter semantische Information zum Syntaxanalyse-Baum hinzufügt und den Symbol-Tisch baut. Diese Phase führt semantische Kontrollen wie Datentypprüfung durch (für Typ-Fehler überprüfend), oder Gegenstand-Schwergängigkeit (Variable und Funktionsverweisungen mit ihren Definitionen vereinigend), oder bestimmte Anweisung (das Verlangen alle lokalen Variablen, vor dem Gebrauch initialisiert zu werden), Zurückweisung falscher Programme oder Ausgabe von Warnungen. Semantische Analyse verlangt gewöhnlich einen ganzen Syntaxanalyse-Baum, bedeutend, dass diese Phase logisch der Syntaxanalyse-Phase folgt, und logisch der Codegenerierungsphase vorangeht, obwohl es häufig möglich ist, vielfache Phasen darin zu falten, überträgt man den Code in einer Bearbeiter-Durchführung.

Zurückende

Der Begriff endet zurück ist manchmal mit dem Codegenerator wegen der übergegriffenen Funktionalität verwirrt, Zusammenbau-Code zu erzeugen. Etwas Literaturgebrauch Mitte des Mais, um die allgemeine Analyse und Optimierung zu unterscheiden, führt das Zurückende von den maschinenabhängigen Codegeneratoren stufenweise ein.

Die Hauptphasen des Zurückendes schließen den folgenden ein:

1. Analyse: Das ist das Sammeln der Programm-Information von der Zwischendarstellung ist auf den Eingang zurückzuführen gewesen. Typische Analysen sind Datenfluss-Analyse, um Gebrauch zu bauen - definieren Ketten, Abhängigkeitsanalyse, Deckname-Analyse, Zeigestock-Analyse, Flucht-Analyse usw. Genaue Analyse ist die Basis für jede Bearbeiter-Optimierung. Der Anruf-Graph und Kontrollfluss-Graph werden gewöhnlich auch während der Analyse-Phase gebaut.
2. Optimierung: Die Zwischensprachdarstellung wird in funktionell gleichwertigen, aber schnelleren (oder kleiner) Formen umgestaltet. Populäre Optimierungen sind Reihenvergrößerung, tote Codebeseitigung, unveränderliche Fortpflanzung, Schleife-Transformation, Register-Zuteilung und sogar automatischer parallelization.
3. Codegeneration: Die umgestaltete Zwischensprache wird in die Produktionssprache, gewöhnlich die heimische Maschinensprache des Systems übersetzt. Das schließt Quelle und Lagerungsentscheidungen, wie das Entscheiden der Variablen ein, Register und Gedächtnis und die Auswahl und Terminplanung von passenden Maschineninstruktionen zusammen mit ihren verbundenen Wenden-Weisen einzubauen (sieh auch Algorithmus von Sethi-Ullman). Fehlersuchprogramm-Daten müssen eventuell auch erzeugt werden, um das Beseitigen zu erleichtern.

Bearbeiter-Analyse ist die Vorbedingung für jede Bearbeiter-Optimierung, und sie arbeiten dicht zusammen. Zum Beispiel ist Abhängigkeitsanalyse für die Schleife-Transformation entscheidend.

Außerdem ändert sich das Spielraum der Bearbeiter-Analyse und Optimierungen außerordentlich, von so kleinem wie ein grundlegender Block zum Niveau des Verfahrens/Funktion, oder sogar über das ganze Programm (Zwischenverfahrensoptimierung). Offensichtlich kann ein Bearbeiter einen besseren Job mit einer breiteren Ansicht potenziell tun. Aber dass breite Ansicht nicht frei ist: Große Spielraum-Analyse und Optimierungen sind in Bezug auf die Übersetzungszeit und den Speicherraum sehr kostspielig; das ist für die Zwischenverfahrensanalyse und Optimierungen besonders wahr.

Zwischenverfahrensanalyse und Optimierungen sind in modernen kommerziellen Bearbeitern von HP, IBM, SGI, Intel, Microsoft und Sonne-Mikrosystemen üblich. Der offene Quell-GCC wurde seit langem dafür kritisiert, an starken Zwischenverfahrensoptimierungen Mangel zu haben, aber er ändert sich in dieser Beziehung. Ein anderer offener Quellbearbeiter mit der vollen Analyse- und Optimierungsinfrastruktur ist Open64, der von vielen Organisationen für die Forschung und kommerziellen Zwecke verwendet wird.

Wegen der zusätzlichen Zeit und des Raums, der für die Bearbeiter-Analyse und Optimierungen erforderlich ist, lassen einige Bearbeiter sie standardmäßig aus. Benutzer müssen Kompilationsoptionen verwenden, den Bearbeiter ausführlich zu erzählen, den Optimierungen ermöglicht werden sollten.

Bearbeiter-Genauigkeit

Bearbeiter-Genauigkeit ist der Zweig der Softwaretechnik, die sich mit dem Versuchen befasst zu zeigen, dass sich ein Bearbeiter gemäß seiner Sprachspezifizierung benimmt. Techniken schließen das Entwickeln des Bearbeiters mit formellen Methoden und mit der strengen Prüfung (häufig genannt Bearbeiter-Gültigkeitserklärung) auf einem vorhandenen Bearbeiter ein.

Zusammenhängende Techniken

Zusammenbau-Sprache ist ein Typ der auf niedriger Stufe Sprache und eines Programms, das kompiliert, ist es als ein Monteur mit dem umgekehrten als ein Zurückübersetzer bekannten Programm allgemeiner bekannt.

Ein Programm, das von einer Sprache der niedrigen Stufe bis ein höheres Niveau übersetzt, ist man ein Dekompilierer.

Ein Programm, das zwischen höheren Programmiersprachen übersetzt, wird gewöhnlich einen Sprachübersetzer, Quelle dem Quellübersetzer, Sprachkonverter oder Sprachwiederschriftsteller genannt. Der letzte Begriff wird gewöhnlich auf Übersetzungen angewandt, die keine Änderung der Sprache einschließen.

Ein Programm, das in ein Gegenstand-Codeformat übersetzt, das auf der Kompilationsmaschine nicht unterstützt wird, wird einen bösen Bearbeiter genannt und wird allgemein verwendet, um Code auf eingebettete Anwendungen vorzubereiten.

Internationale Konferenzen und Organisationen

Jedes Jahr sponsern die europäischen Gemeinsamen Konferenzen für die Theorie und Praxis der Software (ETAPS) die Internationale Konferenz für Compiler Construction (CC) mit Papieren sowohl von den akademischen als auch von industriellen Sektoren.

Siehe auch

• Abstrakte Interpretation
• Attribut-Grammatik
• Binärer Wiederbearbeiter
• Von unten nach oben Syntaxanalyse
• Byzantinische Schuld-Toleranz
• kompilieren Sie und gehen Sie Lader
• Kompilieren Sie Farm
• Bearbeiter-Bearbeiter (oder Generator von Parser)
• Bearbeiter-Genauigkeit
• Dekompilierer
• Geschichte des Bearbeiters, schreibend
• Gerade rechtzeitig Kompilation
• Linker
• Liste von Bearbeitern
• Liste von wichtigen Veröffentlichungen im Computer

science#Compilers

• Metacompilation
• Semantik, die verschlüsselt
• Transcompiler

Zeichen

• Bearbeiter-Lehrbuch bringt In einer Sammlung von Verweisungen auf Hauptströmungsbearbeiter-Baulehrbücher Verweise an
• Aho, Alfred V; Sethi, Ravi; und Ullman, Jeffrey D., (internationale Standardbuchnummer 0-201-10088-6) verbinden sich dem Herausgeber. Auch bekannt als "Das Drache-Buch."
• Allen, Frances E., "Eine Geschichte der Sprachverarbeiter-Technologie in IBM", IBM Journal der Forschung und Entwicklung, v.25, Nr. 5, September 1981.
• Allen, Geil; und Kennedy, Kentucky, Bearbeiter für Moderne Architekturen, Herausgeber von Morgan Kaufmann, 2001 Optimierend. Internationale Standardbuchnummer 1-55860-286-0
• Appel, Andrew Wilson
• Moderne Bearbeiter-Durchführung in Java, 2. Ausgabe. Universität von Cambridge Presse, 2002. Internationale Standardbuchnummer 0 521 82060 X
• Moderne Bearbeiter-Durchführung in ML, Universität von Cambridge Presse, 1998. Internationale Standardbuchnummer 0-521-58274-1

• Bornat, Richard, Verstehend und Bearbeiter Schreibend: A Tun Es Selbst Führer, Macmillan, der, 1979 Veröffentlicht. Internationale Standardbuchnummer 0-333-21732-2
• Küfer, Keith D., und Torczon, Linda, Technik ein Bearbeiter, Morgan Kaufmann, 2004, internationale Standardbuchnummer 1-55860-699-8.
• Leverett; Cattel; Hobbs; Neuling; Reiner; Schatz; Wulf, Eine Übersicht des Produktionsqualitätsprojektes des Bearbeiter-Bearbeiters, im Computer 13 (8):38-49 (August 1980)
• McKeeman, William Marshall; Horning, James J.; Wortman, David B., Ein Bearbeiter-Generator, Englewood Klippen, N.J.: Prentice-Hall, 1970. Internationale Standardbuchnummer 0-13-155077-2
• Muchnick, Steven, Fortgeschrittenes Bearbeiter-Design und Durchführung, Herausgeber von Morgan Kaufmann, 1997. Internationale Standardbuchnummer 1-55860-320-4
• Scott, Michael Lee, Programmiersprache-Pragmatik, Morgan Kaufmann, 2005, 2. Ausgabe, 912 Seiten. Internationale Standardbuchnummer 0-12-633951-1 (Die Seite des Autors auf diesem Buch).
• Srikant, Y. N.; Shankar, Priti, Das Bearbeiter-Designhandbuch: Optimierungen und Maschinencodegeneration, CRC Presse, 2003. Internationale Standardbuchnummer 0 8493 1240 X
• Frottiertuch, Patrick D., Bearbeiter und Bearbeiter-Generatoren: Eine Einführung mit C ++, Internationale Computerpresse von Thomson, 1997. Internationale Standardbuchnummer 1-85032-298-8,
• Wirth, Niklaus, Bearbeiter-Aufbau (internationale Standardbuchnummer 0-201-40353-6), Addison-Wesley, 1996, 176 Seiten. Revidierter November 2005.

Außenverbindungen

• Grundlagen des Bearbeiter-Designs durch Torben Ægidius Mogensen