DE69737750T2

DE69737750T2 - Erst- und Zweitprozessoren verwendetes Verfahren

Info

Publication number: DE69737750T2
Application number: DE69737750T
Authority: DE
Inventors: Charles Reed Solomon; Andrea Bristol BS16 Olgiati
Original assignee: Hewlett Packard Development Co LP
Current assignee: HTC Corp
Priority date: 1997-12-17
Filing date: 1997-12-17
Publication date: 2008-03-06
Anticipated expiration: 2017-12-18
Also published as: US6219833B1; DE69737750D1; EP0926594A1; JPH11249904A; EP0926594B1; JP3711206B2

Description

Die vorliegende Erfindung bezieht sich auf die Kompilierung und die Ausführung von Quellcode für eine Prozessorarchitektur, die aus einem primären Prozessor und aus einem (oder mehreren) sekundären Prozessor(en) besteht. Die Erfindung ist insbesondere, obwohl nicht ausschließlich, für die Architekturen relevant, die einen rekonfigurierbaren sekundären Prozessor verwenden.
Ein primärer Prozessor – wie ein Pentium-Prozessor bei einem herkömmlichen PC (Pentium ist eine Handelsmarke der Intel Corporation) – hat sich weiterentwickelt, um vielseitig einsetzbar zu sein dahin gehend, dass derselbe angepasst ist, um einen großen Bereich von Rechenaufgaben zu bewältigen, ohne für irgendeine derselben optimiert zu sein. Ein derartiger Prozessor ist somit nicht optimiert, um rechenintensive Operationen wie z. B. parallele Teilwortaufgaben effizient zu bewältigen. Derartige Aufgaben können bei der Ausführung eines Codes erhebliche Engpässe bewirken.
Ein unternommener Ansatz zur Lösung dieses Problems besteht in der Entwicklung von integrierten Schaltungen, die spezifisch für spezielle Anwendungen angepasst sind. Diese sind als ASICs (application-specific integrated circuits) bzw. anwendungsspezifische integrierte Schaltungen bekannt. Aufgaben, für die eine derartige ASIC angepasst ist, werden im Allgemeinen sehr gut durchgeführt: Jedoch wird die ASIC im Allgemeinen bei Aufgaben, für die dieselbe nicht konfiguriert ist, eine schlechte Leistung erbringen, wenn überhaupt. Natürlich kann für eine spezielle Anwendung eine spezifische IC gebaut werden, aber dies ist keine erwünschte Lösung für Anwendungen, die für den Betrieb eines Computers nicht zentral sind oder zu der Zeit, in der der Computer gebaut wird, noch nicht bestimmt sind. Somit ist es für eine ASIC besonders vorteilhaft, rekonfigurierbar zu sein, so dass dieselbe für unterschiedliche Anwendungen wie gefordert optimiert werden kann. Die üblichste Form einer Architektur für derartige Vorrichtungen ist das feldprogrammierbare Gatearray (field programmable gate array = FPGA), eine feinkörnige Prozessorstruktur, die konfiguriert werden kann, um eine Struktur aufzuweisen, die für jede gegebene Anwendung geeignet ist. Derartige Strukturen können bei geeigneten Kontexten als unabhängige Prozessoren verwendet werden, sind aber auch zur Verwendung als Coprozessoren besonders zweckmäßig.
Derartige konfigurierbare Coprozessoren weisen das Potential auf, die Leistungsfähigkeit des primären Prozessors zu verbessern. Für spezielle Aufgaben kann ein Code, der durch den primären Prozessor ineffizient durchgeführt wird, extrahiert werden und in einem angepassten Coprozessor, der für diese Anwendung optimiert ist, effizienter ablaufen. Bei einer Weiterentwicklung von derartigen „anwendungsspezifischen" sekundären Prozessoren wird die Möglichkeit zur Verbesserung der Leistungsfähigkeit durch ein Extrahieren eines schwierigen Codes zu einem kundenspezifischen Coprozessor attraktiver. Ein besonders wichtiges Beispiel im allgemeinen Rechenwesen ist die Extraktion von Schleifenkörpern bei einer Bildhandhabung.
Um die erwünschten Effizienzgewinne zu erhalten, ist es notwendig, so effektiv wie möglich zu bestimmen, wie ein Code zwischen einem primären und einem sekundären Prozessor zu teilen ist, und den sekundären Prozessor zu einer optimalen Ausführung des Teils des Codes, der demselben zugeordnet ist, zu konfigurieren. Ein Ansatz besteht darin, den Code bei der Erzeugung desselben zweckmäßig für eine Abbildung zu Coprozessor-Strukturen zu kennzeichnen. In „A C++ compiler for FPGA custom execution units synthesis" von Christian Iseli und Eduardo Sanchez, IEEE Symposium an FPGAs for Custom Computing Machines, Napa, Kalifornien, April 1995, wird ein Ansatz angewendet, der eine Abbildung von C++ zu FPGAs bei VLIW-Strukturen (Strukturen mit sehr langem Befehlswort; VLIW = Very-Long Instruction Word) nach einem zweckmäßigen Etikettieren des Anfangscodes durch den Programmierer betrifft. Dieser Ansatz beruht darauf, dass der Anfangsprogrammierer eine gute Wahl des Codes trifft, der anfänglich zu extrahieren ist.
Ein alternativer Ansatz besteht darin, den Anfangscode zu bewerten, um zu bestimmen, welche Elemente am zweckmäßigsten sind, um zu dem sekundären Prozessor gerichtet zu werden. „Two-Level Hardware/Software Partitioning Using CoDe-X" von Reiner W. Hartenstein, Jürgen Becker und Rainer Kress in Int. IEEE Symposium an Engineering of Computer Based Systems (ECBS), Friedrichshafen, Deutschland, März 1996, erörtert ein Cozeichenwerkzeug, das eine Profilanalyseeinrichtung umfasst, um zu bewerten, welche Teile eines Anfangscodes für eine Zuteilung zu einem Coprozessor geeignet sind, und welche für den primären Prozessor reserviert sein sollten. Darauf folgt eine iterative Prozedur, die eine Kompilierung eines Teilsatzes eines C-Codes zu einer rekonfigurierbaren Coprozessorarchitektur ermöglicht, so dass der extrahierte Code zu dem Coprozessor abgebildet werden kann. Dieser Ansatz erweitert die Verwendung von sekundären Prozessoren, verwirklicht das Potential einer rekonfigurierbaren Logik aber nicht vollständig.
Vergleichbare Ansätze wurden von dem BRASS-Forschungsprojekt an der Universität Berkeley vorgeschlagen. Ein Ansatz, der in „Datapath-Oriented FPGA Mapping and Placement" von Tim Callahan und John Wawrzynek, einem Poster, das auf dem FCCM'97, Symposium an Field-Programmable Custom Computing Machines, 16.–18. April 1997, Napa Valley, Kalifornien, präsentiert wurde (momentan im Internet unter http://www.cs.berkeley.edu/projects/brass/tjc_fccm_poster_thumb.ps verfügbar) erörtert ist, verwendet Schablonenstrukturen, die für eine FPGA-Architektur repräsentativ sind, um bei der Abbildung von Quellcode auf FPGA-Strukturen zu helfen. Quellcodeabtastwerte werden als gerichtete azyklische Graphen bzw. DAGs (DAGs = directed acyclic graphs) wiedergegeben und dann auf Bäume reduziert. Diese und andere grundsätzliche Graphenkonzepte sind z. B. in „High Performance Compilers for Parallel Computing" von Michael Wolfe, Addison-Wesley, Redwood City, 1996, Seite 49 bis 56, ausgeführt, jedoch folgt hier eine kurze Definition eines DAG und eines Baumes.
Ein Graph umfasst einen Satz von Knoten und einen Satz von Kanten: Jede Kante ist durch ein Paar von Knoten definiert (und kann graphisch als eine Linie betrachtet werden, die diese Knoten verbindet). Ein Graph kann entweder gerichtet oder nicht gerichtet sein: Bei einem gerichteten Graphen weist jede Kante eine Richtung auf. Wenn es möglich ist, in einem Graphen einen Pfad von einem Knoten und zurück zu demselben zu definieren, dann ist der Graph zyklisch: wenn nicht, dann ist der Graph azyklisch. Ein DAG ist ein Graph, der sowohl gerichtet als auch azyklisch ist: Derselbe ist somit eine hierarchische Struktur. Ein Baum ist eine spezifische Art eines DAG. Ein Baum weist einen einzelnen Quellknoten auf, „Wurzel" (root) genannt, und es gibt einen eindeutigen Pfad von der Wurzel zu jedem anderen Knoten in dem Baum. Wenn in einem Baum eine Kante X → Y vorhanden ist, dann wird der Knoten X als die Mutter von Y bezeichnet, und Y wird als die Tochter von X bezeichnet. In einem Baum weist ein „Mutterknoten" einen oder mehrere „Tochterknoten" auf, aber ein Tochterknoten kann nur eine Mutter aufweisen, wohingegen bei einem allgemeinen DAG eine Tochter mehr als eine Mutter aufweisen kann. Baumknoten ohne Töchter werden als Blattknoten bezeichnet.
In der Arbeit von Tim Callahan und John Wawrzynek werden diese Bäume unter Verwendung eines „Baumabdeck"-Programms mit dem Namen Iburg mit der FPGA-Struktur abgeglichen. Iburg ist ein allgemein erhältliches Softwarewerkzeug und die Anwendung desselben ist in „A Retargetable C Compiler: Design and Implementation" von Christopher W. Fraser und David R. Hanson, Benjamin/Cummings Publishing Co., Inc., Redwood City, 1995, insbesondere auf den Seiten 373–407 beschrieben. Iburg nimmt die Quellcodebäume als Eingabe und partitioniert diese Eingabe in Brocken, die Befehlen auf dem Zielprozessor entsprechen. Diese Partition wird als eine Baumabdeckung bezeichnet. Dieser Ansatz ist in der Hauptsache durch benutzerdefinierte Muster bestimmt, die für einen Brocken zulässig sind, und ist relativ komplex: Derselbe umfasst eine Abgleichung eines Baumes mit Mustern von oben nach unten, ein Aufzeichnen aller möglichen Übereinstimmungen, gefolgt von einem Reduzierungsdurchlauf von oben nach unten, um zu bestimmen, welche Übereinstimmung der Muster die niedrigsten Kosten liefert. Dieser Ansatz erfordert eine erhebliche anfängliche Einschränkung in der Form des vordefinierten Satzes von zulässigen Mustern und verwirklicht die Möglichkeiten einer rekonfigurierbaren Architektur nicht vollständig.
In „Compiling to the gate Level for a Reconfigurable Co-Processor" beschreiben David Wo et al. ein Verfahren, durch das Quellcodefunktionen basierend auf Profilierkriterien wie der Codegröße derselben und darauf, ob sie Aufrufe zu anderen Funktionen beinhalten, manuell ausgewählt werden. Dies hat ein festgelegtes Programmieren des Coprozessors zur Folge.
Somit besteht ein Bedarf, Techniken und Ansätze zu entwickeln, um weiter die Recheneffizienz von Systemen zu verbessern, die einen primären und einen sekundären Prozessor betreffen und durch die im Hinblick auf ein Maximieren der Leistungseffizienz des Primärer-Prozessor- und Sekundärer-Prozessor-Systems bei einer Ausführung eines Eingangscodes eine optimale Wahl für eine Zuteilung von Code zu einem sekundären Prozessor getroffen werden kann, der dann so effizient wie möglich konfiguriert werden kann, um den extrahierten Code auszuführen.
Dementsprechend liefert die Erfindung ein Verfahren zum Kompilieren von Quellcode zu einem primären und einem sekundären Prozessor, das die folgenden Schritte aufweist: selektive Extraktion von Datenflüssen von dem Quellcode; Transformation der extrahierten Datenflüsse zu Bäumen; Abgleichen der Bäume gegeneinander, um minimale Editierkostenbeziehungen für die Transformation von einem Baum zu einem anderen zu bestimmen; Bestimmen einer Gruppe oder einer Mehrzahl von Gruppen von Datenflüssen auf der Basis der minimalen Editierkostenbeziehungen und Erzeugung eines allgemeinen Datenflusses für jede Gruppe, der in der Lage ist, jeden Datenfluss in dieser Gruppe zu unterstützen; Verwenden des allgemeinen Datenflusses oder der Datenflüsse, um die Hardwarekonfiguration des sekundären Prozessors zu bestimmen; und Einsetzen von Aufrufen an den sekundären Prozessor für diese Gruppe oder die Mehrzahl von Gruppen von Datenflüssen in den Quellcode, und Kompilieren des resultierenden Quellcodes zu dem primären Prozessor.
Dieser Ansatz ermöglicht eine optimale Auswahl von Quellcodedatenflüssen zur Zuteilung zu dem sekundären Prozessor ohne ein vorgefasstes Urteil über eine Geeignetheit (durch eine Abbildung auf vorbestimmte Schablonen z. B.), jedoch immer noch unter voller Berücksichtigung der Ansprüche und Anforderungen der Architektur eines sekundären Prozessors. Vorteilhafterweise werden die minimalen Editierkostenbeziehungen gemäß der Architektur des sekundären Prozessors bestimmt und stellen Hardwarekosten einer entsprechenden Rekonfiguration des sekundären Prozessors dar. Das Verfahren ist besonders effektiv, wenn die minimalen Editierkostenbeziehungen in einer Taxonomie minimaler Editierabschnitte für die Klassifizierung der Bäume ausgeführt sind.
Das Verfahren findet seine nützlichste Anwendung, wenn die Hardwarekonfiguration des sekundären Prozessors eine Rekonfiguration des sekundären Prozessors während der Ausführung des Quellcodes ermöglicht, da dies ermöglicht, dass eine Rekonfiguration des sekundären Prozessors während der Ausführung des Quellcodes erforderlich ist, um jeden Datenfluss in der Gruppe zu unterstützen, der durch einen allge meinen Datenfluss unterstützt wird. Der sekundäre Prozessor kann somit ein anwendungsspezifischer Befehlsprozessor sein und die Prozessorhardware kann ein feldprogrammierbares Gatearray oder ein feldprogrammierbares arithmetisches Array sein (wie das in der in dem Anhang A erörterten CHESS-Architektur gezeigte).
Vorteilhafterweise wird der allgemeine Datenfluss einer Gruppe durch eine ungefähre Abbildung von Datenflüssen in der Gruppe aufeinander berechnet, gefolgt von einer Mischoperation.
Ein vorteilhafter Ansatz zur Konstruktion eines generischen Datenflusses besteht darin, die Datenflüsse als gerichtete azyklische Graphen zu liefern und dieselben durch Entfernung jeglicher Verbindungen in den gerichteten azyklischen Graphen, die nicht in einem entscheidenden Pfad zwischen einem Blattknoten und der Wurzel eines gerichteten azyklischen Graphs vorliegen, auf Bäume zu reduzieren, wobei der entscheidende Pfad ein Pfad zwischen zwei Knoten ist, der durch die größte Anzahl von Zwischenknoten verläuft. Für den entscheidenden Pfad können alternative Kriterien übernommen werden, wenn dieselben für die Hardware des sekundären Prozessors zweckmäßiger sind (z. B., wenn ein anderes Kriterium gefunden werden kann, das empfindlicher gegenüber der Zeitgebung der Operationen in dem sekundären Prozessor ist).
Nach der Erzeugung eines allgemeinen Datenflusses kann ein weiterer vorteilhafter Schritt unternommen werden, bei dem der allgemeine Datenfluss mit weiteren Datenflüssen verglichen wird, die von dem Quellcode extrahiert werden wobei diejenigen der weiteren Datenflüsse, die mit dem allgemeinen Datenfluss ausreichend eng übereinstimmen, dem allgemeinen Datenfluss hinzugefügt werden. Dies ermöglicht, dass mehr von dem Code oder der ganze Code, der in dem Quellcode vorliegt, der für eine Zuteilung zu dem sekundären Prozessor geeignet ist, so zugeteilt wird.
In den oben angezeigten Ansätzen werden die entfernten Verbindungen gespeichert, nachdem die gerichteten azyklischen Gruppen auf Bäume reduziert wurden, und nach dem Mischen der Bäume der Gruppe in den allgemeinen Datenfluss wieder in den allgemeinen Datenfluss eingefügt.
Spezifische Ausführungsbeispiele der Erfindung sind unten beispielhaft unter Bezugnahme auf die dazugehörigen Zeichnungen beschrieben, von denen:
1 eine Universalcomputerarchitektur zeigt, auf die Ausführungsbeispiele der Erfindung geeignet angewendet werden können;
2 schematisch ein Verfahren zum Kompilieren von Quellcode zu einem primären und einem sekundären Prozessor gemäß einem Ausführungsbeispiel der Erfindung zeigt;
3 schematisch einen Schritt der Umwandlung eines DAG in einen Baum darstellt, der in einem Verfahrensschritt gemäß einem Ausführungsbeispiel der vorliegenden Erfindung verwendet wird;
4A den Schritt einer Einfügung und einer Löschung von Knoten darstellt, und 4b den Schritt einer Einsetzung von Knoten in einem Baumabgleichungsprozess, der in einem Verfahrensschritt gemäß einem Ausführungsbeispiel der Erfindung verwendet wird, darstellt;
5 eine Editierabschnittstaxonomie zeigt, die bei einem Beispiel gemäß einem Ausführungsbeispiel der Erfindung vorgesehen ist;
6 einen allgemeinen Datenfluss darstellt, der bei einem Beispiel gemäß einem Ausführungsbeispiel der Erfindung vorgesehen ist;
7 eine logische Schnittstelle für eine Zuteilung von Ressourcen eines sekundären Prozessors für einen allgemeinen Datenfluss gemäß einem Ausführungsbeispiel der Erfindung zeigt;
8 die Anwendung von DAGs auf Datenflüsse einschließlich Multiplexern, um bedingte Aussagen zu handhaben, zeigt; und
9a bis 9d eine Darstellung des Mischens von Kandidatdatenflössen, um einen generischen Datenfluss zu bilden, bei einem Beispiel gemäß einem Ausführungsbeispiel der Erfindung zeigen.
Die vorliegende Erfindung ist für eine Kompilierung von Quellcode zu einer Architektur angepasst, die einen primären und einen sekundären Prozessor aufweist. Ein Beispiel einer derartigen Architektur ist in 1 gezeigt. Der primäre Prozessor 1 ist ein herkömmlicher Universalprozessor wie ein Pentium II-Prozessor eines Personalcomputers. Ein sekundärer Prozessor 2 und (optional) 4 empfängt Aufrufe von dem primären Prozessor 1 und gibt Antworten zu demselben zurück. Jeder sekundäre Prozessor 2, 4 ist angepasst, um die Rechenleistung und die Effizienz der Architektur durch ein Handhaben von Teilen des Quellcodes, die von dem primären Prozessor 1 nicht gut gehandhabt werden, zu erhöhen. Der sekundäre Prozessor 4, hier optional vorliegend, ist ein zweckgebundener Coprozessor, der angepasst ist, um eine spezifische Funktion (wie JPEG = joint photographic experts group image format = Bildformat des Verbunds der Gruppe photographischer Experten; DSP = digital signal processor = Digitalsignalprozessor; oder Ähnliches) zu handhaben – die Struktur dieses Coprozessors 4 ist durch einen Hersteller bestimmt, um eine spezifische, häufig verwendete Funktion zu handhaben. Derartige Coprozessoren 4 stellen nicht den spezifischen Gegenstand der vorliegenden Anwendung dar. Im Gegensatz dazu ist der sekundäre Prozessor 2 nicht bereits für eine spezifische Funktion optimiert, sondern ist stattdessen konfigurierbar, um ein verbessertes Handhaben von Teilen des Quellcodes, die von dem primären Prozessor nicht gut gehandhabt werden, zu ermöglichen. Der sekundäre Prozessor 2 stellt vorteilhafterweise eine anwendungsspezifische Struktur dar: Derselbe kann ein herkömmliches FPGA wie der Xilinx 4013 oder irgendein anderes Mitglied der Xilinx 4000-Serie sein. Eine alternative Klasse einer rekonfigurierbaren Vorrichtung, als ein feldprogrammierbares arithmetisches Array bezeichnet, ist in dem Anhang A zu diesem Dokument beschrieben. Ein derartiger sekundärer Prozessor kann für eine hohe Recheneffizienz bei einer Handhabung von gewünschten Teilen des Quellcodes für eine Anwendung, die von der Architektur ausgeführt werden soll, konfiguriert sein.
In der Computerarchitektur werden ebenfalls ein Speicher 3, auf den der primäre Prozessor 1, und, für zweckmäßige Typen des sekundären Prozessors 2, der sekundäre Prozessor 2 zugreift, und ein Eingangs-/Ausgangskanal 5 verwendet. Der Eingangs-/Ausgangskanal 5 steht hier für alle weiteren Kanäle und weitere Hardware, die notwendig sind, um dem Benutzer zu ermöglichen, mit den Prozessoren (z. B. durch Programmieren) in Wechselwirkung zu stehen, und um den Prozessoren zu ermöglichen, mit allen anderen Teilen der Computervorrichtung 6 in Wechselwirkung zu stehen.
Die vorliegende Erfindung ist insbesondere für das optimierte Partitionieren von Quellcode zwischen dem primären Prozessor 1 und dem sekundären Prozessor 2 relevant, was eine optimale Konfiguration des sekundären Prozessors 2 ermöglicht, um die Handhabung der in dem Quellcode ausgeführten Anwendung durch die Architektur zu optimieren. Durch die Erfindung wird ein erheblicher Beitrag bei der Selektion und der Extraktion von Code zur Verwendung bei dem sekundären Prozessor geleistet.
Der gemäß einem Ausführungsbeispiel der Erfindung unternommene Ansatz ist in 2 dargelegt. Die Anfangseingabe in den Prozess besteht in einem Körper von Quellcode. Im Prinzip kann dies in einer jeglichen Sprache erfolgen: Das beschriebene Beispiel wurde in C-Code ausgeführt, aber der Fachmann auf dem Gebiet versteht ohne weiteres, wie die beschriebenen Techniken mit anderen Sprachen übernommen werden könnten. Zum Beispiel könnte der Quellcode ein Java-Bytecode sein: Wenn der Java-Bytecode so gehandhabt werden könnte, könnte die Architektur von 1 besonders gut angepasst sein, um einen Quellcode, der aus dem Internet empfangen wird, direkt zu empfangen und auszuführen.
Wie anhand von 2 zu sehen ist, besteht der erste Schritt bei dem Prozess in der Identifizierung eines zweckmäßigen Kandidatencodes, der durch den sekundären Prozessor 2 ausgeführt werden soll. Üblicherweise erfolgt dies durch ein Durchführen einer Datenflussanalyse des Quellcodes und ein Bauen von zweckmäßigen Darstellungen der Datenflüsse, die durch gewählte Linien von Code präsentiert werden (bei den meisten Prozessen erfolgt normalerweise zuvor ein manuelles Durchführen einer Profilanalyse des Codes). Dies stellt im Allgemeinen eine Standardtechnik bei einem Kompilieren dar, und eine Anwendung auf sekundäre Prozessoren wird z. B. in „An Adaptive Hardware Machine Architecture and Compiler for Dynamic Processor Reconfiguration", IEEE International Conference an Computer Design, 1991, Seiten 397–400, erörtert.
Der hier unternommene Ansatz besteht darin, gerichtete azyklische Graphen (DAGs) zu bauen, die die Datenflüsse des ausgewählten Codes darstellen. Ein vorteilhafter Weg, um dies zu tun, besteht in einer Verwendung einer Kompiliererinfrastruktur, die zweckmäßig zur Extraktion von Datenflüssen konfiguriert ist: Eine zweckmäßige Kompiliererinfrastruktur stellt SUIF (SUIF = Stanford University Intermediate Format) dar, das von der Universität Stanford entwickelt worden und im Internet auf der Webseite http://suif.stanford.edu/ und anderswo umfassend dokumentiert ist. SUIF ist für eine Kompiliererrecherche für Hochleistungssysteme entwickelt, wobei spezifisch Systeme eingeschlossen sind, die mehr als einen Prozessor aufweisen. Ein Standard-SUIF-Hilfsprogramm kann verwendet werden, um C-Code in SUIF umzuwandeln. Für einen Fachmann auf dem Gebiet ist es dann ein einfacher Prozess, die SUIF-Hilfsprogramme zu verwenden, um durch ein Durchführen einer Datenflussanalyse über Sektionen von SUIF und dann ein Aufzeichnen der Ergebnisse der Analyse DAGs zu bauen.
Die Extraktion von DAGs aus dem Quellcode ist ein herkömmlicher Schritt. Der nächste Schritt in dem Prozess ist die Umwandlung dieser DAGs in Bäume, wie anhand von 2 gesehen werden kann. Dieser Schritt ist ein erheblicher Faktor bei dem Treffen der optimalen Wahl des Codes zur Ausführung durch den sekundären Prozessor 2. DAGs sind komplexe Strukturen, die schwierig auf eine effektive Weise zu analysieren sind. Eine Reduzierung von DAGs auf Bäume ermöglicht es, dass Aspekte der Datenflüsse, die bei dem Bestimmen einer Abbildung derselben zu einer Hardware am wichtigsten sind, festgehalten werden, wobei gleichzeitig die Struktur ausreichend vereinfacht wird, um zu ermöglichen, dass analytische Ansätze erheblich effektiver erfolgen können.
Eine Erörterung der Reduzierung von DAGs auf Bäume wird in „High Performance Compilers for Parallel Computing" (wie oben zitiert), insbesondere auf den Seiten 56 bis 60 vorgenommen. Hierin wird eine andere Terminologie verwendet als die in der zitierten Quelle verwendete, aber Äquivalente und vergleichbare Bezeichnungen sind unten angegeben. Der Typ von Bäumen, die hier aufgebaut werden, ist direkt vergleichbar mit den „spanning trees" (aufspannende Bäume), auf die in der zitierten Quelle Bezug genommen wird.
Der bevorzugte Ansatz, der bei der Reduzierung von DAGs auf Bäume verfolgt wird, besteht in der Entfernung von Verbindungen, die nicht in einem entscheidenden Pfad zwischen einem Blattknoten und der Wurzel sind: Dies ist in 3 dargestellt. Der entscheidende Pfad zwischen Knoten A und Knoten B ist bei einem ersten Ausführungsbeispiel dieses Reduzierungsprozesses als derjenige definiert, der die größte Anzahl von Knoten berührt. Da ein DAG definitionsgemäß azyklisch ist, können bestimmte Pfade definiert sein, um dieses Kriterium zu erfüllen. Es ist wahrscheinlich, dass es zwischen Knoten unterschiedliche Pfade gibt, die die gleiche maximale Anzahl von Knoten aufweisen, aber es ist wahrscheinlich, dass diese Pfade alle für den Zweck eines Baumaufbaus zufrieden stellend sind. Während ein Treffen einer zufälligen Auswahl zwischen diesen Pfaden ein begründeter Ansatz ist, ist ein wesentlicher Punkt bei einer erfolgreichen Abbildung von Quellcode eine Zeitplanung (scheduling), die von Zeitgebungsinformationen abhängt: Dementsprechend ist es, wenn es notwendig ist, eine Wahl zwischen alternativen „entscheidenden Pfaden" zu treffen, erwünscht, denjenigen zu wählen, der die längste Zeit brauchen würde (hinsichtlich der Zeit, die gebraucht wird, um jede der Operationen auszuführen, die durch die Knoten in dem Pfad dargestellt sind). Wie weiter unten erörtert ist, können alternative Ansätze übernommen werden, die direkter auf Zeitgebungsinformationen basieren. Es ist ebenfalls erwünscht, bei dem Treffen derartiger Wahlen einen einheitlichen Ansatz zu übernehmen – sonst können aus im Wesentlichen ähnlichen DAGs morphologisch unterschiedliche Bäume resultieren.
Der Prozess, der bei einem Anwenden des ersten Ausführungsbeispiels des Kriteriums des entscheidenden Pfades unternommen wird, ist wie folgt. Zuerst wird für jeden Blattknoten jeder mögliche Pfad zu der Wurzel hin verfolgt: Da der DAG ein gerichteter Graph ist, ist dies einfach. Wie oben angegeben, wird für jeden Blattknoten der Pfad mit der größten Anzahl von Knoten gewählt, und wenn es sich herausstellt, dass zwei Pfade die gleiche Anzahl von Knoten aufweisen, erfolgt eine Auswahl. Dies ist der entscheidende Pfad für diesen Blattknoten. Alle anderen Pfade, die nicht ausgewählt sind, werden in einer Kante derselben, die am nahesten zu dem Anfangspunkt ist, abgeschnitten. Diese abgeschnittene Kante wird eine Nebenverbindung genannt (äquivalent zu der Bezeichnung Querverbindung („Cross-Link") in der Wolfe-Quelle). Der Baum umfasst die Anordnung von entscheidenden Pfaden und enthält keine Nebenverbindungen. Die Nebenverbindungen sind separat gespeichert. Die Nebenverbindungen sind erforderlich, wenn der extrahierte Quellcode zu dem sekundären Prozessor 2 abgebildet wird, werden aber bei einem Bestimmen, welcher Quellcode zu dem sekundären Prozessor abgebildet werden soll, nicht verwendet.
Es ist natürlich möglich, Bäume aus DAGs aufzubauen, ohne das Kriterium des entscheidenden Pfades zu verwenden. Eine Verwendung des entscheidenden Pfades liefert keine speziellen Vorteile. Insbesondere hat eine Entfernung als Nebenverbindungen der Querverbindungen, die nicht in dem entscheidenden Pfad sind, eine geringe Auswirkung auf die Zeitplanung, wohingegen, wenn ein anderer Ansatz übernommen würde, die entfernten Querverbindungen einen beträchtlichen Einfluss auf die Zeitgebung und somit die Zeitplanung haben können. Die Verwendung des Entscheidender-Pfad-Kriteriums ermöglicht einen Aufbau eines Baumes, der die entscheidenden Merkmale des DAG in dem Kontext einer Abbildung zu einer Hardware bestmöglich darstellt.
3 zeigt die Anwendung des Prozesses, der in dem vorhergehenden Abschnitt beschrieben ist. Ein Quellcodeextrakt 11 zeigt drei Linien, die für eine Ausführung durch den sekundären. Prozessor 2 erwogen werden. Ein DAG 12 zeigt diese drei Linien von Code, die als ein gerichteter azyklischer Graph dargestellt sind, mit einer Wurzel 126 (Variable e) und Blattknoten 121, 129 und 130 als den Eingängen.
Nun ist es eine einfache Angelegenheit, jeden Pfad von einem gegebenen Blattknoten zu der Wurzel zu bewerten und die Anzahl von Knoten in jedem Pfad zu vergleichen. Von dem Knoten 129 (ganzzahliger Wert 2) gibt es lediglich einen Pfad, durch Knoten 122, 123, 124 und 125. Dies ist dann der entscheidende Pfad von dem Blattknoten 129 zu dem Wurzelknoten 126, der in dem Baum vorliegen wird. Von dem Knoten 121 (in dem vorliegenden Fall das Ergebnis einer früheren Operation und als c bezeichnet) gibt es zwei Pfade. Der erste Pfad verläuft durch die Knoten 122, 123, 124 und 125, während der zweite Pfad durch Knoten 127, 128 und 125 verläuft. Der erste Pfad ist der entscheidende Pfad, da derselbe durch mehr Knoten verläuft: Der zweite Pfad kann somit abgeschnitten werden, wie unten erörtert. Der verbleibende Blattknoten 130 (Variable b) weist ebenfalls zwei Pfade zur Verfügung auf: Einer verläuft durch die Knoten 123, 124 und 125, während der andere durch die Knoten 127, 128 und 125 verläuft. Diese sind hinsichtlich der Anzahl von Knoten äquivalent, und somit kann jeder der Pfade als der entscheidende Pfad gewählt werden: Jedoch ist es aus den oben erörterten Gründen (Zeitgebung und morphologische Einheitlichkeit) erwünscht, unter einem zweckmäßigen Satz von weiteren Regeln zu operieren, um die beste Auswahl zu treffen. Derartige weitere Regeln können z. B. auf der Basis der relevanten Hardware bestimmt sein. Hier wird der zweite Pfad gewählt.
Der nächste zu unternehmende Schritt besteht darin, einen Baum 14 aus den entscheidenden Pfaden, die aus dem DAG 12 gewählt sind, zu bauen. Dies erfolgt durch ein Abschneiden aller nicht-entscheidenden Pfade in der Kante derselben, die am nahesten zu dem Anfangspunkt ist (d. h. der Kante, die am nahesten zu dem Anfangspunkt ist, der nicht auch Teil eines entscheidenden Pfades ist). Der erste nicht-entscheidende Pfad, der in Erwägung gezogen werden soll, ist der von dem Knoten 121 zu der Wurzel 126 durch die Knoten 127, 128 und 125. Dieser kann an der Kante zwischen den Knoten 121 und 127 abgeschnitten werden – in dem Baum wird dies durch eine Entfernung einer Kante 151 zwischen Knoten 141 (entsprechend zu 121) und 147 (entsprechend zu 127) dargestellt, die separat als eine Nebenverbindung gespeichert wird. Der andere nicht-entscheidende Pfad, der in Erwägung zu ziehen ist, ist der von dem Knoten 130 zu der Wurzel 126 durch die Knoten 123, 124 und 125: Dieser kann an der Kante zwischen den Knoten 130 und 123 abgeschnitten werden. Diese abgeschnittene Kante wird ebenfalls als eine Nebenverbindung gespeichert.
Es sollte beachtet werden, dass Bedingungsgleichungen auf genau die gleiche Weise wie einfache Gleichungen durch DAGs dargestellt werden und so auf Bäume reduziert werden können. Ein Beispiel ist in 8 gezeigt: Dies ist ein DAG, der den Datenfluss der Linien darstellt,
wenn (x < 2)
a = b
sonst
a = 1
und einen Multiplexerknoten 186 und einen „kleiner als"-Operationsknoten 186 zusätzlich zu den variablen und ganzzahligen Knoten 181, 182, 183 und 184 zeigt. Wie der Fachmann erkennt, ist es im Allgemeinen möglich, den hier gezeigten Ansatz für Quellcode zu verwenden, der als ein DAG dargestellt werden kann.
Die Baumstruktur, die übrig ist – in diesem Fall ein Baum 14 – ist eine Struktur, die bei einem Bestimmen, welcher Quellcode zu dem sekundären Prozessor 2 abgebildet werden sollte, viel einfacher zu verwenden ist, wie weiter unten erörtert ist. Die oben beschriebene Technik ist eine insbesondere zu einem Umwandeln von DAGs in Bäume geeignete, da dieselbe einfach zu implementieren ist, in der Anwendung allgemein ist, und durch eine Verwendung des entscheidenden Pfades die maximale „Tiefe" der Rechenmaschine, die synthetisiert werden soll (von der Annahme ausgehend, dass jeder Knoten ein einzelnes Rechenelement darstellt), aufgrund der Aufnahme von Pfaden mit der maximalen Anzahl von Knoten beibehält. Wie der Fachmann auf dem Gebiet erkennt, können alternative Ansätze zum Bestimmen, welche Kanten bei einem Umwandeln der DAGs in Bäume entfernt werden sollen, übernommen werden. Ein alternatives Ausführungsbeispiel des Reduzierungsprozesses eines DAG zu einem Baum besteht darin, jedem Knoten eine zeitgebungsbasierte Gewichtung zuzuweisen (z. B. auf der Länge der Zeit basierend, die erforderlich ist, um das entsprechende Rechenelement auszuführen) und dann die angesammelten Wichtungen jedes Pfades zu vergleichen und dabei einen Pfad auszuwählen, um den Baum entsprechend auf der Basis der größten angesammelten Wichtung z. B. zu definieren. Dieser Ansatz kann zweckmäßiger sein, wenn die Zeitgebungsparameter des sekundären Prozessors 2 einen kritischen praktischen Faktor darstellen und insbesondere, wenn die Zeitgebungsabhängigkeiten nicht hauptsächlich auf den gezählten Modus bezogen sind (was bei Strukturen der Fall sein kann, bei denen z. B. eine Multiplikation um ein Vielfaches zeitaufwändiger als eine Addition ist).
Der nächste Schritt bei dem Kompilierungsprozess nimmt Bäume als Eingaben und bestimmt die Auswahl von Quellcode für den sekundären Prozessor 2, wie anhand von 2 gesehen werden kann. Wie bei 2 ferner dargestellt ist, umfasst dieser Schritt des Prozesses eine Reihe von Teilschritten. Der erste derselben besteht in der Analyse und der Klassifizierung der Bäume, die aus Kandidatendatenflüssen resultieren. Dies ist ein wichtiger ursprünglicher Schritt, der unten detailliert erörtert ist.
Die Aufgabe bei dieser Stufe des Kompilierungsprozesses besteht darin, bestmöglich zu bestimmen, welche der Kandidatendatenflüsse von dem Quellcode die beste Wahl für eine Ausführung durch den sekundären Prozessor wären. Dies hängt in einem hohen Grad von der Beschaffenheit der Hardware in dem sekundären Prozessor ab. Eine extrem effiziente Abbildung von Quellcode zu dem sekundären Prozessor 2 kann dort erfolgen, wo Datenflüsse ausreichend ähnlich sind, so dass weitgehend für jeden Datenfluss die gleiche Hardwaredar stellung verwendet werden kann. Somit folgt, dass gute Wahlen von Kandidatendatenflüssen zur Abbildung zu dem sekundären Prozessor durch ein Finden von Sätzen von Datenflüssen erfolgen können, die einander ausreichend ähnlich sind. Dies ist, was durch ein Analysieren und ein Klassifizieren der Bäume erreicht wird, die aus den Kandidatendatenflüssen resultieren.
Eine leistungsfähige Technik zur Abgleichung von Bäumen, die bei diesem Ausführungsbeispiel der Erfindung verwendet wird, ist der Baumabgleichungsalgorithmus, der von Kaizhong Zhang von der Universität von West Ontario in Kanada entwickelt wurde. Dieser Algorithmus ist in Kaizhong Zhangs „A Constrained Edit Distance Between Unordered Labelled Trees", Algorithmica (1996) 15: 205–222, Springer Verlag, beschrieben und wird von der Universität von West Ontario als ein Programmierwerkzeug (Toolkit) bereitgestellt, wobei das Programmierwerkzeug zum Zeitpunkt des Schreibens über das Internet unter ftp://ftp.csd.uwo.ca/pub/kzhang/TREEtool.tar.gz erhältlich ist. Es ist zu erkennen, dass alternative Ansätze zu einer Abgleichung von Bäumen, um einen Grad einer Ähnlichkeit zwischen denselben zu bestimmen, dem Fachmann zur Verfügung stehen. Der Ansatz zur Baumabgleichung, der in diesem Ausführungsbeispiel der Erfindung verwendet wird, ist unten beschrieben.
Das Operationsprinzip von Zhangs Algorithmus ist das folgende: Zwei Bäume werden durch eine dynamische Programmiertechnik, die die Editieroperationen minimiert, die erforderlich sind, um einen Baum zu einem anderen zu transformieren, Knoten um Knoten verglichen. Diese Kosten einer Transformation werden hier als Editierkosten bezeichnet. Die Editierkosten von sukzessive größeren Zweigen (subtrees) werden querverglichen, wobei eine Aufzeichnung der gefundenen Minimumkosten gemacht wird. Die Rechenstruktur kann als die eines rekursiven dynamischen Programms charakterisiert sein, das ein arbeitendes dynamisches Programmierraster verwendet, um Komponentenzweigabschnitte zu berechnen, und das Ergebnis auf dem Hauptraster aufzeichnet.
Die zur Verfügung stehenden Editieroperationen sind Einfügung, Löschung und Ersetzung. Diese sind in 4a und 4b gezeigt. 4a zeigt zwei Bäume: einen Baum 151 mit fünf Knoten und einen Baum 152 mit sechs Knoten. Die Struktur der Bäume kann durch eine Hinzufügung eines Knotens zwischen Knoten 3 und 5 des Baumes 151 identisch gemacht werden: Dieser neue Knoten liefert die Struktur des Baumes 152. Folglich wird eine Transformation des Baumes 151 zu dem Baum 152 durch eine Einfügung dieses Knotens erreicht, und eine Transformation des Baums 152 zu dem Baum 151 durch eine Löschung desselben (bei der in dem Anhang A beschriebenen CHESS-Architektur ist „Löschung" bei Hardware durch „Bypass" einer Einheit des Arrays dargestellt: Dies ist ein Beispiel von architektonisch entworfenen Kosten – in diesem Fall extrem niedriger Kosten). Für 4b weisen die zwei Bäume 151 und 152 die gleiche Struktur auf, aber die zwei Knoten 4 stellen einen anderen Typ von Operation bei jedem Baum dar: Es ist somit notwendig, den Knoten 4 bei einem Transformieren eines Baumes zu dem anderen zu ersetzen. Jeder Knoten benötigt somit ein „Etikett": eine Kennung, die an dem Knoten angebracht ist und unter den verschiedenartigen möglichen Knotentypen den Knotentyp identifiziert.
Wie vorhin angegeben, weist jede dieser Editieroperationen Kosten auf. Dies ermöglicht, dass alternative Wahlen getroffen werden: Zum Beispiel kann bei einigen Architekturen das gleiche Ergebnis entweder durch eine Einfügung und eine Löschung oder durch eine Ersetzung erreicht werden: die Kosten dieser unterschiedlichen Alternativen können verglichen werden.
Das Ergebnis des Vergleichs von zwei Bäumen durch diesen Algorithmus ist die Erzeugung einer Liste von Paaren von Knoten (t1, t2), wobei t1 zu dem ersten Baum und t2 zu dem zweiten Baum gehört. Jede Paarung bildet eine Identifizie rung von ähnlichen Knoten bei den zwei Bäumen, wobei die Abbildung von t1 und t2 aufeinander vorgeschlagen wird. Die Liste von Paaren definiert effektiv das Skelett eines Baumes, das jeden der verglichenen Bäume enthalten kann: Um den ersten Baum zu dem zweiten Baum zu transformieren, muss bei diesem Skelett jeder Knoten t1 durch den entsprechenden Knoten t2 ersetzt werden. Knoten, die in der Abbildung nicht auftreten, müssen, in Abhängigkeit davon, zu welchem Baum dieselben gehören, entweder eingefügt oder gelöscht werden, wie weiter unten erörtert ist. Für diese Liste von Paaren ist ein Editierabschnitt definiert: Dies ist das Minimum an Editierkosten, die über die Paare angesammelt und notwendig sind, um einen Baum zu dem anderen zu transformieren. Der Algorithmus ist entwickelt, um einen Editierabschnitt zwischen zwei Bäumen zu bestimmen, zusammen mit dem Satz von Transformationen, der diesen Editierabschnitt erreicht: Alternative Transformationen sind möglich, weisen aber höhere dazugehörige angesammelte Editierkosten auf.
Der Wert eines Berechnens eines Editierabschnitts basierend auf den Editierkosten besteht darin, dass die Editierkosten gewählt werden können, um die „Hardwarekosten" bei einem Rekonfigurieren des sekundären Prozessors von der Konfiguration, die einen Baum darstellt, zu einer Konfiguration, die den anderen Baum bei einer Abbildung darstellt, darzustellen. Diese „Hardwarekosten" sind typischerweise ein Maß für die Quantität der Ressourcen des sekundären Prozessors, die aufgenommen werden, um die zweite Konfiguration zu erreichen, das Vorhandensein der ersten vorausgesetzt – dies kann z. B. hinsichtlich des zusätzlichen Bereichs einer verwendeten Vorrichtung betrachtet werden. Diese Kosten sind durch die Beschaffenheit der Hardware des zweiten Prozessors bestimmt, da für unterschiedliche Typen von Hardware die physische Verwirklichung von Einfügungs-, Löschungs- und Ersetzungsoperationen unterschiedlich ist. Für das rekonfigurierbare CHESS-Array, das in dem Anhang A erörtert ist, beinhaltet eine „Umgehungs"-Operation („By pass"-Operation) minimale Kosten, weist eine Ersetzung zwischen Adds und Subs (Additions- und Subtraktionsoperationen) geringe Kosten auf, während eine Ersetzung zwischen Muls und Divs (Multiplikations- und Divisionsoperationen) teuer ist.
Wie oben angegeben, kann zwischen zwei Bäumen ein Editierabschnitt aufgebaut werden. Jedoch kann ein weiterer Schritt unternommen werden: Unter Verwendung von Zhangs Algorithmus oder einem vergleichbaren Ansatz kann eine Taxonomie aufgebaut werden, um die Editierabschnitte zwischen jedem einen aus einem Satz von Bäumen zu zeigen. Diese Taxonomie kann ohne weiteres in der Form eines Baumes geliefert sein, dessen Beispiel in 5 gezeigt ist. Jeder Blattknoten 161 des Baumes stellt einen Kandidatenbaum dar, der aus einem DAG extrahiert ist, und jeder Zwischenknoten 162 stellt Editierkosten dar. Der Baum liefert einen eindeutigen Pfad zwischen jedem Paar von Blattknoten. Der Editierabschnitt zwischen den zwei Blattknoten eines Paares wird durch eine Summierung von Kosten gefunden, die an jedem Zwischenknoten auf diesem Pfad geliefert sind. Zum Beispiel ist der Editierabschnitt zwischen irgendeinem Paar der Blattknoten, die Baum Nr. 4, Baum Nr. 5 oder Baum Nr. 6 darstellen, 6. Jedoch ist der Editierabschnitt zwischen Baum Nr. 1 und Baum Nr. 4 496: die Summierung von Zwischenknoten mit Werten von 12, 221, 107, 50 und 6.
Diese Taxonomie gibt die Anzahl von Editieroperationen an, die erforderlich sind, um zwischen Bäumen zu übersetzen. Eine derartige Taxonomie ist ein wertvolles Werkzeug, da dieselbe heuristisch als ein Maß für den Grad an Variation zwischen Kandidatenbäumen verwendet werden kann. Die Erzeugung einer Taxonomie macht es somit einfach, zu bestimmen, welche Bäume ausreichend ähnlich sind, um zusammen konsolidiert zu werden (wie weiter unten erörtert ist), und welche für diesen Zweck zu unterschiedlich sind. Dies kann durch ein Auferlegen einer Editierabschnittschwelle erfolgen.
Eine Gruppe von Bäumen kann zur Konsolidierung ausgewählt werden, wenn der Editierabschnitt zwischen jedem und jedem möglichen Paar von Bäumen in der Gruppe geringer als die Editierabschnittschwelle ist. Der Wert der Editierabschnittschwelle ist zufällig und kann durch den Fachmann auf dem Gebiet in dem Kontext von spezifischen primären und sekundären Prozessoren gewählt werden, um die Leistungsfähigkeit des Systems zu optimieren.
Der Vorteil eines Konsolidierens einer Gruppe von Bäumen besteht darin, dass für die ganze Gruppe eine gemeinsame Hardwarekonfiguration verwendet werden kann, die Funktion eines jeden Baumes unterstützt. Dies ist insbesondere für Architekturen wie z. B. CHESS zweckmäßig, bei denen Partialrekonfigurationsmechanismen mit geringer Latenzzeit auf dem sekundären Prozessor verfügbar sind. Eine Rekonfiguration ist erforderlich, um die Konfiguration von derjenigen, die die Funktion eines Baumes unterstützen soll, zu derjenigen, die die Funktion eines anderen Baumes unterstützen soll, zu ändern: Jedoch ist bereits bekannt, dass der Grad der erforderlichen Konfiguration innerhalb annehmbarer Grenzen liegt, da der Editierabschnitt zwischen diesen Bäumen nie größer als die Editierkostenschwelle sein wird. Die Gruppe von Bäumen wird zusammen durch einen Aufbau eines „Superbaumes", der eine Darstellung eines jeden Komponentenbaums beinhaltet, konsolidiert. Nachdem derselbe aufgebaut worden ist, kann der Superbaum in eine Darstellung jeden der relevanten DAGs umgewandelt werden, die aus dem Quellcode durch eine Wiedereinfügung der vorhergehend entfernten Nebenverbindungen extrahiert sind. Aus dem vollständigen Superbaum kann dann die Hardwarekonfiguration bestimmt werden. Der Aufbau des Superbaumes ist unten detailliert erörtert.
6 stellt den Schritt eines Aufbaus eines Superbaumes aus einer Gruppe von Bäumen dar, die unter die spezifizierte Editierkostenschwelle fallen: Eine derartige Gruppe von Bäumen wird hier als eine Klasse bezeichnet. Die Bäume 171, 172 und 173 können zusammen in einen Superbaum 170 abgebildet werden. Die Rekonfiguration, die erforderlich ist, um die Hardwarekonfiguration von derjenigen, die z. B. den Baum 171 unterstützen soll, zu derjenigen von dem Baum 172 zu ändern, ist ausreichend eingeschränkt, um in der Praxis umsetzbar zu sein, weil der Editierabschnitt zwischen den zwei Bäumen unter der Editierkostenschwelle liegt.
Ein beispielhafter Superbaum-Anordnungsalgorithmus, Mischen (merge), ist in dem Anhang B als Code C geliefert. Die Funktion des Algorithmus ist unten unter Bezugnahme auf 9 beschrieben. Der Algorithmus beinhaltet die folgenden Elemente:
merge:
Der Baum in der Klasse mit der größten Anzahl von Knoten wird gewählt, um der Anfangsmischbaum zu sein – falls es Bäume mit einer gleichen Anzahl von Knoten gibt, kann eine zufällige Auswahl erfolgen. Die verbleibenden Bäume werden als Quellbäume bezeichnet.
Auf jeden Quellbaum werden dann die folgenden Operationen angewendet:
Aus der Abbildung zwischen dem Quellbaum und dem Mischbaum, die berechnet worden ist (bei diesem Ausführungsbeispiel aus Zhangs Algorithmus und aus Editierkosten, die von der Architektur des sekundären Prozessors bestimmt sind) wird der Superbaum wie folgt aufgebaut:

1. Zuerst werden abgebildete Knoten, die der Wurzel am nächsten sind, berücksichtigt;
2. Die Quellbaumoperation (Quelloperation) wird mit der entsprechenden abgebildeten Mischbaumoperation (Mischoperation) verkettet;
3. Für jede Tochteroperation der Quelloperation
a. Wenn die Tochter abgebildet ist, unter Bezugnahme auf die Quelltochter zu Schritt 2 zurücksetzen
b. Wenn die Tochter nicht abgebildet ist, dann berücksichtigen, ob es eine Abbildung in dem Zweig gibt, dessen Wurzel die Tochter ist (Quellzweig).
i. Wenn es keine weitere Abbildung gibt, zum Mischen in den Mischbaum unter dem entsprechenden Mischbaumknoten einfach den Quellzweig übernehmen.
ii. Wenn es in dem Quellzweig eine weitere Abbildung gibt, den Zweig wie folgt verbinden:
a. Wenn die Mischoperation dieser untergeordneten Abbildung außerhalb des vorhergehend abgebildeten Zweigs fällt, die abgebildete Quelloperation aus dem Quellbaum entfernen. Bei dieser Stufe liegt eine Rekursion vor – wo abgebildete Töchter bereits behandelt worden sind, ist alles, was getan werden muss, zu entfernen, was andernfalls eine Baumquerverbindung wäre.
b. Dies ist in 9 gezeigt. Wenn die Mischoperation dieser untergeordneten Abbildung in den vorhergehend abgebildeten Zweig fällt, den Mischbaum hinaufsteigen, bis der kleinste gemeinsame Ahne (ancestor) für alle enthaltenen untergeordneten Abbildungen gefunden ist. Der kleinste gemeinsame Ahne ist der erste Knoten, der alle der Quellabbildungen enthält. Das nicht abgebildete Quellsegment wird dann durch ein Verbinden der Quelloperation des nicht abgebildeten Quellzweigs als eine Tochter der Mutter des kleinsten gemeinsamen Ahnen und durch ein Verbinden des gemeinsamen Ahnen als die Tochter der nicht abgebildeten Quelloperation unmittelbar über der nahesten abgebildeten Quelloperation in dem momentanen Zweig (wobei die „naheste abgebildete Quelloperation" das untere Ende eines nicht abgebildeten Segments des Zweigs begrenzt und ein abgebildeter Knoten ist, der in den Zweig der momentanen Abbildung fällt – die Mutter des Quellknotens, die nicht abgebildet ist, übernimmt den kleinsten gemeinsamen Ahnen des Mischbaumes als Tochter und umgekehrt) in den Mischbaum abgebildet.

Das Paar von gemischten Bäumen wird zu einem einzigen Baum normiert, der den neuen Mischbaum bildet.
Der Vorgang setzt sich fort, bis alle der Quellbäume in der Klasse in dem Mischbaum enthalten sind, der nun ein Superbaum ist.
Dieser Prozess ist in 9 angezeigt. 9a zeigt zwei Datenflussbäume, einen Mischbaum 201 und einen Quellbaum 202. Zwischen den Knoten erfolgen drei Abbildungen, die durch den Vergleichsalgorithmus erfolgen – die verbleibenden Knoten müssen zweckmäßig eingefügt werden. Wie im Abschnitt 1 oben angezeigt, besteht der erste Schritt darin, die abgebildeten Operationen zu berücksichtigen, die am nächsten zu der Wurzel sind – in diesem Falle, an der Wurzel. Diese Operationen A sind verkettet.
Danach werden die Tochterknoten von A in dem Quellbaum berücksichtigt. Knoten B weist keine Abbildung auf und ist kein Ahne jeglicher Abbildungen – derselbe wird somit als eine Tochter von A:A gemischt (Siehe 9b). Der andere Tochterknoten von A, C, weist jedoch Nachfolgerabbildungen auf (D und F, die zu D und E in dem Mischbaum abbilden). Beide relevanten Mischoperationen fallen in den vorhergehend abgebildeten Zweig (da dieselben beide Nachfolger von A sind). Somit ist es notwendig, den oben in dem Abschnitt 3(b)(ii)(b) ausgeführten Verlauf zu befolgen. Der kleinste gemeinsame Ahne, der beide abgebildeten Mischoperationen D und E enthält, ist X. C des Quellbaumes ist somit in den Mischbaum als Kind von A:A verbunden (die Mutter von X) und Mutter von X. Diese Anordnung ist in 9b gezeigt – das Mischen wird durch eine Verkettung oder ein Mischen der verbleibenden Knoten des Quellbaumes vollendet, wobei alle dieser Schritte einfach sind.
Der resultierende Superbaum 203 ist in 9c gezeigt. Dieser Superbaum 203 handelt als Mischbaum zum Einmischen eines weiteren Kandidatenquellbaumes 204, wie in 9d gezeigt. In diesem Falle ist jeder Knoten des Quellbaumes in einen Superbaumknoten abgebildet – das Mischen ist somit gänzlich einfach und besteht lediglich aus einer Verkettung (d. h. einer Ersetzung). Dieser Prozess setzt sich fort, bis alle der Kandidatenbäume in einen Superbaum vermischt sind.
Bei dieser Stufe ist es möglich, einen Schritt zu unternehmen, der es ermöglicht, dass mehr von dem Quellcode zu dem sekundären Prozessor zugeteilt wird. Der Quellcode enthält DAGs, die anders sind als diejenigen, die für eine Aufnahme des Superbaumes ausgewählt worden sind: DAGs z. B., die nicht berücksichtigt worden sind, weil dieselben nicht an einem der rechenmäßig intensivsten „Notspots" des Codes liegen. Jedoch kann der Code dieser DAGs auch schneller ablaufen, wenn derselbe auf einem zweckmäßig angepassten sekundären Prozessor und nicht auf dem primären Prozessor ausgeführt wird. Es kann somit vorteilhaft sein, derartige verbleibende DAGs durch einen Rückabbildungsprozess mit dem Superbaum zu vergleichen. Zu diesem Zweck können Prozesse verwendet werden, die aus herkömmlichen Rückabbildungstechniken wie z. B. Iburg abgeleitet sind. Der vorteilhafteste Ansatz jedoch könnte darin bestehen, zu einer Verwendung von Zhangs Algorithmus zurückzukehren und weitere Kandidatenbäume in dem Quellcode gegen den Superbaum abzugleichen, dieses Mal aber mit einer niedrigeren Editierkostenschwelle. Wenn die Bäume, die aus derartigen DAGs erhalten werden, entweder direkt auf den Superbaum abgebildet werden können oder wenn die Editierkosten für eine derartige Abbildung unter ein gewisses Mindestniveau fallen, dann kann der Code dieser DAGs auch dem sekundären Prozessor zugewiesen werden und der Superbaum modifiziert werden, falls dies notwendig ist. Steuerinformationen bezogen auf derartige Datenflüsse, die durch diesen Rückabbildungsprozess hinzugefügt werden, müssen ebenfalls gespeichert werden.
Es ist dann einfach, aus diesem Superbaum die Nebenverbindungen einzufügen, die aus den DAGs bei der Umwandlung derselben in Bäume entfernt wurden (hierin eingeschlossen jegliche DAGs, die aus dem Rückabbildungsprozess hinzugefügt wurden, falls angewendet). Die resultierende Struktur ist ein Klassendatenfluss, der alle Informationen, die in den DAGs der Klasse vorliegen, darstellt: Steuerinformationen für den Superbaum (z. B., um eine Rekonfiguration, die auftreten soll, zu bestimmen) müssen ebenfalls vorliegen. Dieser Klassendatenfluss kann zu dem Zweck eines Bestimmens der Hardwarekonfiguration des sekundären Prozessors verwendet werden und kann ebenfalls verwendet werden, um eine Struktur zum Ermöglichen eines Zurückzusammensetzens von zweckmäßigen Aufrufen an den sekundären Prozessor in den Quellcode liefern: Diese Schritte sind weiter unten beschrieben.
Ein Zusammensetzen von Aufrufen an den sekundären Prozessor zurück in den Quellcode erfordert in der Tat lediglich den Superbaum und nicht den Klassendatenfluss, da der Superbaum die Peripherie des Datenflusses vorschreibt. Die Handlungen, die in Bezug auf einen jeglichen ersetzten Datenfluss in dem Quellcode erforderlich sind, sind Ersetzung von Eingaben des Datenflusses (Blätter des Baumes, der aus dem Datenfluss reduziert ist) durch Ladegrundelemente, und der Ausgabe des Datenflusses (Wurzel des relevanten Baumes) durch einen Lesevorgang. Die Blätter und Wurzeln des relevanten Baumes sind in dem Superbaum enthalten, so dass lediglich der Superbaum zu diesem Zweck erforderlich ist. Der ganze verbleibende Code, der in dem Datenfluss subsumiert ist, kann einfach entfernt werden, da derselbe durch die Konfiguration des sekundären Prozessors ersetzt wird.
7 zeigt eine logische Schnittstelle zum Erreichen der erforderlichen Substitutionen in den Quellcode. Ein Eingabebaum, als Eingabebaum Nr. 3 etikettiert, ist zusammen mit einem Superbaum, als PFU-Baum etikettiert, gezeigt. Jeder Knoten in dem Eingabebaum Nr. 3 weist eine eindeutige eigene Operationsidentifkation auf, die aus der Darstellung der inneren Form des Kompilierers erhalten ist. Für den Superbaum (PFU-Baum) sind Register oder andere I/O-Ressourcen (I/O = Input/Output = Eingang/Ausgang) zu den Blättern und der Wurzel zugeteilt. Die implizite Abbildung zwischen dem Eingabebaum Nr. 3 und dem PFU-Baum liefert somit eine Entsprechung zwischen den Operationsidentifikationen der Eingabebaumknoten und den Eingangs/Ausgangressourcen, die für den PFU-Baum in der Form einer Spezifikation zugeteilt sind. Die Anwendung dieser Spezifikation bei dem Schritt, der in 7 als „Mischen" angegeben ist, ermöglicht eine Entfernung des Codes, der von dem PFU subsumiert ist, und die Substitution der notwendigen Eingangs-/Ausgangsgrundelemente in dem Code.
Es ist möglich, aus dem Klassendatenfluss den sekundären Prozessor zu konfigurieren. Dieser Schritt kann gemäß bekannten Ansätzen durchgeführt werden, durch eine Reduzierung des Klassendatenflusses auf eine Netzliste (mit Einfügungs-, Lösch- und Substituieroperationen und einschließlich jeglicher dynamischer Rekonfigurationsanweisungen in angemessener Form) und dann eine Abbildung der Netzliste zu der spezifischen Hardware des sekundären Prozessors, wobei Anforderungen der Rekonfiguration zwischen Komponentendatenflüssen berücksichtigt werden. Für herkömmliche FPGA-Architekturen können diese Schritte in der Hauptsache durch eine Verwendung von zweckmäßigen bekannten Werkzeugen durchgeführt werden. Zum Beispiel können im Falle eines Standard-Xilinx-FPGA wie des XC4013 zweckmäßige eigene Xilinx-Werkzeuge verwendet werden. Zuerst kann die Netzliste in dem Xilinx-Netzlistenformat (XNF) wiedergegeben werden. Darauf kann anschließend ein Partitionieren zu konfigurierbaren Logikblöcken und Eingangs/Ausgangsblöcken durch das Xilinx-Partition-Place-and-Route-Programm (PPR) folgen, wobei das Resultierende durch das Xilinx-MakeBits-Programm zu einem Konfigurationsbitstrom umgewandelt wird. Dieser Ansatz ist zusammen mit weiteren Erörterungen einer Lieferung von vorbestimmten Rekonfigurationslösungen in „Run-Time Programming Method for Reconfigurable Computer" von Steven Casselman, momentan im Internet unter http://www.reconfig.com/specrept/101596/session1/library/cassel.htm erhältlich, einem Beitrag zu der Internetkonferenz zu rekonfigurierbarem Rechnen, betrieben durch SB Associates, Inc. of 504 Nino Avenue, Los Gatos, Ca 95032, USA, erörtert. In der Hauptsache ähnliche Vorgänge können unter Verwendung von Werkzeugen, die für den betreffenden Prozessor zweckmäßig sind, für alternative Typen eines konfigurierbaren und rekonfigurierbaren Prozessors, wie z. B. die CHESS-Vorrichtung, die in dem Anhang A beschrieben ist, befolgt werden.
Ist der Quellcode einmal in einer ausführbaren Form mit zweckmäßigen Aufrufen an den sekundären Prozessor erzeugt und ist die Konfiguration des sekundären Prozessors einmal bestimmt, kann der Quellcode geladen und ausgeführt werden.
Der Quellcode wird in dem primären Prozessor mit Aufrufen an Coprozessoren und an den sekundären Prozessor ausgeführt: Da der sekundäre Prozessor spezifisch angepasst ist, um die Datenflüsse, die zu demselben extrahiert sind, auszuführen, ist die Ausführungsgeschwindigkeit des Codes erheblich erhöht. Zum Beispiel wurde bei einer Anwendung des Verfahrens dieses Ausführungsbeispiels der Erfindung auf den iDCT-Algorithmus aus der JPEG-Werkzeugsammlung eine Verbesserung von 25 festgestellt, obwohl dies aufgrund von Eingangs-/Ausgangseinschränkungen in der Tat ein schlechtes Problem für eine Abbildung zu einem derartigen sekundären Prozessor darstellt.
Die hierin beschriebenen Verfahren sind somit besonders effektiv, um eine optimale Verwendung des sekundären Prozessors bei einer Architektur zu ermöglichen, die einen primären Prozessor und einen rekonfigurierbaren sekundären Prozessor aufweist.
ANHANG A
CHESS-Array
Das CHESS-Array ist eine Art eines feldprogrammierbaren Arrays, bei dem die programmierbaren Elemente keine Gatter wie bei einem FPGA sind, sondern 4-Bit-Rechenwerke (4-Bit-ALUs; ALUs = arithmetic logic units). Die Arraykonfiguration ist detailliert in der Europäischen Patentanmeldung Nr. 97300563.0 beschrieben, und die ALU-Struktur und die Bereitstellung von Anweisungen an ALUs sind in einer anhängigen Anmeldung mit dem Titel „Reconfigurable Processor Devices" erörtert, die an dem gleichen Datum wie die vorliegende Anmeldung eingereicht wurde.
Das CHESS-Array umfasst einen Schachbrettentwurf mit abwechselndem Quadraten, die einen ALU bzw. eine Schaltkastenstruktur aufweisen. Der Konfigurationsspeicher für einen benachbarten Schaltkasten ist in dem ALU gehalten. Einzelne ALUs können bei einer Verarbeitungspipeline verwendet werden, und bei einer bevorzugten Implementierung erfolgt eine Bereitstellung, um eine dynamische Bereitstellung von Anweisungen aus einem ALU zu ermöglichen, um die Funktion eines nachfolgenden ALU zu bestimmen. ALUs sind 4-Bit, mit vier identischen Bitelementen (Bit-Slices), mit 4-Bit-Eingängen A und B, die direkt aus einem extensiven 4-Bit-Verbindungsverdrahtungsnetzwerk entnommen sind, und einem 4-Bit-Ausgang U, der durch ein optional verriegelbares Ausgangsregister zu dem Verdrahtungsnetzwerk geliefert ist: Ein 1-Bit-Übertrageingang und -ausgang sind ebenfalls geliefert und weisen eine eigene Verbindung derselben auf.
Dynamische Anweisungen sind aus dem Ausgang U eines ALU zu einem 4-Bit-Anweisungseingang I eines anderen ALU lieferbar. Der Übertragausgang C_out eines ALU kann mit dem Effekt eines Veränderns der Anweisung dieses ALU auch als C_in eines anderen ALU verwendet werden.
Das CHESS-ALU ist angepasst, um ein Multiplexern zwischen den A- und B-Eingängen zu unterstützen, und unterstützt ebenfalls ein Multiplexern zwischen verwandten Anweisungen (z. B. OR/NOR (ODER/NICHT-ODER), AND/NAND (UND/NICHT-UND)).
Eine Rekonfiguration zwischen derartigen Anweisungen kann durch eine zweckmäßige Verwendung der Übertrageingänge und -ausgänge ohne einen Verbrauch von Silizium erreicht werden. Komplexere Rekonfigurationen (z. B. AND/XOR (UND/exclusives ODER), Add/Sub) können durch ein Verwenden von zwei ALUS erreicht werden, der erste, um zwischen den zwei alternativen Anweisungen zu multiplexen, und der zweite, um die gewählte Anweisung auf den Operanden auszuführen. Eine Multiplikation nimmt mehr als ein einzelnes ALU ein, wodurch bewirkt wird, dass eine Rekonfiguration eine komplexere Multiplikationsoperation umfasst. Es ist einfach, die Multiplexerkapazität eines CHESS-ALU zu verwenden, um eine Operation zu „umgehen" („bypass"), wobei eine zweckmäßige Steuerung entweder eine Durchführung der Operation oder eine Ausbreitung einer gegebenen Eingabe zur Folge hat.

Ein Beispielsatz von Funktionen, die aus den Anweisungseingaben erhältlich sind, ist in Tabelle A1 unten angegeben: Ein weiter Bereich von Möglichkeiten ist mit einer zweckmäßigen Logik in Verbindung mit den Anweisungseingaben an den ALU verfügbar. Diese Funktionen sind in Tabelle A2 beschrieben.

I₃	I₂	I₁	I₀	ÜbertragIn-Wert	(CarryIn-Wert)
I₃	I₂	I₁	I₀	0	1
0	0	0	0	XOR	NXOR (NICHT-Exclusives-ODER)
0	0	0	1	A AND B	A OR B
0	0	1	0	A AND B	A OR B
0	0	1	1	ADD
0	1	0	0	A OR B	A AND B
0	1	0	1	B	A
0	1	1	0	A	B
0	1	1	1	MATCH0
1	0	0	0	A NAND B	A NOR B
1	0	0	1	NOT A	NOT B
1	0	1	0	NOT B	NOT A
1	0	1	1	MATCH1
1	1	0	0
1	1	0	1
1	1	1	0	A gleicht B
1	1	1	1	SUB

Tabelle A1: Anweisungsbits und entsprechende Funktionen

Name	U-Funktion	C_out-Funktion
ADD	A plus B	arithmetischer Übertrag
SUBA	A minus B	arithmetischer Übertrag
A AND B	U_i = A_i AND B_i	C_out = C_in
A OR B	U_i = A_i OR B_i	C_out = C_in
A NOR B	U_i = NOT (A_i OR B_i)	C_out = C_in
A XOR B	U_i = A_i XOR B_i	C_out = C_in
A NXOR B	U_i = NOT (A_i XOR B_i)	C_out = C_in
A AND B	U_i = A_i AND (NOT B_i)	C_out = C_in
B AND A	U_i = (NOT A_i) AND B_i	C_out = C_in
A OR B	U_i = (NOT A_i) OR B_i	C_out = C_in
B OR A	U_i = A_i OR ( NOT B_i)	C_out = C_in
A	U_i = A_i	C_out = C_in
B	U_i = B_i	C_out = C_in
NOT A	U_i = NOT A_i	C_out = C_in
NOT B	U_i = NOT B_i	C_out = C_in
A gleicht B	nicht anwendbar	wenn A == B dann 0, sonst 1
MATCH1	nicht anwendbar	Bitweise AND von A und B, gefolgt von OR über Breite des Wortes
Abgleichen 0	nicht anwendbar	Bitweise OR von A AND B, gefolgt von einem AND über die Breite des Wortes

Tabelle A2: Ausgaben für Anweisungen

Eine 2s-Komplementärarithmetik wird verwendet, und der arithmetische Übertrag ist geliefert, um mit dieser Arithmetik im Einklang zu sein. Die MATCH-Funktionen werden so genannt, weil für MATCH1 der Wert von 1 lediglich zurückgegeben wird, wenn es zumindest eine Position gibt, die sowohl bei A als auch B 1 ist, während für MATCH2 der Wert von 0 lediglich zurückgegeben wird, wenn es zumindest eine Position gibt, die sowohl bei A als auch bei B 0 ist.

Claims

Ein Verfahren zum Kompilieren von Quellcode zu einem primären und sekundären Prozessor, das folgende Schritte umfasst: selektive Extraktion von Datenflüssen von dem Quellcode; Transformation der extrahierten Datenflüsse in Bäume; Abgleichen der Bäume gegeneinander, um minimale Editierkostenbeziehungen für die Transformation von einem Baum zu einem anderen zu bestimmen; Bestimmen einer Gruppe oder einer Mehrzahl von Gruppen von Datenflüssen auf der Basis der minimalen Editierkostenbeziehungen und Erzeugen eines allgemeinen Datenflusses für jede Gruppe, der in der Lage ist, jeden Datenfluss in dieser Gruppe zu unterstützen; Verwenden des allgemeinen Datenflusses oder der Datenflüsse, um die Hardwarekonfiguration des sekundären Prozessors zu bestimmen; und Einsetzen von Aufrufen an den sekundären Prozessor für diese Gruppe oder die Mehrzahl von Gruppen von Datenflüssen in den Quellcode, und Kompilieren des resultierenden Quellcodes zu dem primären Prozessor.
Ein Verfahren gemäß Anspruch 1, bei dem die minimalen Editierkostenbeziehungen in einer Taxonomie minimaler Editierabschnitte für die Klassifizierung der Bäume ausgeführt sind.
Ein Verfahren gemäß Anspruch 1 oder Anspruch 2, bei dem die minimalen Editierkostenbeziehungen gemäß der Architektur des sekundären Prozessors bestimmt werden, und Hardwarekosten einer entsprechenden Rekonfiguration des sekundären Prozessors darstellen.
Ein Verfahren gemäß einem der Ansprüche 1 bis 3, bei dem die Hardwarekonfiguration des sekundären Prozessors eine Rekonfiguration des sekundären Prozessors während der Ausführung des Quellcodes ermöglicht.
Ein Verfahren gemäß Anspruch 4, bei dem der sekundäre Prozessor ein anwendungsspezifischer Befehlsprozessor ist.
Ein Verfahren gemäß Anspruch 4, bei dem der sekundäre Prozessor ein feldprogrammierbares Gatterarray ist.
Ein Verfahren gemäß Anspruch 4, bei dem der sekundäre Prozessor ein feldprogrammierbares arithmetisches Array ist.
Ein Verfahren gemäß einem der Ansprüche 4 bis 7, bei dem die Rekonfiguration des sekundären Prozessors während der Ausführung des Quellcodes erforderlich ist, um jeden Datenfluss in der Gruppe zu unterstützen, der durch einen allgemeinen Datenfluss unterstützt wird.
Ein Verfahren gemäß einem der vorhergehenden Ansprüche, bei dem ein allgemeiner Datenfluss einer Gruppe berechnet wird durch eine ungefähre Abbildung von Datenflüssen in der Gruppe aufeinander, gefolgt von einer Mischoperation.
Ein Verfahren gemäß einem der vorhergehenden Ansprüche, bei dem die Datenflüsse als gerichtete azyklische Graphen geliefert werden, und auf Bäume reduziert werden durch Entfernung jeglicher Verbindungen in den ge richteten azyklischen Graphen, die nicht in einem kritischen Weg zwischen einem Blattknoten und der Wurzel eines gerichteten azyklischen Graphs vorliegen.
Ein Verfahren gemäß Anspruch 10, bei dem der kritische Pfad ein Pfad zwischen zwei Knoten ist, der durch die größte Anzahl von Zwischenknoten verläuft.
Ein Verfahren gemäß Anspruch 10, bei dem der kritische Pfad ein Pfad zwischen zwei Knoten mit der höchsten angesammelten Ausführungszeit ist.
Ein Verfahren gemäß einem der Ansprüche 10 bis 12, bei dem nach der Erzeugung eines allgemeinen Datenflusses der allgemeine Datenfluss mit weiteren Datenflüssen verglichen wird, die von dem Quellcode extrahiert werden und auf eine in Anspruch 10 definierte Weise geliefert werden, wobei diejenigen der weiteren Datenflüsse, die mit dem allgemeinen Datenfluss ausreichend eng übereinstimmen, dem allgemeinen Datenfluss hinzugefügt werden.
Ein Verfahren gemäß einem der Ansprüche 10 oder 13 in Rückbeziehung auf Anspruch 9, bei dem die entfernten Verbindungen gespeichert werden, nachdem die gerichteten azyklischen Graphen auf Bäume reduziert wurden und nach dem Mischen der Bäume der Gruppe in den allgemeinen Datenfluss wieder in den allgemeinen Datenfluss eingefügt werden.