Titel : Über Datenverarbeitung
Beschreibung
Die vorliegende Erfindung betrifft das Oberbegrifflieh Beanspruchte. Sie bezieht sich somit u. a. darauf, wie zu einem gegebenen Hochsprachen- Programm ein ausführbarer Maschinencode erzeugt werden kann, wenn berücksichtigt werden muss, dass möglicherweise durch Prozessorwechsel, etwa die Verwendung neuerer Prozessorgenerationen, eine Änderung der Maschinencodes erforderlich wird.
Bei der Ausführung von Programmen auf Datenverarbeitungsanlagen wie Laptops, Servern und dergleichen wird typisch beim System, das heißt beispielsweise auf der Festplatte eines Laptops oder im Festplattenarray eines Servers, eine Vielzahl von Dateien vorrätig gehalten, die ausführbar sind. Damit ein Benutzer ein einzelnes Programm starten kann, sind typisch eine Vielzahl von modulartig miteinander zusammenwirkenden, ausführbaren Teilen erforderlich. In herkömmlichen Betriebssystemen wie MICROSOFT WINDOWS werden diese Programmteile Endungen wie „.exe" und ,,.dllλλ aufweisen.
Bei der Abarbeitung eines Programms werden häufig eine Vielzahl unterschiedlicher Module, die ausführbar sind, aufgerufen. Diese ausführbaren Module bilden gemeinsam eine Bibliothek (library) .
Die einzelnen Elemente einer Library sind dabei für die Ausführung an die jeweilige Datenverarbeitungsarchitektur ange- passt. Diese Anpassung erfolgt typisch durch Compilierung ei-
nes in einer Programmier-Hochsprache geschriebenen Programmteiles beziehungsweise Programms. Bei der Compilierung werden eine Vielzahl von Umformungen des Hochsprache-Programms oder -Programmteils vorgenommen, um zu einem auf der Zielarchitektur ausführbaren Codeteil zu gelangen. Die Compilierung ist ein in der Technik bestens bekanntes Verfahren. Verwiesen sei insbesondere auf Standardlehrbücher wie WIRTH, Compilerbau, AHO, SETHI und ULLMAMN „Red Dragon" .
Bei herkömmlichen Compilern wird zunächst der Hochsprachen- quelltext in für die Compilierung geeignete Teilstücke, sogenannte „Symbole" oder Anweisungen zerlegt (geparst) , auf Syntaxfehler untersucht usw. Dies geschieht im sogenannten Frontend des Compilers. Der vom Frontend erhaltene, aufbereitete Code wird dann abstrahiert, um einen sogenannten RTL- Code (Register Transfer Level -Code) zu erhalten. In dieser Stufe liegen typisch bereits die Datenfluss- und Kontroll- flussgraphen vor, die beispielsweise auch Erwähnung finden in den Veröffentlichungen des Anmelders (PCT/DE 02/03278, PCT/EP 02/10065, PCT/EP 2004/009640, PCT/EP 03/00624) einschließlich aller Familienmitglieder. Die genannten Schriften sind zu Offenbarungszwecken vollumfänglich eingegliedert.
Zielarchitekturen des Compilers sind insbesondere rekonfigu- rierbare Architekturen.
Unter einer rekonfigurierbaren Architektur werden u. a. Bausteine (VPU) verstanden, die eine Vielzahl in Funktion und/oder Vernetzung im Betrieb veränderliche Elemente (PAE) aufweisen, die vorzugsweise in einer zwei- oder noch höher dimensionalen Matrix angeordnet sind. Zu den Elementen können arithmetische Logikeinheiten, FPGA-Bereiche, Ein-Ausgabe-
zellen, Speicherzellen, analoge Baugruppen usw. gehören. Diese sind in der Regel grobgranular, also z. B. wenigstens 4, bevorzugt 8 Bit breit und in ihrer Funktion und Vernetzung konfigurierbar. Dazwischen können aber zum Teil auch feingra- nulare Bereiche angeordnet sein. Bausteine dieser Art sind beispielsweise unter der Bezeichnung VPU bekannt . Diese um- fasst typisch als PAEs bezeichnete ein- oder mehrdimensional angeordnete arithmetische und/oder logische und/oder analoge und/oder speichernde und/oder vernetzende Baugruppen und/oder kommunikative periphere Baugruppen (10) , die direkt oder durch einen oder mehrere Bussysteme miteinander verbunden sind. Die PAEs sind in beliebiger Ausgestaltung, Mischung und Hierarchie angeordnet, wobei die Anordnung als PAE-Array oder kurz PA bezeichnet wird. Es kann dem PAE-Array eine konfigurierende Einheit zugeordnet sein. Prinzipiell sind neben VPU-Baustei- nen auch systolische Arrays, neuronale Netze, Mehrprozessor- systeme, Prozessoren mit mehreren Rechenwerken und/oder logischen Zellen, Vernetzungs- und Netzwerkbausteine wie Cross- bar-Schaltung usw. bekannt, genauso wie FPGAs, DPGAs, Trans- puter usw.
Insbesondere gehören FPGAs zu den Zielarchitekturen, wobei die FPGAs bevorzugt zumindest einige der vorstehend aufgeführten (in der Regel grobgranularen, konfigurierbaren) Elemente (PAEs) aufweisen. Besonders bevorzugt ist zumindest eine Reihe oder Spalte innerhalb der FPGA Architektur, die Elemente aufweist mit zumindest einem Addierer und einem Multiplizierer, oder eine Arithmetisch-Logische-Einheit (ALU) .
Im übrigen sei bezüglich der Zielarchitekturen, und vorteilhafter Datenverarbeitungsverfahren auf diesen Zielarchitekturen hingewiesen auf die folgenden Dokumente der Anmelderin: P 44 16 881.0-53, DE 197 81 412.3, DE 197 81 483.2, DE 196 54 846.2-53, DE 196 54 593.5-53, DE 197 04 044.6-53, DE 198 80 129.7, DE 198 61 088.2-53, DE 199 80 312.9, PCT/DΞ 00/01869, DE 100 36 627.9-33, DE 100 28 397.7, DE 101 10 530.4, DE 101 11 014.6, PCT/EP 00/10516, EP 01 102 674.7, PCT/DE 97/02949, PCT/DE 97/02998, PCT/DE 97/02999, PCT/DE 98/00334, PCT/DE 99/00504, PCT/DE 99/00505, DE 101 39 170.6, DE 101 42 903.7, DE 101 44 732.9, DE 101 45 792.8, DE 101 54 260.7, DE 102 07 225.6, PCT/DE 00/01869, DE 101 42 904.5, DE 101 44 733.7, DE 101 54 259.3, DE 102 07 226.4, DE 101 10 530.4, DE 101 11 014.6, DE 101 46 132.1, DE 102 02 044.2, DE 102 02 175.9, DE 101 35 210.7, PCT/EP 02/02402, EP 01 129 923.7, PCT/EP 03/00624, PCT/EP 02/10084, PCT/DE 03/00942, PCT/EP 03/08080, PCT/EP 02/10464, PCT/EP 02/10536, PCT/EP 02/10572, PCT/EP 02/10479, PCT/EP 03/08081, PCT/EP 03/09956, PCT/EP 03/09957, DE 102 36 269.6, DE 102 43 322, EP 02 022 692.4, DE 103 00 380.0-53, DE 103 10 195.0-53, EP 03 009 906.3, PCT/EP 2004/006547, EP 03 015 015.5, PCT/EP 2004/009640, DE 103 41 051.1, PCT/EP 2004/003603, EP 03 025 911.3, DE 103 57 284.8-55, PCT/EP 2005/001211, DE 10 2004 004 955.6, DE 04 002 719.5, DE 04 075 382.4, EP 04 003 258.3, EP 04 004 885.2, EP 04 075 654.6, EP 04 005 403.3, EP 04 075 707.2, EP 04 013 557.6, EP 04 018 267.7, EP 04 077 206.3, PCT/EP 2006/001014, EP 05 003 174.9, EP 05 017 798.9, EP 05 017 844.1, EP 05 027 332.5, EP 05 027 333.3, PCT/EP 2007/000380,
DE 10 2007 054 903.4, DE 10 2007 055 131.4, jeweils inklusive aller Familienmitglieder.
Auch diese sind zu Offenbarungszwecken, ohne sich hier auf in den Schriften gezeigte oder erwähnte Sonderfälle zu beschränken, vollumfänglich eingegliedert.
Es sei darauf hingewiesen, dass als Zielarchitekturen der vorliegenden Erfindung neben den bekannten XPP-Bausteinen des Anmelders auch andere, parallel datenverarbeitende Architekturen in Frage kommen, wie die bereits genannten FPGAs. Nur beispielsweise seien etwa VIRTEX-Bausteine der Firma XILINX (SPARTAN, VIRTEX-2, VIRTEX-II Pro, VIRTEX-4, VIRTEX-5) etc. oder Bausteine von Altera insbesondere STRATIX usw. erwähnt. Die Bausteine weisen PAE Elemente in Form von DSP Zellen auf. Zum besseren Verständnis sei auf die Datenblätter der jeweiligen Bausteine verwiesen, die öffentlich zugänglich beispielsweise über die Internet Seiten der Hersteller XILINX und ALTERA zu erhalten sind und zu Offenbarungszwecken vollumfänglich eingegliedert sind.
Ebenfalls gehören Multithread Systeme und Prozessoren, wie z. B. INTEL Pentium und XEON oder AMD Athlon, zu den Zielarchitekturen.
Zum besseren Verständnis sei auch hier auf die Datenblätter der jeweiligen Bausteine verwiesen, die öffentlich zugänglich beispielsweise über die Internetseiten der Hersteller INTEL und AMD zu erhalten sind und zu Offenbarungszwecken vollumfänglich eingegliedert sind.
Im herkömmlichen Compilerbau wird der RTL-Code, der bereits optimiert ist, dann in einem sogenannten Backend weiterübersetzt auf den von der jeweiligen „Maschine", das heißt der tatsächlichen Zielstruktur, zu verstehenden Code. Bei rekon- figurierbaren Architekturen umfasst die Funktion des Backende typisch die Erzeugung tatsächlich ausführbarer Konfigurationen aus den hierfür vorhergehend optimierten Datenfluss- und Kontrollflussgraphen, was beispielsweise ein Plazieren und Routen erfordert . Auf den hier einschlägigen Stand der Technik, z. B. die von der Anmelderin stammende PCT/DE 02/03278, wurde bereits verwiesen. Andere Verfahren sind gleichfalls mit der Erfindung anwendbar.
Problematisch ist nun, dass das Backend, welches die maschi- nenangepassten Programm- beziehungsweise Bibliotheksteile ausgibt, typisch sehr eng an die jeweilige Rechnerarchitektur bzw. Maschine angepasst sein muss. Dies verhindert typisch, dass die Bibliotheksteile, die für eine bestimmte Zielarchitektur erstellt wurden, auf einer anderen Zielarchitektur ausgeführt werden können, beziehungsweise, sofern dies überhaupt der Fall sein könnte, performant ausgeführt werden können.
Es ist im Hinblick auf die sich regelmäßig ergebenden großen Fortschritte im Hardwarebereich jedoch erforderlich, dem Endbenutzer die Möglichkeit zu eröffnen, seine zuvor lauffähigen Programme auch auf einer verbesserten Hardware ausführen zu können. Dies soll mit möglichst geringem Aufwand geschehen, was typisch bedeutet, dass eine Kompilierung eines Hochspra- chenguellcodes nicht durchgeführt werden kann, weil eine solche Kompilierung für Durchschnitts- oder DAU-Benutzer allen-
falls unter größten Schwierigkeiten, wenn überhaupt, zu bewältigen ist.
Es ist wünschenswert, auf einfache Weise maschinenangepasste Bibliotheken bereitstellen zu können.
Die Aufgabe der vorliegenden Erfindung besteht darin, Neues für die gewerbliche Anwendung bereitzustellen.
Die Lösung dieser Aufgabe wird in unabhängiger Form beansprucht .
Mach einem ersten unabhängigen Gedanken der vorliegenden Erfindung wird somit vorgeschlagen, dem Benutzer ein Präcompi- lat zur Verfügung zu stellen, in welchem bereits bestimmte Optimierungen vorgenommen worden sind, um als solches Präcom- pilat ein intermediäres Format zu erzeugen, das vor (erstmaliger) Ausführung problemfrei fertig kompilierbar ist.
Die Kompilierung kann bestimmte architektur- aber nicht bausteinspezifische Optimierungen eines Hochsprachencodes umfassen, beispielsweise für die Präcompilaterzeugung jene Optimierungen, die erwähnt sind in PCT/EP 02/10065, PCT/EP 2004/003603, PCT/EP 2004/009640, PCT/EP 02/06865. Es werden also beispielsweise Optimierungen vorgenommen, die eine Aufteilung in parallele und vektorielle/sequentielle Programmanteile oder Flussanteile betreffen, ein (Hyper-) Threading betreffen usw. Diese Optimierungen können gegebenenfalls von einem Programmierer manuell unterstützt werden; dies ist allerdings nicht zwingend erforderlich. Es sei erwähnt, dass gegebenenfalls, wenn auch nicht im Optimalfall, als Ausgangscode für ein Präcompilat auch auf sequentiellen bekannten
Prozessoren ausführbare Programme, Programmteile und Module, das heißt existierende Binaries herangezogen werden, die einer architekturspezifischen Analyse unterzogen werden können, etwa um Parallelanteile herauszufinden und eine Anpassung auf Parallelarchitekturen auch ohne Kenntnis eines Quellcodes zu ermöglichen, was insbesondere für sogenannten Legacy-Code und dessen Verwendung von Vorteil ist. Dass dies vor allem für auf sequenziellen Architekturen ausführbare Binaries gilt, sei erwähnt. Es sei erwähnt, dass es möglich ist, für die Präcompilaterzeugung bestimmte Optimierungen so vorzunehmen, dass eine Anpassung auch auf allgemein zu erwartende Bausteineigenschaften erfolgt, z. B. durch Anpassung an die Anzahl vermutlich zu erwartender sequenzieller Einheiten wie Funktions- und/oder Graphfalteelemente in einem Array; hier ist der so - typisch iterativ - bestimmte Objektcode zwar schon im Hinblick auf die Zielbausteine optimiert, oftmals bleiben solche Optimierungen aber bei Generationswechsel sinnvoll .
Das Präcompilat kann und wird dann als Objektcode vor Ausführung einer bausteinspezifischen Optimierung unterworfen werden. Diese bausteinspezifische Optimierung kann beispielsweise angepasst sein an die Breite und Menge zur Verfügung stehender Busse, Registertiefen und/oder lokal vorhandene Speicher, den Befehlssatz von Elementen wie ALUs in einem Array beziehungsweise den unterschiedlichen Befehlssätzen unterschiedlicher Elemente in einem Array; es können bei dieser (zweiten) Optimierung temporale Partitionierungen entsprechend PCT/EP 03/00624 durchgeführt werden usw. Die entsprechend weiter optimierten Teile des RTL werden einem Backend zugeführt und daraus ein Binary-Code bestimmt. Dies ist deshalb vorteilhaft, weil bei Umstellungen der tatsächlich aus-
führenden Bausteine, beispielsweise bei Wechsel von einer Prozessor-Generation zu einer nächsten Prozessor-Generation leichter Anpassungen durch einfache Nachkompilierung des Prä- compilats vorgenommen. werden können.
Dies ist insbesondere bei solchen Zielarchitekturen von Interesse, deren Hardware Architektur nicht komplett vom ausführbaren Binärcode (Executable) abstrahiert werden kann - oder aus Komplexitäts- und/oder Kostengründen soll. Diese Gruppe umfasst somit vor allem die vorgenannten Field-Programmable- Gate-Arrays (FPGAs) und (re) konfigurierbare Prozessoren, wie z. B. die VPUs der Anmelderin, Bausteine des Herstellers Si- liconHive (Netherlands) , die ADRES Architektur des IMEC (BeI- gium) und IPFlex (Japan) . Die Architektur-Details sind öffentlich zugänglich und es soll auf die Web-Seiten und Patentanmeldungen der jeweiligen Anbieter verweisen werden, die zu Offenbarungszwecken vollumfänglich eingegliedert sind.
Es ist auch möglich, die typisch in eine Bibliothek eingefügten Binaries für unterschiedliche Prozessoren oder Prozessorkombinationen vorrätig zu halten, was es ermöglicht, bei Ausfall eines Teils von Prozessoren dennoch weiterarbeiten zu können, ohne dass der Gesamtbetrieb gestört wird. Dies trägt zu einem hoch versagenssicheren System bei. Die bausteinspezifischen Daten wie Busbreiten, Feldgrößen, Befehlssätze usw. können dem Nachcompilierer der vorliegenden Erfindung auf unterschiedliche Weise bekannt gegeben werden. In der besonders bevorzugten Variante können sie aus jedem im System verfügbaren, einschlägigen Chip ausgelesen werden. So können entsprechende Daten in einem ROM- oder einem Flash-Speicher beim oder auf dem Prozessor-Chip beziehungsweise -Modul gespei -
chert werden. Analog ist eine Ablage in einem BIOS oder dergleichen möglich, wenn auch nicht bevorzugt.
Es ist auch möglich, vor allem dann, wenn ein System Anbindung an das Internet oder andere Datenquellen hat, die einschlägigen Chip- beziehungsweise Moduldaten, die für die Kompilierung benötigt werden, von extern zu erhalten.
Zusammenfassend umfasst die Erfindung somit ein System und/oder Verfahren zur Zurverfügungstellung von flexiblerem und prozessorunabhängigerem Code für den Endbenutzer, wie folgt:
1. Ein Präcompilat wird beim Software-Hersteller durch einen Compiler erzeugt. Das Präcompilat ist kein prozessorspezifischer Binärcode im herkömmlichen Sinn, sondern ein Zwischen-Format (intermediate format) des Codes, zum Beispiel in Form von Graphen oder einer Register Transfer Language (RTL) . Der Code weist bevorzugt keine maschinenspezifischen Teile auf, sondern ist ein reines prozessorunabhängiges Zwischen-Format (intermediate format) .
2. Dieses Präcompilat wird an Stelle des nach dem Stand der
Technik üblichen Executables im Binärformat dem Anwender zur Verfügung gestellt .
3. Das Präcompilat wird auf dem Prozessorsystem oder Computer des Anwenders mittels eines Nachcompilers in das ausführbare Executable im Binärformat übersetzt. Verschiedene Zeitpunkte bieten sich zur Code-Übersetzung an und sind System-, markt- und anwenderspezifisch zu wäh-
len. Beispielsweise kann, das Präcompilat zu folgenden Zeitpunkten übersetzt werden:
a. während der Installation der Software b . beim Aufruf der Software c. beim Booten des Computers d. während der Ausführung, wobei sich hier auch insbesondere die Interpretation des Präcompilates anbietet .
Es soll an dieser Stelle auf die Programmiersprache JAVA verwiesen werden. JAVA wird ebenfalls nicht als ausführbarer Binärcode (Executable) distributiert, sondern in Form einer Zwischenrepräsentation. Dies ist jedoch, als wesentlicher Unterschied zu der vorliegenden Erfindung, bereits prozessorspezifisch auf die JAVA Virtual Machine übersetzt und somit nicht mehr vollständig zielsystemunabhängig. Zwar kann der Code auf unterschiedlichen Zielprozessoren ausgeführt werden, diese implementieren bzw. emulieren jedoch entweder innerhalb eines Interpreters zur Laufzeit, oder eines Compilers die JAVA Virtual Machine. Sämtliche spezifischen Limitierungen der JAVA Virtual Machine sind daher bereits implizit im Präcompilat enthalten und lassen sich kaum oder nicht mehr auf dem Zielsystem optimieren. Dies ist im Übrigen einer der wesentlichen Nachteile von JAVA, da hierdurch die mögliche Performance erheblich eingeschränkt wird.
Es soll nochmals herausgestellt werden, dass im Unterschied zu JAVA das erfindungsgemäße Präcompilat ein reines Zwischenformat ist, das keine prozessor- oder architekturspezifischen Merkmale aufweist und damit effizient auf jedes mögliche Zielsystem compiliert werden kann.
- Ii -
Das Präcompilat ist dabei jedoch bevorzugt bereits auf bestimmte Prozessortypen und Basisarchitekturen hin optimiert und ausgestaltet.. Beispielsweise wird ein Präcompilat für FPGAs bereits andere Optimierungsschritte und Transformationen im Präcompiler durchlaufen haben als das Präcompilat für gewöhnliche sequentielle Prozessoren. Auch mag das Präcompilat bereits herstellerspezifische Optimierungen aufweisen, und sich somit das Präcompilat in Architekturdetails zwischen beispielsweise Altera und XILINX FPGAs unterscheiden. Das Compiler ist jedoch vollständig unabhängig von bestimmten Bausteinen innerhalb einer bestimmten Baustein- oder Architektur-Familie (z. B. Virtex-4) und bevorzugt weitestgehend unabhängig zwischen ähnlichen Baustein- oder Architektur- Familien (wie z. B. Virtex-4 und Virtex-5) und ermöglicht somit eine flexible und effiziente Endcompilierung auf die entsprechenden Zielbausteine oder Zielprozessoren.
Der klassische Compileraufbau ist im Übrigen in Fig. 2a dargestellt. In dieser bedeutet 0201 den Hochsprachenquellcode, beispielsweise C-Code. 0202 stellt das Frontend dar, 0204 das intermediäre Format, 0205 das Backend und 0206 die aus dem Backend ausgegebenen Binärdaten. 0203a bis 0203n sind die für die Optimierung des intermediären Formates erforderlichen Optimierer beziehungsweise Transformierer, die in Hard- und/ oder typisch Software erstellt sein können und insoweit bestimmte Verfahrensschritte darstellen.
In Fig. 2b sind im wesentlichen dieselben Einheiten beziehungsweise Stufen wie in Fig. 2a beschrieben, nunmehr aber unter Implementierung der vorliegenden Erfindung. Der letztlich ausgegebene Binary-Code, der in einer Bibliothek oder
dergleichen eingetragen werden kann, ist in Fig. 2b als 0214 bezeichnet. Das Backend ist als 0213 bezeichnet. Die Präcom- pilaterzeugung findet in 0204 nach Durchlauf eines Hochsprachen-Codes beziehungsweise eines für einen sequentiellen Prozessor oder Co-Prozessor aufbereiteten Binär-Codes 0201 durch ein Frontend 0202 in der Stufe 0204 statt, wobei die verschiedenen Optimierungen 0203a bis 0203i ausgeführt werden, die vorstehend bereits erwähnt wurden. Das erzeugte und ausgeworfene Präcompilat 0210 wird als Objektcode in eine intermediäre Stufe 0211 eingespeist, die wiederum über die spezifischen Daten jener Chips verfügt, auf denen die Programmteile, Module usw. später tatsächlich ausgeführt werden sollen. Es werden chipspezifische Optimierungen 0212a bis 0212g ausgeführt. Dass das Präcompilat verfügbar, handelbar und versendbar gemacht wird, ist somit besonders vorteilhaft .
Es sei erwähnt, dass typisch die Ausführung der chipspezifischen beziehungsweise bausteinspezifischen Optimierungen signifikant später und/oder auf einem anderen Rechnersystem als die Präcompilaterzeugung erfolgen kann. Insbesondere kann die Nachcompilierung durch die Zielarchitektur selbst erfolgen. Dies wird für sich jeweils als besonders vorteilhaft angesehen. Es sei allerdings darauf hingewiesen, dass gegebenenfalls auch dasselbe Rechnersystem verwendet werden kann, etwa weil ein bestehendes Hochsprachenprogramm nach Präcompilie- rung für eine Vielzahl unterschiedlicher Rechnerbausteine von einem Softwarehersteller übersetzt werden soll .
Der Nachcompilierer 0211 speist das Nachcompilat an das Backend 0213, das ein chipspezifisches Binary erzeugt. Es sei darauf hingewiesen, dass gegebenenfalls ein einzelnes Binary eine Vielzahl von Teilbinaries für spezifische Chips umfassen
kann, wobei beim Laden eines in einer Bibliothek abgelegten derartigen Binaries das jeweils benötigte Teil-Binary aus dem so zusammengestellten Binary ausgewählt wird. Alternativ ist es möglich, in einer Bibliothek Binaries abzulegen, die zwar prinzipiell dieselben Programmteile oder Funktionen ausführen, gleichwohl aber für unterschiedliche Maschinen beziehungsweise Chips kompiliert sind und jeweils typisch auch nur und ausschließlich auf diesen laufen beziehungsweise zumindest nur auf diesen performant laufen.
Fig. 1 zeigt dann, wie ein gegebener Objektcode 0105 in dem (lokalen) Übersetzer/Nachcompilierer 0104 unter Berücksichtigung von chipspezifischen Informationen aus einer Datenbank 0106 oder einem Chip, insbesondere der Chip-ID, vergleiche 0102, Extraktion 0103 nachkompiliert wird, um in einem Backend 0107 Binaries zu erzeugen, die dann in einer Bibliothek 0101 abgelegt werden, um nach Verlinkung von einem Programm 0108 instanziiert zu werden.
Bei der gewünschten Instanziierung eines Programms oder Programmteiles kann dann geprüft werden, ob ein in der Library vorhandenes Element beziehungsweise Modul eine Chip- Id oder dergleichen aufweist, die jener Chip- Id des Chips, der gerade mit dem Programm beziehungsweise Programmteil geladen werden soll. Ist dies der Fall, kann der Programmteil geladen werden. Ist dies nicht der Fall, wird der Objektcode für die tatsächlich vorhandene Zielarchitektur nachkompiliert. Dies kann, hinreichend hohe Leistungsfähigkeit der Zielarchitektur und/oder anderer, im System vorhandener Datenverarbeitungs- prozessoren vorausgesetzt/ auch in für den Benutzer transparenter Weise geschehen, etwa während eines Ladevorganges in
Echtzeit; dann muss nur der Objektcode, das heißt das Präcom- pilat, in Zugriff ermöglichender Weise mit abgelegt werden.