DE102005021749A1

DE102005021749A1 - Verfahren und Vorrichtung zur programmgesteuerten Informationsverarbeitung

Info

Publication number: DE102005021749A1
Application number: DE102005021749A
Authority: DE
Inventors: Wolfgang Dr. Matthes
Original assignee: Fachhochschule Dortmund
Current assignee: Fachhochschule Dortmund
Priority date: 2005-05-11
Filing date: 2005-05-11
Publication date: 2006-11-16
Also published as: US20060259744A1

Abstract

Herkömmliche Rechnerarchitekturen können den in üblichen Programmen gegebenen inhärenten Parallelismus nur unvollkommen ausnutzen. Hard- und Software sind nicht ohne weiteres gegeneinander austauschbar. Das neue Verfahren soll den inhärenten Parallelismus in höchstmöglichem Maße nutzbar machen. Zudem soll es möglich werden, Hard- und Software beliebig gegeneinander auszutauschen. DOLLAR A Das Verfahren umfaßt folgende Schritte: 1. Ressourcen aus einem Ressourcenvorrat auswählen, 2. Verbindungen einrichten, 3. mit Parametern versorgen, 4. Verarbeitungsvorgänge auslösen, 5. Daten transportieren, 6. Ergebnisse zuweisen, 7. Verbindungen trennen, 8. Ressourcen freigeben. Die Ausführung der Verfahrensschritte wird durch Anweisungsangaben (Operatoren) gesteuert. Die Verfahrensschritte können sowohl auf Schaltungsanordnungen als auch auf Programme angewendet werden. Verbindungen können so eingerichtet werden, daß die Ressourcenanordnung dem Datenflußschema des Anwendungsproblems entspricht. Vorrichtungen zur Durchführung des Verfahrens bestehen aus Plattformanordnungen (1), Speichermitteln (2) und Verarbeitungsressourcen (3). DOLLAR A Das Verfahren wird in programmgesteuerten Informationsverarbeitungseinrichtungen eingesetzt, um beliebige Verarbeitungsaufgaben auszuführen.

Description

Die Erfindung betrifft ein Verfahren zur programmgesteuerten Informationsverarbeitung und Vorrichtungen zur Durchführung dieses Verfahrens. Die Erfindung wird in programmgesteuerten Informationsverarbeitungseinrichtungen aller Art eingesetzt, die durch Programmierung beliebige Aufgaben der Informationsverarbeitung ausführen können.

Rechenanlagen (Computer) erbringen ihre Funktionen im Verbund von Schaltmitteln (Hardware) und gespeicherten Programmen (Software). Entscheidend für dieses Zusammenwirken ist die Schnittstelle zwischen Hard- und Software (Rechnerarchitektur). Diese Schnittstelle ist herkömmlicherweise durch eine Menge elementarer Datenstrukturen und über diese definierte Maschinenbefehle gekennzeichnet. Der einzelne Maschinenbefehl spezifiziert einen ziemlich einfachen Verarbeitungsvorgang. Befehlslisten und Datenstrukturen sind aus der Erfahrung heraus entstanden. Die ersten Computer wurden als Rechenmaschinen entwikkelt. Deshalb lag es nahe, die Grundrechenarten des numerischen Rechnens als Befehlswirkungen vorzusehen. Ein Befehl veranlaßt typischerweise eine solche Rechenoperation, einen Hilfsablauf (Datentransport, Eingabe, Ausgabe usw.) oder eine Funktion der Ablaufsteuerung (Verzweigung, Unterprogrammruf usw.). Die einzelnen Architekturen unterscheiden sich vor allem in den Zubringerfunktionen (Adressierung, Registermodell). Programme für übliche Rechnerarchitekturen sind ihrer Natur nach sequentiell. Das grundlegende Programmiermodell sieht vor, einen Befehl – und damit eine Verknüpfungsoperation – nach der anderen auszuführen.

Man ist stets bestrebt, die Verarbeitungsleistung zu erhöhen. Die Ausführungszeiten der einzelnen Abläufe lassen sich aber nicht beliebig verringern. Die Grenzen sind durch die Schaltverzögerungs- und Signallaufzeiten der Hardware gegeben. Um die Verarbeitungsleistung darüber hinaus zu erhöhen, hat man Computer mit mehreren Verarbeitungseinrichtungen ausgerüstet, die gleichzeitig (parallel zueinander) betrieben werden. Das Problem besteht darin, wie diese Einrichtungen genutzt werden. In manchen Anwendungsgebieten ist es offensichtlich, daß eine Vielzahl von Informationsverarbeitungsvorgängen gleichzeitig ausgeführt werden kann (Parallelverarbeitung). Zumeist ist die Möglichkeit der Parallelausführung aber nicht ohne weiteres erkennbar. Die meisten Programme werden nicht im Hinblick auf Parallelverarbeitung geschrieben, und die gängigen Programmiersprachen beruhen auf der sequentiellen Ausführung der Anweisungen. Nicht alle Anweisungen bzw. Befehle müssen aber wirklich nacheinander ausgeführt werden. Beispiel:

1. Befehl: X := A + B
2. Befehl: Y := C + D

Stehen zwei Rechenwerke zur Verfügung, könnte man beide Befehle gleichzeitig ausführen. Die Tatsache, daß es in üblichen Programmen Befehle und Befehlsfolgen gibt, die gleichzeitig (parallel zueinander) ausgeführt werden können, heißt innewohnender (inhärenter) Parallelismus (inherent parallelism).

Es gibt verschiedene Möglichkeiten, den inhärenten Parallelismus zu erkennen und auszunutzen. Die entscheidende Voraussetzung ist die Verfügbarkeit mehrerer Verarbeitungswerke (Superskalarprinzip). Die wesentlichen Unterschiede bestehen darin, wie diese Hardware gesteuert wird. Im Grunde gibt es zwei Prinzipien:

1. herkömmliche Programmschnittstelle bzw. Befehlsliste. Der einzelne Befehl gibt jeweils eine einzige auszuführende Operation an und veranlaßt somit die Nutzung einer einzigen Verarbeitungseinrichtung. Der inhärente Parallelismus wird zur Laufzeit erkannt. Hierzu werden mehrere aufeinanderfolgende Befehle gleichzeitig geholt und decodiert. Da beim Schreiben des Programms die Parallelausführung nicht berücksichtigt wurde, kann es zu Konflikten kommen. Beispiel: 1. Befehl: X := A + B 2. Befehl: Y := C + X Werden beide Befehle gleichzeitig ausgeführt, so rechnet der zweite mit dem bisherigen Wert von X, liefert also ein falsches Ergebnis. Solche Konflikte werden von besonderen Schaltmitteln erkannt und durch nochmaliges Ausführen der betroffenen Befehle gelöst. Neben den eigentlichen Verarbeitungsressourcen sind Schaltungen zum Erkennen von Gelegenheiten zur parallelen Verarbeitung und zum Erkennen und Auflösen der Konfliktfälle erforderlich. Der Aufwand hierfür ist vergleichsweise hoch. Deshalb können nur wenige Befehle auf parallele Ausführbarkeit geprüft werden, und die Anzahl der Verarbeitungseinrichtungen läßt sich nicht beliebig erhöhen. Typisch sind zwei bis vier Verarbeitungswerke je Datentyp (ganze Binärzahlen, Gleitkommazahlen usw.). Eine wesentlich größere Anzahl an Verarbeitungswerken würden eine untragbaren Aufwand erfordern, um die möglichen Konfliktfälle zu erkennen. Da im Konfliktfall die Befehlsausführung wiederholt werden muß, sinkt in der Praxis die Verarbeitungsleistung. Zudem ist es (wegen des Steuerungs- und Überwachungsaufwandes) üblich, nur elementare Befehle auf diese Weise zu unterstützen; Befehle mit komplizierteren Wirkungen werden oftmals nach wie vor nur einzeln ausgeführt.
2. Befehle mit Angaben zur Steuerung der Parallelarbeit. Es gibt verschiedene Ausführungen, z. B. extrem lange Befehle mit Steuerangaben für alle Ressourcen (VLIW = Very Long Instruction Word) oder Befehle, in denen angegeben werden kann, ob nachfolgende Befehle parallel ausführbar sind oder nicht (expliziter Parallelismus). Überwachungsvorkehrungen in der Hardware sind nicht erforderlich (Schaltungsvereinfachung). Die Anzahl der so unterstützten Verarbeitungseinrichtungen ist aber beschränkt (Befehle können nicht beliebig lang werden) und typischerweise in der jeweiligen Architektur festgelegt (z. B. auf drei, vier oder acht Rechenwerke). Die tatsächliche Verarbeitungsleistung hängt wesentlich vom Compiler ab, der aus dem Quelltext heraus die Programmierabsicht erkennen und festlegen muß, wie die vorhandenen Ressourcen am besten ausgenutzt werden. Ein derart optimiertes Maschinenprogramm ist auf Hardware mit abweichender Ausstattung (z. B. acht statt drei Rechenwerke) nicht ohne Neucompilierung lauffähig.

Zum Entwicklungsstand der universellen Rechenanlagen gibt es ein umfangreiches Schrifttum. Einen Überblick vermittelt u. a. das Lehrbuch „Computer Architecture – A Quantitative Approach" von Patterson und Hennessy. Einzelheiten sind vor allem aus den Handbüchern und Anwendungsschriften ersichtlich, die von den einschlägigen Herstellern im Internet bereitgehalten werden. Als Beispiel sei http:\\developer.intel.com genannt.

Eine weitere Möglichkeit zur Leistungssteigerung besteht darin, die gewünschten Informationswandlungen nicht mit Folgen vergleichsweise einfacher Befehlswirkungen zustande zu bringen, sondern die Schaltmittel gezielt in Hinsicht auf die gewünschten Wirkungen auszulegen (Spezialhardware). Solche Einrichtungen werden vorzugsweise mit programmierbaren Logikschaltkreisen (Field Programmable Gate Arrays; FPGAs) aufgebaut. Das erfordert eine detaillierte Schaltungsentwicklung. Um die Entwicklungsarbeiten zu erleichtern, werden fertige Schaltungen bereitgestellt, die in die eigenen Entwürfe eingebettet werden (IP Cores; IP = Intellectual Property). Hiervon gibt es zwei Arten:

1. „weiche" Schaltungen (Soft Cores). Sie liegen als Schaltungsbeschreibungen vor, werden in den Entwicklungsablauf eingebunden und mit den Mitteln des programmierbaren Schaltkreises (Funktionsblöcke, Makrozellen usw.) realisiert.
2. „harte" Schaltungen (Hard Cores). Sie sind auf dem Schaltkreis in fester Form (nicht programmierbar) vorhanden.

Solche Schaltkreise sind vergleichsweise teuer, und die Entwicklung ist aufwendig. Es ist daher naheliegend, nach Kompromißlösungen zu suchen und die jeweiligen Anwendungsaufgaben im Verbund von Hard- und Software zu lösen. Typische Prinzipien:

a) ein üblicher Universalrechner (typischerweise ein Mikroprozessor) arbeitet mit spezieller Hardware zusammen,
b) nur wirklich zeitkritische Funktionen werden mit spezieller Hardware unterstützt,
c) werden keine extremen Leistungsanforderungen gestellt, so wird auf spezielle Hardware verzichtet,
d) der Universalrechner (Prozessor) kann in seiner Struktur verändert werden, um die Aufwendungen gering zu halten (das betrifft beispielsweise die Größe von Registersätzen und die Ablaufbeschleunigung für bestimmte Befehle).

Beträchtliche Schwierigkeiten ergeben sich daraus, daß zwei verschiedene Entwicklungsabläufe miteinander zu koordinieren und aufeinander abzustimmen sind (Hardware-Software-Codesign). Herkömmlicherweise hat man solche Probleme durch Einsatz von zwei Sprachen gelöst (Programmiersprache + Hardware-Beschreibungssprache). Dabei wird ein Universalprozessor ggf. durch zusätzliche Hardware ergänzt. Der Universalprozessor bleibt im wesentlichen gleich; es gibt lediglich die Möglichkeit, die Konfiguration in gewissen Grenzen zu ändern (das betrifft z. B. die Größe von Caches und Registersätzen, die Anordnung von Gleitkommaverarbeitungshardware usw.). Dem universellen Prozessor zugeordnete spezielle Hardware wird über Sonderbefehle angesprochen, die zum Befehlssatz des Prozessors hinzugefügt werden. Eine solche Verfahrensweise ist z. B. in dem US-Patent 6,477,683 „Automated processor generation system for designing a configurable processor and method for the same" eingehend beschrieben. Diese Schrift enthält zudem weitere Verweise auf den bekannten Stand der Technik.

Das Ziel der Erfindung besteht darin, den inhärenten Parallelismus in Informationsverarbeitungsabläufen in höchstmöglichem Maße nutzbar zu machen, d. h. in den Grenzen, die sich aus Programmierabsicht einerseits und jeweils verfügbarer Hardware andererseits ergeben, sowie Schnittstellen zwischen Hard- und Software anzugeben, die eine beliebige Austauschbarkeit von Hard- und Software gewährleisten.

Die Aufgabe der Erfindung besteht darin, ein Verfahren zur Nutzung informationsverarbeitender Einrichtungen anzugeben, wodurch eine beliebige Anzahl solcher Einrichtungen programmseitig freizügig angesprochen bzw. zu Schaltungsanordnungen konfiguriert werden kann, die die gewünschten Informationswandlungen ausführen. Des weiteren besteht die Aufgabe der Erfindung darin, Vorrichtungen anzugeben, mit denen das Verfahren durchgeführt werden kann.

Die Mängel der bekannten Lösungen haben ihre Ursache vor allem darin, daß sie im Grunde nach wie vor auf dem herkömmlichen Universalrechner aufbauen. Einrichtungen, die versuchen, den inhärenten Parallelismus in üblichen Programmen zur Laufzeit zu erkennen, können nur jeweils wenige aufeinanderfolgende Befehle berücksichtigen. Zudem sind Konfliktfälle zu erkennen und ggf. durch wiederholte Befehlsausführung aufzulösen. Hierzu sind vergleichsweise aufwendige Schaltmittel erforderlich. Die eigentlichen Verarbeitungseinrichtungen werden nur unvollkommen ausgenutzt, weil sie zwecks Konfliktauflösung ggf. mehrmals durchlaufen werden müssen (Befehlswiederholung). Wird die Parallelarbeit von den Befehlen aus explizit gesteuert, so entfallen die soeben beschriebenen Nachteile. Es kann aber nur eine beschränkte, feste Anzahl an Verarbeitungseinrichtungen unterstützt werden, wobei die Auslegung der einzelnen Verarbeitungseinrichtung ebenfalls ziemlich starren Beschränkungen unterliegt (z. B. in Hinsicht auf die Zahl und Art der Operanden, auf die Anzahl der Taktzyklen je Informationswandlung usw.). Der Übergang auf auch nur geringfügig anders ausgestattete Systeme erfordert ein erneutes Compilieren der betreffenden Programme (mit Maschinenbefehlen, die z. B. nur drei Verarbeitungswerke unterstützen, könnte man ein System das z. B. acht Verarbeitungswerke enthält, nur sehr unvollständig ausnutzen). Ergänzt man einen universellen Prozessor durch spezielle Hardware, so sind zwei verschiedenartige Entwicklungsabläufe zu beherschen (Hardware-Software-Codesign). Solche Anordnungen sind nur in eng begrenzten Anwendungsbereichen wirklich effektiv; der Übergang zu einem anderen Anwendungsbereich erfordert typischerweise einen erneuten Entwicklungsablauf.

Die Aufgabe wird erfindungsgemäß durch die in den Patentansprüchen angeführten Verfahrensschritte und Schaltungsanordnungen gelöst. Das Verfahren beruht darauf, daß die zur Ausführung der Informationsverarbeitungsvorgänge vorgesehenen Einrichtungen gemäß Anspruch 1 einen Ressourcenvorrat bilden. Die jeweils benötigten Ressourcen werden aus diesem Vorrat ausgewählt und zur Durchführung der jeweiligen Informationswandlungen eingesetzt. Ressourcen, die nicht mehr benötigt werden, werden in den Ressourcenvorrat zurückgegeben. Die einzelnen Verfahrensschritte sind in den kennzeichnenden Merkmalen des Anspruchs 2 angegeben. Die Ansprüche 3 bis 13 betreffen die Steuerung der einzelnen Verfahrensschritte durch gespeicherte Anweisungsangaben. Die Ansprüche 14 bis 18 betreffen vorteilhafte Ausgestaltungen des Verfahrens, nämlich das Aufbauen von komplexeren Ressourcen aus einfacheren, das Erzeugen, Transportieren und Verändern von Anweisungsangaben durch rekursive Anwendung der Verfahrensschritte, den Aufbau von Ressourcenanordnungen, die dem Datenflußschema des jeweiligen Anwendungsproblems entsprechen, sowie die gemeinsame Ausführung bestimmter Verfahrensschritte in bestimmten Zeitabschnitten. Die Ansprüche 19 bis 21 betreffen die Bereitstellung von Ressourcen in Form von Schaltungsanordnungen, durch programmseitige Nachbildung der jeweiligen Wirkungen (Emulation) oder dadurch, daß eine entsprechende Schaltungsanordnung auf einem geeigneten Schaltkreis durch Programmierung erzeugt wird. Die Ansprüche 22 bis 24 betreffen Ausgestaltungen der Anweisungsangaben. Die Ansprüche 25 bis 46 betreffen Einzelheiten der Durchführung des Verfahrens. Die Ansprüche 47 bis 140 betreffen Vor richtungen zur Durchführung des Verfahrens. Im einzelnen betreffen die Ansprüche 47 bis 50 grundsätzliche Strukturen von Vorrichtungen, 51 und 52 Vorrichtungen auf Grundlage von Universalrechnern (die ggf. geringfügig abgewandelt werden), 53 den grundsätzlichen Aufbau von Ressourcen in Form von Schaltungsanordnungen, 54 bis 56 den grundsätzlichen Aufbau von Ressourcen, deren Wirkungen programmtechnisch hervorgebracht werden (Emulation) oder die durch Programmierung auf entsprechenden Schaltkreisen erzeugt werden, 57 den Aufbau einfacher Ressourcen in Form von Schaltungsanordnungen, 58 und 59 die Funktionssteuerung, 60 und 61 die Verkettung, 62 bis 66 Ressourcen, die selbsttätig Speicherzugriffe ausführen können, 67 und 68 die Einstellung und Anzeige der Verarbeitungsbreite, 69 die Kopplung über eine Systemanschlußsteuerung, 70 bis 77 elementare Plattformstrukturen, 78 bis 80 grundsätzliche Auslegungen von Speichermitteln, 81 und 82 die Ausgestaltung als Harvard- und v.Neumann-Maschine, 83 das Befehlslesen seitens der Verarbeitungsressourcen, 84 bis 89 Adressierungsschaltungen, 90 bis 94 Iteratorschaltungen, 95 bis 97 Arithmetik-Logik-Einheiten (ALUs) als universelle Ressourcen, 98 bis 102 die Verkettung von Ressourcen, 103 und 104 Ressourcen mit eigenen Speichereinrichtungen (Ressourcenzellen), 105 bis 115 Ressourcen in Speicheranordnungen, 116 bis 124 Ressourcen in Schaltkreisen (vorzugsweise in FPGAs), 125 bis 130 die Adressierung der Speichermittel (Register) in den Ressourcen, 131 bis 135 die Auslegung ein- und ausgangsseitiger Speichermittel als adressierbare Speicheranordnungen sowie 136 bis 140 ergänzende Vorkehrungen zur Leistungsmessung, zum Fehlersuchen, für Schutzfunktionen usw.

Die Erfindung beruht darauf, daß jedes beliebige Programm stets eine Hardware zu seiner Ausführung benötigt; es wird letzten Endes in Informationstransporte, kombinatorische Verküpfungen und Zustandsübergänge überführt, d. h. in den Informationsfluß in einer Register-Transfer-Struktur. Die Erfindung wirkt derart, daß von der Programmierabsicht ausgehend eine jeweils angemessene Register-Transfer-Struktur ad hoc aufgebaut wird, und zwar aus elementaren Verarbeitungseinrichtungen, die als Ressourcen bezeichnet werden. Unter einer Ressource kann man sich z. B. eine übliche Arithmetik-Logik-Einheit vorstellen, aber auch eine komplizierte Spezialschaltung. Das allgemeine Modell einer Ressource ist eine Hardware, die bestimmte Informationswandlungen ausführt, also aus gegebenen Daten (an den Eingängen) neue Daten (an den Ausgängen) errechnet. Dem Verfahren liegen folgende Ansätze zugrunde:

1. es gibt jederzeit genügend Ressourcen. Das ist zunächst eine theoretische Annahme (Hypothese vom (nahezu) unbeschränkten Ressourcenvorrat). Auf dieser Grundlage ist es möglich, Ressourcen in beliebiger Anzahl anzufordern (beispielsweise einige hundert Multiplikationswerke) und den inhärenten Parallelismus in vollem Umfang auszunutzen. Maschinenprogramme werden typischerweise so erzeugt (z. B. mittels Compiler), als ob beliebig viele Ressourcen zur Verfügung stünden. Die Anpassung an die Gegebenheiten der Praxis (jeder tatsächliche Ressourcenvorrat ist begrenzt) kann zur Compilierzeit oder zur Laufzeit erfolgen (Emulation, Virtualisierung).
2. ob eine Ressource als Software oder als Hardware ausgeführt ist, spielt keine Rolle,
3. das grundsätzliche Modell einer Ressource ist stets eine Hardware, also eine technische Einrichtung mit Ein- und Ausgängen,
4. ein Verarbeitungsvorgang (Programmablauf) besteht in der Benutzung von Ressourcen im Laufe der Zeit (Ressourcen werden bei Bedarf aus dem Ressourcenvorrat entnommen und bei Nichtgebrauch zurückgegeben),
5. die zur Steuerung der Verfahren vorgesehenen Anweisungsangaben (Operatoren) betreffen nur die grundlegenden Verfahrensschritte des Anforderns, Transportierens, Auslösens usw., nicht aber konkrete Maschinenoperationen (vollständige Maschinenunabhängigkeit),
6. die zur Durchführung des Verfahrens dienenden Einrichtungen können rekursiv aus elementaren Ressourcen aufgebaut werden,
7. Anweisungsangaben, die erfindungsgemäße Verfahrensschritte steuern, können durch rekursive Anwendung erfindungsgemäßer Verfahrensschritte erzeugt, transportiert oder verändert werden,
8. wo die Ressourcen angesiedelt und wie sie aufgebaut sind, spielt keine Rolle. U. a. ist es möglich, Ressourcen übers Internet anzufordern und auszunutzen (z. B. Spezialrechner).

Um eine bestimmte Programmierabsicht auszuführen, werden jeweils geeignete Ressourcen aus dem Ressourcenvorat ausgewählt. Diese werden mit Parametern versorgt. Dann werden die Verarbeitungsvorgänge in den Ressourcen ausgelöst. Anschließend werden die Ergebnisse zugewiesen (Endergebnisse werden gespeichert oder ausgegebenen, Zwischenergebnisse an andere Ressourcen weitergeleitet). Weitere Schritte der Parameterversorgung, Auslösung und Zuweisung werden so oft durchlaufen, bis die jeweilige Verarbeitungsaufgabe ausgeführt ist. Schließlich werden die nicht mehr benötigten Ressourcen an den Ressourcenvorrat zurückgegeben. Die Verarbeitungsschritte werden von Anweisungsangaben gesteuert, die in Speichermitteln untergebracht sind. Besondere Verfahrensschritte ermöglichen es, Verbindungen zwischen Ressourcen einzurichten (die Ressourcen miteinander zu verketten) und solche Verbindungen wieder zu trennen. Ist eine Verbindung (Verkettung) zwischen Ressourcen eingerichtet, laufen die Verfahrensschritte der Parameterversorgung, des Auslösen der Verarbeitungsvorgänge und des Zuweisens der Ergebnisse innerhalb der verketteten Ressourcen weitgehend selbsttätig ab; es ist dann nicht mehr erforderlich, jeden einzelnen Verfahrensschritt durch besondere Anweisungsangaben zu steuern.

Die Anweisungsangaben enthalten zum einen Bitmuster, die die Art der Angabe und die auszuführende Funktion kennzeichnen, und zum anderen Angaben, die sich auf die zur Durchführung des Verfahrens vorgesehenen Speichereinrichtungen, Verarbeitungseinrichtungen und Steuereinrichtungen beziehen. Sie wirken typischerweise im Sinne des Auswählens oder Adressierens und im Sinne des Auslösens von Transport- und Verarbeitungsabläufen. Zum Abruf der Anweisungsangaben aus den Speichermitteln sind weitere Ressourcen vorgesehen. Es gibt verschiedene Möglichkeiten, die Anweisungsangaben zu gestalten:

a) sie werden eigens zur Steuerung der erfindungsgemäßen Verfahrensschritte ausgebildet,
b) sie werden ähnlich den bekannten Maschinenbefehlen oder Mikrobefehlen ausgebildet,
c) ihre Wirkungen werden mit Folgen herkömmlicher Maschinenbefehle oder Mikrobefehle nachgebildet (Emulation).

Das Verfahren läuft letzten Endes darauf hinaus, eine Hardware zu entwerfen, die die betreffende Verarbeitungsaufgabe ausführen kann, und zwar zunächst als Gedankenexperiment, unabhängig von der tatsächlichen praktischen Durchführbarkeit. Diese (fiktive) Hardware kann zur Laufzeit dynamisch auf-, um- und abgebaut werden. Es wird fallweise entschieden, was tatsächlich als Hardware implementiert wird und was nicht. Ist eine Res source nicht direkt als Hardware verfügbar, so wird deren Wirkung mit anderen Ressourcen auf Grundlage des erfindungsgemäßen Verfahrens (Rekursion) oder mit herkömmlichen Maschinenprogrammen (Emulation) nachgebildet.

Die Verfahrensschritte der Parameterübergabe, Funktionsauslösung usw. können sowohl auf Verarbeitungsschaltungen (Hardware) als auch auf Programme (Software) angewendet werden; Programme und Hardware-Ressourcen werden gleichartig aufgerufen. Jedes Programm bzw. Unterprogramm entspricht dem Modell einer Hardware mit Registern an den Ein- und Ausgängen (Register-Transfer-Modell).

Die Anweisungsangaben betreffen keine bestimmten Operationen, sondern das Auf-, Um- und Abbauen von Ressourcen, die zugehörigen Datentransporte und das Aktivieren der betreffenden Ressourcen.

Vorrichtungen zur Durchführung des Verfahrens enthalten Plattformanordnungen, Verarbeitungsschaltungen und Speichermittel. Es ist möglich, entsprechende Schaltmittel auf programmierbaren Schaltkreisen (FPGAs) unterzubringen. Alle diese Einrichtungen können in den Ressourcenvorrat einbezogen und durch Anwenden der erfindungsgemäßen Verfahrensschritte angesprochen werden.

Die einzelne Ressource kann sein:

a) eine Schaltungsanordnung mit fester Funktion,
b) eine Schaltungsanordnung mit einstellbarer Funktion,
c) eine programmgesteuerte Schaltungsanordung (Steuerung durch übliche Maschinenbefehle oder durch Mikrobefehle),
d) ein entsprechend aufgeteilter Speicherbereich, ergänzt um Programmsteuerangaben (Emulation),
e) ein entsprechend aufgeteilter Speicherbereich, ergänzt um eine Beschreibung einer Schaltungsanordnung, die die jeweiligen Informationswandlungen ausführen kann (z. B. in Form von Netzlisten oder Booleschen Gleichungen). Diese Schaltungsbeschreibung kann auf bekannte Weise simuliert werden. Alternativ dazu kann die betreffende Schaltung-entsprechende programmierbare Schaltkreise (z. B. FPGAs) vorausgesetzt – durch Programmierung tatsächlich erzeugt werden (Schaltungssynthese).

Das erfindungsgemäße Verfahren kann durchgeführt werden:

a) mit herkömmlichen Universalrechnern,
b) mit abgewandelten Universalrechnern (geänderter Befehlsdecoder, geänderter Registersatz, andere Mikroprogramme usw.),
c) mit speziellen, von Grund auf für die Durchführung des Verfahrens ausgebildete Rechenanlagen,
d) mit programmierbaren Schaltkreisen (z. B. FPGAs).

Durch Anwendung des erfindungsgemäßen Verfahrens kann der den Verarbeitungsabläufen inhärente Parallelismus in dem Maße ausgenutzt werden, in dem tatsächlich Hardware verfügbar ist. Schaltmittel zur Konflikterkennung, Ablaufwiederholung usw. sind nicht erforderlich. Speichermittel und Verarbeitungsschaltungen können direkt miteinander verbunden werden (im Vergleich zu den Registersätzen der bekannten Hochleistungs prozessoren sind weniger Zugriffswege erforderlich, und die Adreßdecodierung ist einfacher). Verarbeitungsschaltungen können in Speicheranordnungen eingebettet werden (Ressourcenzellen, aktive Speicheranordnungen), so daß sich kürzeste Zugriffswege ergeben. Diese Vereinfachungen der Hardware bieten die Möglichkeit, die Taktfrequenz zu erhöhen, Pipeline-Stufe einzusparen (Verkürzung der Latenzzeiten der Operationsausführung) und auf einer gegebenen Schaltkreisfläche mehr bzw. leistungsfähigere Verarbeitungsschaltungen anzuordnen. Die perspektivischen Möglichkeiten, die die Schaltungsintegration bietet (z. B. einige hundert Millionen Transistoren auf einem Schaltkreis) können in weitem Umfang ausgenutzt werden. Da der inhärente Parallelismus unmittelbar aus der Programmierabsicht heraus (in statu nascendi) erkannt wird, ist es möglich, ggf. auch hunderte Verarbeitungswerke gleichzeitig einzusetzen, um den Ablauf des einzelnen Programms zu beschleunigen. Je nach den Kosten- und Leistungszielen und nach dem Stand der Technologie sind Hard- und Software gegeneinander austauschbar (z. B. ein Unterprogramm gegen eine spezielle Verarbeitungseinrichtung und umgekehrt). Entsprechende Programme sind somit invariant gegen die technologische Entwicklung; sie können jeden Fortschritt der Schaltungsintegration ohne weiteres ausnutzen. Auf programmierbaren Schaltkreisen sind Systeme realisierbar, die eine im Grunde beliebige Kombinationen von Hard- und Software darstellen. Anwendungspraktisch wichtige Zusatzfunktionen, z. B. die Unterstützung des Fehlersuchens (Debugging), der Systemverwaltung, der Datenverschlüsselung usw., die herkömmlicherweise zusätzliche Programmabläufe (Geschwindigkeitsverlust) oder spezielle Hardware (Aufwand) erfordern, können in die Ressourcen organisch eingebaut werden (der Mehraufwand ist geringer, da sich aufgrund der unmittelbaren Verbindungen mehr Gelegenheiten zur Schaltungsoptimierung bieten, und die Systemleistung wird nicht beeinträchtigt). Des weiteren kann man zusätzliche Ressourcen aus dem allgemeinen Ressourcenvorrat entnehmen, um entsprechende Einrichtungen bedarfsweise aufzubauen (wird die betreffende Funktion – z. B. zur Unterstützung des Fehlersuchens – nicht mehr benötigt, so stehen die betreffenden Ressourcen wieder zur allgemeinen Nutzung zur Verfügung).

Im folgenden sollen Einzelheiten des Verfahrens, Ausführungsbeispiele von Vorrichtungen zu dessen Durchführung sowie beispielhafte Varianten der Auslegung entsprechender Anweisungsangaben näher beschrieben werden. In der zugehörigen Zeichnung zeigen
1 eine allgemeine Darstellung von Hardware auf der Register-Transfer-Ebene (Register Transfer Level RTL),
2 Register-Transfer-Darstellungen verschiedenartiger Ressourcen,
3 zwei Anordnungen mehrerer Ressourcen,
4 Ressourcen, die an einen Speicher mit wahlfreiem Zugriff (RAM) angeschlossen sind,
5 die alternative Realisierung von Ressourcen als Hardware und als Software,
6 die Nutzung einer Ressource nach dem erfindungsgemäßen Verfahren,
7 eine Verkettung von Ressourcen gemäß dem Datenflußschema der jeweiligen Informationswandlungen,
8 Ressourcen mit durchnumerierten Parametern,
9 eine Ressourcenanordnung, die einem beispielhaften Verarbeitungsvorgang zugrunde liegt,
10 bis 12 Vorrichtungen zur Durchführung des erfindungsgemäßen Verfahrens,
13 eine Verarbeitungsressource mit Systemanschlußsteuerung,
14 eine einfache Plattformstruktur,
15 eine Ressourcenanordnung, in der eine Verzweigung ausgeführt wird,
16 und 17 zur Unterstützung von Verzweigungsvorgängen ausgebildete Plattformstrukturen,
18 und 19 Verzweigungsabläufe in typischen Programmkonstrukten,
20 bis 23 weitergebildete Plattformstrukturen,
24 eine Übersicht über die Parameter einer Plattform,
25 bis 28 typische Prinzipien der Speicheradressierung,
29 ein System mit zwei Speichereinrichtungen,
30 Signalflüsse des Befehlslesens,
31 und 32 Ausführungen von Verarbeitungsressourcen,
33 eine Verarbeitungsressource mit vor- und nachgeschalteten Adressierungsressourcen,
34 bis 39 verschiedene Ausführungen von Adressierungs- und Iteratorressourcen,
40 bis 48 verschiedene Ausführungen von Verarbeitungsressourcen,
49 bis 58 Einzelheiten zur Verkettung von Ressourcen,
59 bis 70 mit Speichermitteln verbundene und in Speichermittel eingebaute Ressourcen,
71 bis 79 in Schaltkreise – vor allem in FPGAs – eingebaute Ressourcen,
80 bis 85 Beispiele von Tabellenstrukturen zur Ressourcenverwaltung,
86 bis 96 Einzelheiten der Ressourcenadressierung,
97 bis 101 Varianten der Instrumentierung,
102 bis 105 Einzelheiten der Gestaltung von Bytecodes,
106 eine beispielhafte Speicherbelegung,
107 die Parameteradressierung im Speicher
108 und 109 dem Stand der Technik entsprechende Hochleistungssysteme,
110 und 111 Blockschaltbilder von Superskalar-Hochleistungsprozessoren,
112 die Abwandlung eines herkömmlichen Superskalarprozessors zur Durchführung des erfindungsgemäßen Verfahrens.
Zunächst werden charakeristische Begriffe und Zusammenhänge erläutert. Dann wird das Verfahren im einzelnen beschrieben. Die weitere Beschreibung betrifft Vorrichtungen zur Durchführung des Verfahrens, Varianten der Gestaltung von Anweisungsangaben sowie Erläuterungen zu typischen Anwendungsgebieten.
Anhand der 1 bis 7 wird der Begriff der Ressource – im erfindungsgemäßen Sinne – näher erläutert. Zudem wird gezeigt, wie man solche Ressourcen einsetzen kann, um elementare Aufgaben der Informationsverarbeitung (Informationswandlungen) auszuführen.
1 veranschaulicht den Begriff der Register-Transfer-Struktur bzw. Register-Transfer-Ebene (Register Transfer Level RTL). Jede digitale informationsverarbeitende Einrichtung läßt sich auf Speichermittel (Flipflops, Register, Speicherzellen) und kombinatorische Schaltungen (Funktionszuordner) zurückführen; sie ist durch Speichermittel RG und durch Boolesche Gleichungen, die die Wirkungsweise der Funktionszuordner FZ beschreiben, in funktioneller Hinsicht vollständig bestimmt. Im folgenden können deshalb die Ressourcen ohne Beschränkung der Allgemeinheit durch einfache Register-Transfer-Darstellungen (RTL-Darstellungen) veranschaulicht werden. Die Booleschen Gleichungen, die die in der Informatik üblichen grundlegenden Informationswandlungen beschreiben, gehören zum allgemeinen Fachwissen.
2 zeigt Register-Transfer-Darstellungen einfacher Ressourcen. Sie bestehen aus Registern, die die Operanden und die Ergebnisse aufnehmen, sowie aus zwischengeordneten kombinatorischen Schaltungen (Funktionszuordnern). Elementare Ressourcen (2a) bilden beispielsweise aus zwei Operanden (A, B) ein einziges Ergebnis (X): X := A OP B bzw. X := OP (A, B)
Die meisten Verarbeitungsbefehle der typischen Universalrechner entsprechen diesem Schema (die Unterschiede liegen vor allem in der Art und Weise, wie die Operanden bereitgestellt werden und wie das Ergebnis zugewiesen wird). Die üblichen Rechenwerke und Arithmetik-Logik-Einheiten (ALUs) können als Beispiele solcher elementaren Ressourcen angesehen werden.
Universalrechner kennen nur wenige elementare Datentypen, z. B. ganze Binärzahlen, Gleitkommazahlen, Zeichen usw., wobei zumeist mehrere Formate unterstützt werden (z. B. 16, 32 und 64 Bits). Ein Rechenwerk verarbeitet üblicherweise nur Daten eines bestimmten Typs (z. B. ganze Binärzahlen oder Gleitkommazahlen). Bei elementaren Verknüpfungen haben Operanden und Ergebnis jeweils das gleiche Format.
Erfindungsgemäße Ressourcen haben keine solchen Einschränkungen. Eine Ressource kann aus beliebig vielen Operanden beliebig viele Ergebnisse bilden, wobei Operanden und Ergebnisse beliebigen Datentypen und -formaten entsprechen dürfen (2b, c). Es gibt auch keine Beschränkung auf elementare Datentypen. Die Datentypen dürfen vielmehr beliebig komplex sein (Bit- und Zeichenketten, Felder (Arrays), heterogene Strukturen (Records) usw.).
Der typische herkömmliche Universalrechner führt einen Befehl zu einer Zeit aus (Einzelprozessor). Hierzu genügt eine einzige Verarbeitungsressource. Es liegt nahe, durch Anordnung mehrerer Verarbeitungsressourcen die Verarbeitungsleistung zu steigern. 3 zeigt zwei Beispiele. Mehrere Ressourcen, die voneineinander unabhängig sind (3a), versprechen größtmögliche Vielseitigkeit. Es bleibt aber das Problem, sie mit Operanden (Parametern) zu versorgen und die Ergebnisse abzutransportieren. Eine Lösung besteht darin, die Ressourcen gemäß den am häufigsten vorkommenden Datenflüssen so miteinander zu verbinden, daß Ergebnisse unmittelbar zu Operanden anderer Ressourcen werden können (Verkettung; 3b).
4 veranschaulicht eine alternative Auslegung. Hierbei sind die Ressourcen an einen Speicher mit wahlfreien Zugriff (RAM) angeschlossen. Der einzelne Verarbeitungsablauf unterteilt sich in drei Zeitabschnitte:

1. Transport der Operanden zu den Ressourcen,
2. Verarbeitung innerhalb der Ressourcen (in allen gleichzeitig),
3. Transport der Ergebnisse in den Speicher.

5 veranschaulicht, daß Ressourcen sowohl mit Hardware als auch mit Software realisiert werden können. Den Operanden- und Ergebnisregistern der Hardware (5a) entsprechen Speicherbereiche mit Speicherzellen für die Parameter und Ergebnisse (5b), den kombinatorischen Netwerken (Funktionszuordnern) entsprechen Programme, die die jeweiligen Informationswandlungen ausführen (5c). Die Alternative besteht darin, die Beschrei bung einer Schaltungsanordnung zu speichern, die die jeweiligen Informationswandlungen ausführen kann (5d). Um die Operationen der Ressourcen softwareseitig nachzubilden (Emulation, Simulation), sind oft zusätzliche Arbeitsbereiche erforderlich (vgl. 5b).
Es gibt mehrere Möglichkeiten, die auszuführenden Informationswandlungen zu codieren:

a) übliche Maschinenprogramme (Emulation),
b) Mikroprogramme (Emulation),
c) Nutzung des erfindungsgemäßen Verfahrens. Um die Wirkung der betreffenden Ressource zu erbringen, wird eine Anordung aus anderen Ressourcen aufgebaut, mit Parametern versorgt usw. (wie nachfolgend im einzelnen beschrieben). Eine komplexe Ressource kann somit durch eine Konfiguration aus einfacheren Ressourcen nachgebildet werden (Rekursion). Alternativ dazu ist es möglich, entsprechende komplexe Ressourcen anzufordern und so einzurichten, daß sie die jeweiligen Informationswandlungen ausführen können.
d) Beschreibung einer Schaltungsanordnung, die die jeweiligen Informationswandlungen ausführt (z. B. in Form einer Netzliste). Auf dieser Grundlage ist es möglich, die jeweilige Hardware zu erzeugen (z. B. auf einem programmierbaren Schaltkreis) oder deren Wirkungsweise nachzubilden (Schaltungssimulation).
e) Darstellung der Booleschen Gleichungen, die die jeweiligen Informationswandlungen beschreiben. Auf dieser Grundlage ist es möglich, eine entsprechende Hardware zu erzeugen (Schaltungssynthese) oder die Booleschen Gleichungen rechentechnisch auszuwerten (Simulation auf Register-Transfer-Ebene).

Das erfindungsgemäße Verfahren verwendet eine beliebige Anzahl beliebiger Ressourcen. 6 veranschaulicht, wie eine Ressource gemäß diesem Verfahren genutzt wird. Im Beispiel werden folgende Verfahrensschritte durchlaufen:

1. Ressource anfordern bzw. auswählen,
2. mit Parametern (Operanden) versorgen,
3. Operation ausführen (Hardware aktivieren oder Programm laufen lassen),
4. Ergebnis abtransportieren (zuweisen),
5. Ressource wieder zurück- bzw. freigeben.

Funktionseinheiten der Hardware können zu komplexeren Anordnungen zusammengeschaltet werden. Eine solche (spezielle) Hardware entspricht dem Datenflußschema der jeweiligen Informationswandlungen. 7 zeigt ein Beispiel (die Nutzung dieser Anordnung wird weiter unten beschrieben). Das erfindungsgemäße Verfahren bietet die Möglichkeit, Ressourcen zu solchen Datenflußschemata zu verbinden (im folgenden: zu verketten) und die Verbindungen (Verkettung) wieder zu trennen.
Die erfindungsgemäßen Verfahrensschritte werden durch gespeicherte Anweisungsangaben gesteuert. Anweisungsangaben, die eigens zur Steuerung der erfindungsgemäßen Verfahrensschritte ausgebildet sind, werden im folgenden als Operatoren bezeichnet. Die Verfahrensschritte werden anhand der zugehörigen Operatoren erklärt:

1. Ressourcen auswählen: s-Operator (select),
2. Verbindungen zwischen Ressourcen einrichten (Verkettung): c-Operator (connect),
3. mit Parametern versorgen: p-Operator (parameter),
4. Informationsverarbeitungsvorgänge (Operationen) auslösen: y-Operator (yield),
5. Daten zwischen Ressourcen transportieren: 1-Operator (link),
6. Ergebnisse zuweisen: a-Operator (assign),
7. nicht mehr benötigte Verbindungen (Verkettungen) trennen: d-Operator (disconnect),
8. Ressourcen wieder zurückgeben (freigeben): r-Operator (release).

Es gibt mehrere grundsätzliche Varianten des Verfahrens:

a) wenn die Ressourcen die Verkettung überhaupt nicht unterstützen, entfallen die Schritte 2 und 7. Der Parametertransport muß dann auschließlich mit p-,1- und a-Operatoren durchgeführt werden, die Operationsauslösung ausschließlich mit y-Operatoren.
b) wenn nicht alle Ressourcen eine unbeschränkte Verkettung unterstützen, können keine beliebigen Datenflußschemata aufgebaut werden. In manchen Fällen sind dann die Verkettungsvorkehrungen nicht nutzbar, und es muß gemäß Punkt a) verfahren werden.
c) wenn die Ressourcen die Eingangsverkettung nicht unterstützen (wird weiter unten näher beschrieben), so können Parameter auch über Verbindungen transportiert werden, die mit c-Operatoren aufgebaut wurden (Verkettung). Zur Operationsauslösung sind jedoch stets entsprechende y-Operatoren erforderlich.
d) wenn die Ressourcen die Eingangsverkettung unterstützen, ist es möglich, die jeweiligen Operationen automatisch auszulösen (also ohne y-Operator). Eine solche Ressource beginnt – falls entsprechend eingerichtet – dann mit der Operationsausführung, wenn alle Operanden gültig sind, ganz gleich, auf welche Weise sie angeliefert wurden (p-Operator, l-Operator, Verkettung).

In der Praxis braucht man oftmals zusätzliche, ergänzende Angaben, z. B. zur Unterstützung von Compilern, zur Systemverwaltung usw. Um derartige Angaben in die hier verwendete Notation einfügen zu können, werden folgende ergänzende Operatoren eingeführt:

1. Hinweise: h-Operator,
2. metasprachliche Funktionen und Angaben: m-Operator,
3. Verwaltungs- und Hilfsfunktionen: u-Operator (utility).

Hinweise (h-Operatoren) können u. a. veranlassen, daß Variable oder Programmstücke vorbeugend in Caches eingetragen werden, so daß sie dann, wenn sie benötigt werden, mit hoher Wahrscheinlichkeit schon bereitstehen. Dieses Prinzip gehört zum Stand der Technik. Es muß deshalb nicht näher beschrieben werden. Weitere h-Operatoren können sinngemäß vorgesehen werden, um einen künftigen Bedarf an bestimmten Ressourcen oder an bestimmten Konfigurationen verbundener (verketteter) Ressourcen anzuzeigen. Derartige Angaben können u. a. vorteilhaft ausgenutzt werden, um die Entnahme von Ressourcen aus dem Ressourcenvorrat (s-Operatoren) zu optimieren (indem beispielsweise dem anfordernden Programm Ressourcen zugeteilt werden, die – für die nachfolgende Verkettung – in besonders günstiger Lage (auf dem Schaltkreis) angeordnet sind).
Metasprachliche Funktionen und Angaben (m-Operatoren) betreffen u. a. das Einstellen von Konfigurationen und die bedingte Ausführung von Verfahrensschritten. Solche Operatoren können näherungsweise mit den Präprozessor- und Compileranweisungen der üblichen Programmiersprachen verglichen werden. Sie können aber nicht nur zur Compilierzeit, sondern auch zur Laufzeit wirksam werden. Eine typischer Einsatzfall: in Abhängigkeit davon, welche Ressourcentypen zur Verfügung stehen, wird einer von mehreren Abläufen gewählt, um eine bestimmte Programmierabsicht zu verwirklichen. Übliche bedingte Verzweigungen hängen von Verarbeitungsergebnissen, Eingangsbelegungen, Operanden usw. ab. Metasprachliche bedingte Verzweigungen hängen u. a. von der Art und Anzahl der vorhandenen Ressourcen ab. m-Operatoren können auf die Tabellenstrukturen der Ressourcenverwaltung (wie sie weiter unten anhand der 80 bis 85 erläutert werden) zugreifen und deren Inhalt verändern.
Verwaltungs- und Hilfsfunktionen (u-Operatoren) erledigen allgemeine organisatorische und unterstützende Aufgaben. All jene Funktionen, die während der Programmausführung erforderlich sind, sich aber – im Rahmen der jeweiligen Ressourcenausstattung – nicht in das Schema der Operatoren s, c, p, y, l, a, d, r, h, m einordnen lassen, werden mit u-Operatoren erledigt.
Die Funktionen, die mit h-, m- und u-Operatoren codiert werden, können von Einrichtungen erbracht werden, die außerhalb des Ressourcenvorrates stehen. Das kann z. B. ein üblicher Universalrechner sein, der den Vorrat der Verarbeitungsressourcen verwaltet und steuert. Solche Einrichtungen werden hier allgemein als Plattform bezeichnet.
Alternativ dazu ist es möglich, für viele dieser Funktionen eigens weitere Ressourcen vorzusehen oder aus vorhandenen Ressourcen entsprechende Anordnungen ad hoc aufzubauen, z. B. Ressourcen, die vorbeugend Caches auffüllen, andere Ressourcen reservieren oder Ressourcentabellen verwalten. Im Grunde kann die – außerhalb des Ressourcenvorrates stehende – Plattform auf einfachste Funktionen des Befehlslesens, der Initialisierung usw. beschränkt bleiben. Alle weiteren Funktionen lassen sich auf die Nutzung eines hinreichend ausgestatteten Ressourcenvorrates durch entsprechendes Anwenden der erfindungsgemäßen Verfahrensschritte zurückführen (Rekursion). Deshalb ist eine genauere Beschreibung der h- und m-Operatoren nicht erforderlich. u-Operatoren werden dann näher erläutert, wenn dies zum Verständnis der jeweiligen Einzelheiten nötig ist.
Die Daten, mit denen die Ressourcen arbeiten, heißen hier allgemein „Parameter". Eingangsseitige Parameter werden auch als Operanden, ausgangsseitige als Ergebnisse bezeichnet. Es gibt folgende Arten von Parametern:

1. Eingänge (Operanden; IN-Typ),
2. Ausgänge (Ergebnisse; OUT-Typ),
3. Ein- und Ausgänge (INOUT-Typ).

Die Parameterübergabe erfolgt grundsätzlich als Wert (by Value). Ist das nicht ohne weiteres möglich, sind zusätzliche Ressourcen vorzusehen, die die Werte heranschaffen und abtransportieren.
Erfindungsgemäße Verarbeitungsabläufe können folgendermaßen dargestellt werden:

1. umgangssprachlich. Das erfordert keine besonderen Festlegungen, ist aber weitschweifig und nicht immer eindeutig.
2. als Textcode. Formalisierte Notation auf Grundlage von Zeichenketten.
3. Bytecode. Kompakte, binär codierte Darstellungen; aus dem Textcode abgeleitet.
4. Maschinencode. Binär. Maschinenspezifisch.

Die nachfolgenden Beispiele werden in einem Textcode beschrieben, der folgende Merkmale aufweist:

a) Kommentare werden mit – eingeleitet (vgl. Programmiersprache Ada).
b) Parameter werden durchnumeriert (Ordinalzahlen): zuerst die Eingänge, dann die Ein- und Ausgänge, dann die Ausgänge. 8 zeigt zwei Beispiele.
c) Durchnumerierung der Ressourcen: die folgenden Beispiele beziehen sich auf eine fortlaufende Durchnumerierung (1, 2 usw.) gemäß der Reihenfolge in den s-Operatoren. Die hierbei vergebenen laufenden Nummern (Ordinalzahlen) bleiben erhalten, auch wenn zwischenzeitlich Ressourcen mit niedrigeren Nummern zurückgegeben wurden (r-Operator). Anstelle der Ordinalzahlen können symbolische Namen (Eigennamen) angegeben werden.
d) Angabe von Ressourcentypen, Ressourcen und Parametern: durch Ordinalzahlen oder Eigennamen. Syntax der Zuordnung eines Eigennamens: Ordinalzahl : Eigenname.
e) Darstellung einer Zuweisung: => (Pfeil symbolisiert Übertragungsrichtung).
f) Bezeichnung eines Parameters einer bestimmten Ressource: Ressource. Parameter (Punkt zwischen Ressourcen- und Parameterangabe).
g) Leerzeichen können beliebig eingefügt oder weggelassen werden.
h) Kennzeichnung von Varianten der Operatoren: durch Zusatzangaben, die durch ein Unterstreichungssymbol (Underscore) abgesetzt sind (z. B. s_a, p_imm oder u_rs2).

Die hier verwendete Notation ist an sich zur maschineninternen Nutzung gedacht. Deshalb wird auf Anwendungsfreundlichkeit usw. kein Wert gelegt – es geht nicht um eine neue Programmiersprache für Anwendungsprogrammierer. Der Textcode soll vielmehr kurz sein, um entsprechende Darstellungen programmtechnisch effektiv auswerten zu können (Durchmusterung, Analyse, Wandlung, Übersetzung usw.). Zunächst werden die Operatoren – und damit die Verfahrensschritte – einzeln erläutert.

1. Ressourcen auswählen: s-Operator: s(1. Ressourcentyp, 2. Ressourcentyp usw.). Mit dem s-Operator werden Ressourcen angefordert. Bei allgemein üblichen (generischen) Ressourcen wird der jeweilige Typ angegeben, bei speziellen Ressourcen der jeweilige Bezeichner (Eigenname). Im allgemeinen Fall kommen als Bezeichner auch Internet-Adressen usw. in Betracht. Die angeforderten Ressourcen werden fortlaufend durchnumeriert. Nachfolgende Operatoren beziehen sich dann auf die so vergebenen Ordinalzahlen bzw. auf die zugehörigen Eigennamen. In einer weiteren Auslegung können die s-Operatoren auch explizite Angaben der Bezeichner, Ordinalzahlen oder Adressen enthalten, die den angeforderten Ressourcen zugewiesen werden (Operatorvariante s_a): s_a (1. Ressourcentyp => 1. Ressourcennummer, 2. Ressourcentyp => 2. Ressourcennummer usw.). s-Operatoren können – in Abhängigkeit von der jeweiligen Ressourcenanordnung – folgendermaßen wirken:. a) eine entsprechende Hardware-Ressource wird reserviert, eingerichtet und zugeordnet, b) entsprechender Speicherplatz wird reserviert, eingerichtet und zugeordnet. Ggf. werden die jeweils erforderlichen Steuerangaben geladen (Programme, Mikroprogramme, Netzlisten, Boolesche Gleichungen usw.). c) die angeforderte Ressource wird aus anderen Ressourcen aufgebaut (Rekursion), d) es wird eine entsprechende Hardware erzeugt, z. B. durch Programmieren von Zellen und Verbindungen eines programmierbaren Logikschaltkreises. Eine Ressource einrichten heißt, beispielsweise Fest- und Anfangswerte einzutragen, Zugriffsbreiten einzustellen, Funktionscodes und andere Steuerangaben zu laden usw. Eine Ressource zuordnen heißt, sie in die Verwaltung der ausgewählten Ressourcen einzubeziehen, so daß sie von Operatoren unter einer laufenden Nummer (Ordinalzahl) oder über Adreßangaben angesprochen werden kann. Einzelheiten hierzu werden weiter unten anhand der 80 bis 85 näher erläutert.
2. Verbindungen zwischen Ressourcen einrichten (Verkettung): c-Operator c(1. Quell-Ressource. 1. Ergebnis => 1. Ziel-Ressource. 1. Parameter, 2. Quell-Ressource. 2. Ergebnis => 2. Ziel-Ressource. 2. Parameter usw.) Die einfachste Verkettung verbindet einen Ausgang (Ergebnisparameter) der Quell-Ressource mit einem Eingang (Operandenparameter) der Ziel-Ressource. Des weiteren ist es möglich, Eingänge untereinander zu verketten (Eingangsverkettung). Die Wirkung einer solchen Verkettung entspricht einer Parallelschaltung der betreffenden Eingänge. Anwendung: um den jeweiligen Parameter mehreren Ressourcen gleichzeitig zuzuführen. Der c-Operator trägt Verkettungssteuerangaben in die jeweiligen Ressourcen ein. In manchen Implementierungen (z. B. in FPGAs) kann er veranlassen, daß die entsprechenden physischen Verbindungen hergestellt werden (z. B. durch Programmieren des Schaltkreises). Die Ressourcen sind zu verketten, bevor die betreffenden Verarbeitungsfunktionen ausgelöst werden (y-Operator).
3. Ressourcen mit Parametern versorgen: p-Operator: p(1. Variable => Ressource. Parameter, 2. Variable => Ressource. Parameter usw.) Mit p-Operatoren wird angegeben, welche Variable in welche Parameterposition welcher Ressource transportiert wird. Die Variablen werden durch Namen, Ordinalzahlen oder Adressen bezeichnet. Anstelle von Variablen können auch Direktwerte angegeben werden (Operatorvariante p_imm): p_imm (1. Direktwert => Ressource. Parameter, 2. Direktwert => Ressource. Parameter usw.) In Ressourcen, die die Eingangsverkettung unterstützen, können p-Operatoren auch die Operationsausführung auslösen (Verarbeitung beginnt, wenn alle Operanden gültig sind).
4. Informationsverarbeitungsvorgänge (Operationen) ausführen: y-Operator: y(1. Ressource, 2. Ressource usw.) Der y-Operator löst die Verarbeitungsvorgänge in den angegebenen Ressourcen aus. Was in den Ressourcen jeweils geschieht, ergibt sich entweder direkt aus der Art der Ressource (falls diese nur eine einzige Funktion ausführen kann) oder aus Parametern (Funktionscodes), die vorher einzustellen sind (z. B. mit s- oder p-Operatoren). In einer weiteren Auslegung wird der Funktionscode im y-Operator übergeben (Operatorvariante y_f): y_f(1. Funktionscode => 1. Ressource, 2. Funktionscode => 2. Ressource usw.) Diese Variante widerspricht dem Prinzip, in den Operatoren nur grundsätzliche Verfahrensschritte, nicht aber konkrete Maschinenoperationen zu codieren. Es ist eine Art pragmatische Sparlösung, die nur für maschinenbezogene Befehlscodes in Frage kommt. Eine alternative Variante der Operationsauslösung – ohne y-Operator – beruht darauf, daß die Verarbeitungsvorgänge dann gestartet werden, wenn alle erforderlichen Operanden gültig sind. Hierzu muß die betreffende Ressource die Eingangsverkettung unterstützen. Gültige Operanden können durch Verkettung, mit p-Operatoren oder mit 1-Operatoren angeliefert werden.
5. Daten zwischen Ressourcen transportieren: l-Operator: l(1. Quell-Ressource. 1. Ergebnis => 1. Ziel-Ressource. 1. Parameter, 2. Quell-Ressource. 2. Ergebnis => 2. Ziel-Ressource. 2. Parameter usw.) Der l-Operator bewirkt den Transport von Parametern zwischen verschiedenen Ressourcen (jeweils vom Ausgang der Quell-Ressource zum Eingang der Ziel-Ressource). In Ressourcen, die die Eingangsverkettung unterstützen, können l-Operatoren auch die Operationsausführung auslösen (Verarbeitung beginnt, wenn alle Operanden gültig sind).
6. Ergebnisse zuweisen: a-Operator: a(1. Ressource. 1. Ergebnis => 1. Ergebnisvariable, 2. Ressource. 2. Ergebnis => 2. Ergebnisvariable usw.) Der a-Operator weist die Inhalte der angegebenen Ergebnispositionen der angegebenen Ressourcen den angegebenen Variablen zu. Die Variablen werden durch Namen, Ordinalzahlen oder Adressen bezeichnet.
7. nicht mehr benötigte Verbindungen (Verkettungen) trennen: d-Operator: d(1. Quell-Ressource. 1. Ergebnis => 1. Ziel-Ressource. 1. Parameter, 2. Quell-Ressource. 2. Ergebnis => 2. Ziel-Ressource. 2. Parameter usw.) Der d-Operator trennt bestehende Verkettungen. In manchen Implementierungen (z. B. in FPGAs) kann er veranlassen, daß die entsprechenden physischen Verbindungen aufgelöst werden (z. B. durch Umprogrammieren). Anschließend können die Ressourcen anderweitig verkettet oder auch einzeln betrieben werden.
8. Ressourcen wieder zurückgeben (freigeben): r-Operator: r(1. Ressource, 2. Ressource usw.) Die angegebenen Ressourcen werden an den Ressourcenvorrat zurück- bzw. freigegeben. Sie stehen somit für andere Verarbeitungsaufgaben zur Verfügung.

Das folgende Beispiel zeigt, wie eine Programmierabsicht auf Grundlage des erfindungsgemäßen Verfahrens realisiert werden kann. 9 veranschaulicht die Ressourcenanordnung aus zwei Addierwerken (ADD) und einem Multiplizierwerk (MULT). Zur Verkettung vgl. 7. Die laufenden Nummern (Ordinalzahlen) der Ressourcen: erstes Addierwerk = 1, zweites Addierwerk = 2, Multiplizierwerk = 3. Die laufenden Nummern (Ordinalzahlen) der Parameter einer Ressource: Eingänge (Operanden) = 1 und 2, Ergebnis = 3.

a) Programmierabsicht: X := (A + B)·(C + D).
b) nutzbare Ressourcentypen: ADD, MULT.

Ausführliche Notation (jeder Vorgang einzeln):

s (ADD, ADD, MULT)
p(A => 1.1)
p(B => 12)
p(C => 2.1)
p(D => 2.2)
y(1)
y(2)
l(1.3 => 3.1)
l(2.3 => 32)
r(1, 2)
y(3)
a(3.3 => X)
r(3)

Verkürzte Notation:

s (ADD, ADD, MULT)
p(A =>1.1, B => 12, C => 2.1, D => 22)
y(1, 2)
l(1.3 => 3.1, 2.3 => 32)
r(1, 2)
y(3)
a(3.3 => X)
r(3)

Als Datenflußschema (Verkettung):

s (ADD, ADD, MULT)
c(1.3 => 3.1, 2.3 => 3.2)
p(A => 1.1, B => 1.2, C => 2.1, D => 2.2)
y(1, 2, 3) – allgemeine Erlaubnis; startet die verketteten Ressourcen
a(3.3 => X)
r(1, 2, 3)

Um das Verfahren praktisch durchzuführen, müssen die Operatoren in gespeicherter Form als Maschinencode vorliegen. Es gibt mehrere Alternativen der Auslegung von Maschinencodes:

a) Operatoren als Bytecode (variable Länge),
b) fest formatierte Maschinenbefehle, die den erfindungsgemäßen Operatoren entsprechen (1 Befehl = 1 Operator),
c) Anweisungen, die ganz elementare Abläufe auslösen (z. B. Informationstransporte). Die Wirkungen der erfindungsgemäßen Operatoren werden mit Folgen entsprechender Anweisungen nachgebildet (vgl. die herkömmliche Mikroprogrammsteuerung).
d) Steuerworte, die Einzelbitangaben sowie Direktwert-, Adreß- und Anweisungsfelder enthalten. Solche Steuerworte dienen vor allem dazu, eine größere Zahl (ggf. alle) Ressourcen auf einmal mit Parametern zu versorgen, zu aktivieren usw. (vgl. die herkömmlichen Maschinen mit langem Befehlswort (VLIW)).
e) Befehle, die den Maschinenbefehlen der herkömmlichen Architekturen ähnlich sind,
f) Umsetzung der erfindungsgemäßen Operatoren in Folgen herkömmlicher Maschinenbefehle bzw. in entsprechende Funktionsaufrufe (Compilierung).

Weiter unten werden anhand der 88, 90 und 102 bis 105 sowie der Tabellen 5 bis 30 verschiedene Beispiele beschrieben.
Das Verfahren hat folgende charakteristische Vorteile:

1. es kann eine letzten Endes beliebige Anzahl von Ressourcen angesprochen werden (keine Begrenzung der Ressourcenanzahl, wie sie beispielsweise in den sog. VLIW-Architekturen gegeben ist),
2. die Ressourcenbereitstellung und -freigabe ist bis in die Einzelheiten programmseitig steuerbar; es ist möglich, aus den gegebenen Ressourcen für jede aktuelle Verarbeitungsaufgabe ad hoc eine Art virtuelle Spezialmaschine zu konfigurieren und am Ende wieder abzubauen,
3. sind solche Strukturen erst einmal aufgebaut, so ist der programmseitige Verwaltungsaufwand (Overhead) deutlich geringer als in herkömmlichen Maschinen (kein Auf- und Abbau von Stack Frames, kein Speichern und Wieder-Lesen von Zwischenwerten),
4. im Gegensatz zu herkömmlichen Operationsbefehlen ist die Operationsauswahl (s-Operator) von der Operationsauslösung (y-Operator) getrennt. Jede Ressource weiß somit von vornherein, wofür die übertragenen Parameter bestimmt sind. Das kann gelegentlich zur Optimierung der Hardware ausgenutzt werden. Die Auslösungsangaben sind typischerweise kürzer als die Auswahlangaben. Das ist dann von Vorteil (Codeverkürzung), wenn gleiche Funktionen immer wieder oder wenn viele Funktionen auf einmal auszulösen sind. Bei gegebener Befehlslänge kann man mehr Funktionen auf einmal auslösen, als dies üblicherweise möglich ist. Beispiel: eine der bekann ten Architekturen für Hochleistungsprozessoren hat Befehlsworte von 128 Bits Länge, die drei Befehle aufnehmen. Somit können bis zu drei Operationen gleichzeitig ausgelöst werden. Eine erfindungsgemäße Abwandlung dieses Formates könnte beispielsweise einen Operationscode von 8 Bits enthalten. In y-Operatoren stehen die verbleibenden 120 Bits zur Funktionsauslösung zur Verfügung. Je nach Gestaltung des Befehlsformates können beispielsweise ausgelöst werden: • wenn jeder Ressource ein Bit zugeordnet ist: bis zu 120 Verarbeitungsvorgänge, • wenn die Ressourcenadresse 6 Bits lang ist: bis zu 20 Verarbeitungsvorgänge, • wenn die Ressourcenadresse 12 Bits lang ist: bis zu 10 Verarbeitungsvorgänge.

Anhand der 10 bis 13 sollen im folgenden Vorrichtungen zur Durchführung des erfindungsgemäßen Verfahrens näher beschrieben werden. Solche Vorrichtungen enthalten Speichermittel, Verarbeitungsschaltungen und Steuerschaltungen. Speichermittel, Verarbeitungsschaltungen und Steuerschaltungen werden als Ressourcen aufgefaßt. Wie die einzelnen Ressourcen aufgebaut sind, ist im Grunde gleichgültig. Um die jeweiligen Verarbeitungsaufgaben auszuführen, sind die Ressourcen in aufeinanderfolgenden Zeitschritten auszuwählen, mit Parametern zu versorgen, zu aktivieren, wieder freizugeben usw. Diese Vorgänge werden von gespeicherten Anweisungen (dem Maschinencode) gesteuert. Das Verfahren kann – mit entsprechenden Programmen – in herkömmlichen Rechenanlagen (Computern, Prozessoren) ausgeführt werden. Die Vorteile kommen aber erst dann in vollem Maße zur Wirkung, wenn die ausführende Hardware durchgehend auf das auszuführende Verfahren abgestimmt ist. Entsprechende Einrichtungen (Systeme) umfassen:

a) Plattformanordnungen,
b) Verarbeitungsressourcen,
c) Speichermittel und E-A-Einrichtungen.

Elementare Konfigurationen ähneln einem herkömmlichen Universalrechner. 10 zeigt eine derartige Einrichtung. Plattform 1, Speichermittel 2 und Verarbeitungsressourcen 3 sind über einen Systembus (Universalbus) 4 untereinander verbunden. An den Systembus 4 können weiterhin E-A-Einrichtungen beliebiger Art angeschlossen werden. Im Gegensatz zum herkömmlichen Universalrechner sind die Verarbeitungsressourcen aber nicht auf ein einziges Rechenwerk oder auf wenige Verarbeitungswerke beschränkt.
In einer abgewandelten Konfiguration gem. 11 sind die Speichermittel 2 an die Plattfom 1 angeschlossen. Der Systembus 4 ist in mehrere Bussysteme aufgelöst, z. B. in einen Speicherbus 5, einen Operandenbus 6 und einen Ergebnisbus 7.
Herkömmliche Bussysteme haben den Nachteil, daß zu einer Zeit nur ein Übertragungsvorgang stattfmden kann. 12 veranschaulicht eine Alternative: schnelle Punkt-zu-Punkt-Verbindungen 8, die über Koppelfelder bzw. Schaltverteiler 9 geführt sind. Punkt-zu-Punkt-Hochgeschwindigkeitsinterfaces mit Datenraten von mehreren GBits/s und hinreichend kurzen Latenzzeiten entsprechen dem Stand der Technik. Schaltverteiler ermöglichen es, beliebige Einrichtungen untereinander zu verbinden. Dabei können viele unabhängige Übertragungsvorgänge gleichzeitig stattfinden.
Kleinere Systeme können zentral gesteuert werden. Die Plattform 1 steuert hierbei alle Speicherzugriffe und Informationstransporte. Nur die y-Operatoren werden autonom in den Verarbeitungsressourcen 3 erledigt. Die Verkettung wird von der Plattform emuliert. Solche Maschinen können z. B. auf Grundlage von Bussystemen aufgebaut werden, an die alle Verarbeitungsressourcen 3 als Slaves (Targets) angeschlossen sind.
Hochleistungssysteme erfordern eine autonome Steuerung der Speicherzugriffs- und Verkettungsfunktionen. Die Plattform 1 und die Verarbeitungsressourcen 3 sind hierzu mit entsprechenden Anschlußsteuerschaltungen auszurüsten und über universelle Multimaster-Bussysteme 4, Schaltverteiler 9 o. dergl. miteinander zu verbinden. 13 zeigt eine Verarbeitungsressource 3, deren Speichermittel über einen Operandenbus 6 und einen Ergebnisbus 7 mit einer Systemanschlußsteuerung 10 verbunden sind, die ihrerseits an ein Multimaster-Bussystem 4 oder an ein entsprechendes Punkt-zu-Punkt-Interface 8 angeschlossen ist. Die hier dargestellte Verarbeitungsressource wird weiter unten anhand von 48 und Tabelle 2 näher beschrieben. Geeignete Bussysteme und Interfaces entsprechen dem Stand der Technik. Es sei beispielsweise auf die Industriestandards PCI, HyperTransport und PCI Express verwiesen. Entsprechende Anschlußsteuerungen sind als fertige Schaltungsentwürfe verfügbar; sie müssen deshalb nicht näher beschrieben werden.
Anhand der 14 bis 30 werden nachfolgend Varianten der Auslegung von Plattformen und Systemen erläutert. Die Plattform umfaßt die Ressourcen, die unbedingt notwendig sind, um den Betrieb des Systems einzuleiten und aufrecht zu erhalten. Plattformanordnungen dienen dazu, den jeweiligen Maschinencode auszuführen. Der Maschinencode besteht aus Befehlen oder Anweisungen, die den erfindungsgemäßen Operatoren direkt entsprechen oder die es ermöglichen, die Wirkungen der Operatoren nachzubilden. Es gibt verschiedene Möglichkeiten, eine Plattform aufzubauen:

a) Nutzung eines herkömmlichen Prozessors,
b) Auslegung als mikroprogrammiertes Steuerwerk,
c) Auslegung als Sammlung elementarer Ressourcen,
d) Aufbau aus universellen Verarbeitungsressourcen mit einer anfänglichen (nach dem Einschalten bzw. Rücksetzen) festen Zusammenschaltung.

Demgemäß können die Funktionen der Plattform gesteuert werden durch:

1. herkömmliche Maschinenbefehle,
2. Mikrobefehle oder Steuerworte,
3. elementare Maschinenbefehle für Verwaltungsaufgaben (Regiebefehle), z. B. Laden, Speichern, Verzweigen, Unterprogrammruf Rückkehr, Unterbrechungssteuerung,
4. Maschinenbefehle, die die Wirkungen der erfindungsgemäßen Operatoren veranlassen,
5. beliebige Kombinationen von 1. bis 4.

Erfindungsgemäße Systeme können mehrere Plattformen enthalten.
Kompliziertere Ressourcen können aus einfacheren aufgebaut werden (Rekursion), sei es durch entsprechende Verschaltung (Verkettung), sei es durch programmseitig gesteuerte Ausnutzung in entsprechend vielen aufeinanderfolgenden Verarbeitungsschritten. In diesem Sinne werden die Ressourcen durch eine Ordnungszahl gekennzeichnet:

1. Ordnungszahl 0: die Ressourcen der Plattform,
2. Ordnungszahl 1: die Ressourcen, die von der Plattform aus unmittelbar angesprochen werden können,
3. Ordnungszahl 2: Ressourcen, die aus Ressourcen der Ordnungszahlen 0 und 1 aufgebaut werden,
4. Ordnungszahl 3: Ressourcen, die aus Ressourcen der Ordnungszahlen 0, 1 und 2 aufgebaut werden usw.

Die Entsprechungen in herkömmlichen Rechnerarchitekturen:

1. Ordnungszahl 0: die allgemeinen Wirkprinzipien (Befehlslesen, Datenadressierung, Unterprogrammruf, Verzweigungen usw.),
2. Ordnungszahl 1: die Verarbeitungsbefehle,
3. Ordnungszahl 2: grundlegende Systemfunktionen, Unterprogrammbibliotheken usw.

Des weiteren ist es gelegentlich zweckmäßig, Ressourcen, die mit Verarbeitungsaufgaben beschäftigt sind, von Ressourcen zu unterscheiden, die sich mit der Verwaltung und Unterstützung anderer Ressourcen befassen. Hierzu wird der Begriff der Ebene verwendet. Ressourcen, die Verarbeitungsaufgaben ausführen, gehören zur Ebene 1, solche, die Ressourcen der Ebene 1 verwalten, zur Ebene 2 usw. In jeder Ebene kann es wiederum Ressourcen der Ordnungszahlen 0, 1, 2 usw. geben.
Alle Programmierabsichten müssen letzten Endes auf die Ausnutzung von Ressourcen der Ordnungszahlen 0 und 1 umgesetzt werden. Das kann zur Laufzeit oder zur Compilierzeit geschehen.

1. Umsetzung zur Laufzeit. Die Programmstruktur gemäß Programmierabsicht bleibt erhalten. Die für die aufeinanderfolgenden Programmschritte benötigten Ressourcen werden angefordert, genutzt und wieder freigegeben. Jeder Funktion bzw. Prozedur (in einer entsprechenden Programmiersprache formuliert) entspricht ein Unterprogramm, jedem Funktionsaufruf entspricht ein Aufruf des jeweiligen Unterprogramms. Wird ein Unterprogamm aufgerufen, so fordert es seinerseits Ressourcen an, versorgt sie mit Parametern, veranlaßt die Ausführung der Verarbeitungsfunktionen usw. Bei der Rückkehr zum rufenden Programm werden die angeforderten Ressourcen wieder freigegeben. Bezogen auf die typische Auslegung der Laufzeitsysteme üblicher Programmiersprachen veranlaßt jeder Funktionsaufruf den Aufbau und den Abbau eines Stack Frame. Dabei sind die lokalen Variablen nur zeitweise vorhanden. Sie müssen bei jedem Aufruf neu bereitgestellt werden und gehen bei der Rückkehr verloren.
2. Umsetzung zur Compilierzeit. Das Programmentwicklungssystem (z. B. ein Compiler) setzt die Programmierabsicht vollständig in Ressourcen der Ordnungszahlen 0 und 1 um. Im Extremfall werden alle Ressourcen auf einmal angefordert, auch jene, die zur Ausführung von Funktionen (Unterprogrammen) benötigt werden. Sie bleiben während der gesamten Programmlaufzeit zugeordnet. Ein Funktionsaufruf beschränkt sich auf die Transporte der Operanden, auf das Aktivieren der Ressourcen und auf das Abholen der Ergebnisse. Ist es möglich, Ressourcen miteinander zu verketten, genügt es oftmals, nur die Parameter einzutragen. Alles andere läuft dann gleichsam von selbst ab, d. h. ohne weiteren Eingriff der Plattform (die Abläufe werden von den Verarbeitungsressourcen autonom gesteuert). Dabei entfällt das Auf- und Abbauen von Stack Frames. Ins Herkömmliche übersetzt handelt es sich um ein Verarbeitungsmodell, in dem die Stack Frames aller Funktionsaufrufe zu Anfang vorgefertigt werden. Alle lokalen Variablen (in den Ressourcen) werden somit praktisch zu globalen Variablen, die einfach erreichbar und ständig zugänglich sind.

Die Schaltmittel der Plattform müssen programmseitig angesprochen werden. Hierzu gibt es folgende Alternativen:

1. über besondere Befehle oder Operatoren, die herkömmlichen Maschinenbefehlen entsprechen (Regiebefehle, u-Operatoren). Typische Funktionen: Laden von Adreßregistern, Verzweigen, Unterprogrammruf Rückkehr, Unterbrechungssteuerung. Im Extremfall ist die Plattform ein herkömmlicher Universalrechner (z. B. ein Mikroprozessor), der den Betrieb der eigentlichen Verarbeitungsressourcen organisiert und koordiniert. Die Befehlsliste eines typischen Mikroprozessors mag als Beispiel eines Vorrates an Regiebefehlen dienen (zumeist genügt eine Grundausstattung an Transport- und Verzweigungsbefehlen, ggf. ergänzt um Befehle, die zur Adreßrechnung nutzbar sind).
2. die Einrichtungen der Plattform sind Ressourcen der Ordnungszahl 0. Sie werden wie alle anderen Ressourcen über Operatoren (oder entsprechende Befehle bzw. Anweisungen) angesprochen.

Im folgenden wird vorzugsweise die zweite Alternative beschrieben.
Einfache Plattformen können nur Befehle lesen. Alle anderen Wirkungen sind von Verarbeitungsressourcen zu erbringen. Sind beispielsweise Daten aus einem Speicherbereich zu holen, so müssen eigens entsprechende Ressourcen angefordert werden. Solche Plattformen sind nicht in der Lage, alle erfindungsgemäßen Operatoren zu unterstützen.
14 zeigt eine einfache Plattform, die einen Befehlszähler IC, ein Verzweigungsadreßregister BA, ein Bedingungsbitregister BC, ein Verzweigungsbedingungsregister BCTL, ein Befehlsregister IR sowie – bedarfsweise – ergänzende Zustandspuffer SB enthält. Der Befehlszähler IC und das Befehlsregister IR wirken auf herkömmliche Weise (wie in jedem üblichen Universalrechner), um aufeinanderfolgende Befehle zu adressieren sowie die adressierten Befehle zu lesen und zur nachfolgenden Decodierung bereitzustellen.
Die Auslegung des Befehlsregisters IR hängt von den jeweiligen Befehlsformaten ab. Sind alle Befehle gleich lang (z. B. 16 Bits), so wird das Befehlsregister so ausgelegt, daß es einen kompletten Befehl aufnehmen kann.
Gibt es Befehle unterschiedlicher Länge (das betrifft z. B. Bytecodes), so kann man das Befehlsregister IR so auslegen, daß es in der Lage ist, den längsten vorkommenden Befehl aufzunehmen. Der Befehlszähler IC und die Speicherschnittstelle zum Befehlslesen müssen in der Lage sein, die verschieden langen Befehle ggf. durch mehrere aufeinanderfolgende Zugriffe ins Befehlsregister IR zu transportieren. Entsprechende Schaltungen werden in vielen üblichen Universalrechnern verwendet. Sie müssen deshalb nicht näher beschrieben werden.
Eine Zwischenlösung besteht darin, Befehle einer einzigen Länge zu verwenden und Angaben, die nicht in einem solchen Befehl unterzubringen sind, auf mehrere Befehle zu verteilen. Das wird weiter unten anhand von Beispielen näher erläutert (u. a. anhand der 103 und der Tabellen 14 bis 30). 14 veranschaulicht die zur Implementierung dieser Beispiele erforderliche Erweiterung der Hardware durch Zustandspuffer SB, die dem Befehlszähler IR nachgeordnet sind. In einfachen Ausführungen sind die Zustandspuffer SB als Halteregister ausgebildet. Es gibt soviele Halteregister, wie jeweils nötig (z. B. drei oder vier). Sie werden mit besonderen Befehlen (bzw. u-Operatoren) geladen. Die zur Auswahl, Ansteuerung und Parameterversorgung der Ressourcen nötigen Signalleitungen sind sowohl dem Befehlsregister IR als auch den Zustandspuffern SB (bzw. den Halteregistern) nachgeordnet.
Die Plattform hat drei eigene Parameter, die mit p-Operatoren, mit l-Operatoren oder durch Verkettung geladen werden können. Die Verzweigungsadresse kommt ins Verzweigungsadreßregister BA, die Verzweigungsbedingung ins Verzweigungsbedingungsregister BCTL. Als dritter Parameter wird die aktuelle Verzweigungsbedingung in das Bedingungsbitregister BC transportiert, und zwar von jener Verarbeitungsressource, deren Ergebnis über den weiteren Verarbeitungsablauf entscheiden soll. Das Bedingungsbitregister BC ist über l-Operatoren oder über Verkettung zugänglich, so daß Verarbeitungsressourcen in der Lage sind, durch Zuführen der aktuellen Bedingungsbits eine Verzweigung auszulösen. Die Register BA und BCTL können in einfachen Plattformen nur – wie in 14 gezeigt – mit Direktwerten aus dem Befehlregister geladen werden (direktes Einstellen von Verzweigungsadresse und Verzweigungsbedingung). In weiterentwickelten Plattformen sind auch diese Register über l-Operatoren oder Verkettung zugänglich. Somit ist es möglich, mit berechneten Verzweigungsadressen und Bedingungen zu arbeiten.
Verzweigungsbedingungen sind besondere Ergebnisse, die von entsprechenden Ressourcen erzeugt werden. Die einfachste Form entspricht den herkömmlichen Flagbits. Darüber hinaus sind beliebige Sonderfunktionen denkbar. Es könnte z. B. eine Verarbeitungsressource geben, die Zahlen addiert und bei einem Überlauf die Verzweigung zu einem Behandlungsablauf veranlaßt.
Eine Verzweigungsressource liefert als Ausgang einen Befehlszählerinhalt. Verzweigen heißt hier Anwendung des y-Operators auf die Verzweigungsressource. Neben der Plattform können auch andere Ressourcen als Verzweigungsressourcen verwendet werden.
Ein typischer Verzweigungsablauf:
Entspricht die aktuelle Bedingung der eingestellten, so wird die Verzweigung ausgelöst; die Verzweigungsadresse BA wird in den Befehlszähler IC transportiert.
Es ist Auslegungssache, wann die Verzweigung ausgelöst wird:

1. sofort mit dem Eintreffen einer aktuellen Bedingung,
2. mit einem entsprechenden y-Operator (vgl. das nachfolgende Beispiel).

Die erste Auslegung spart den y-Operator ein, erfordert aber eine strikt sequentielle Ausführungsreihenfolge (der jeweils nächste Operator darf erst dann wirksam werden, wenn der vorhergehende Operator vollständig ausgeführt wurde). Hierdurch wird gewährleistet daß die Verzweigung sofort nach dem Eintreffen der aktuellen Bedingung ausgelöst wird, ohne daß zwischenzeitlich andere Operatoren angearbeitet werden.
Die zweite Auslegung ermöglicht es, zwischen dem Eintreffen der Bedingung und dem Auslösen der Verzweigung weitere Operatoren auszuführen. Ein ähnliches Prinzip ist in manchen der bekannten Hochleistungsprozessoren vorgesehen. Eine typische Auslegung besteht darin, nach dem Verzweigungsbefehl zunächst noch den unmittelbar nachfolgenden Befehl auszuführen und somit die Lücke in der Befehlspipeline, die sich infolge der Verzweigung zwangsläufig ergibt, mit nützlicher Arbeit zu füllen. Diese Art der Verzögerung (Delayed Branching) ist aber starr und beispielsweise auf den einen nachfolgenden Befehl beschränkt. Die Nutzung des y-Operators zum Auslösen der eigentlichen Verzweigung ermöglicht es hingegen, zwischen der Entscheidung über die Verzweigungsrichtung und der tatsächlichen Verzweigung beliebig viele weitere Befehle auszuführen.
Anhand von 15 soll eine einfache bedingte Verzweigung anhand eines Beispiels veranschaulicht werden. Die Programmierabsicht:
C := A + B
if CARRY_OUT then goto OUT_OF_RANGE
Die Ressourcen:

1. Verarbeitungsressource ADD: ein übliches Addierwerk (bzw. eine ALU). Liefert aus den Parametern 1, 2 die Summe 3 sowie die Flagbitbelegung 4.
2. Verzweigungsressource PGM_CTR: der Befehlszähler, bestehend aus dem Befehlsadreßregister IA und einem Zählnetzwerk CT, das den Registerinhalt um Eins erhöht. Die laufenden Nummern der Parameter: 1 – Verzweigungsadresse; 2 – Verzweigungsbedingung; 3 – auszuwertende Bedingungsbits; 4 – Ergebnis = Adresse der nächsten Anweisung. COND CTL = Bedingungssteuerung. Normalfall: Adreßerhöhung über Zählnetzwerk CT. Verzweigungsfall: Übernehmen der Verzweigungsadresse 1.

Der Ablauf:
Alternative (Verkettung):
Verzweigungen bereiten besondere Schwierigkeiten in Einrichtungen, die mit Ablaufüberlappung (Befehlspipelining) arbeiten, da eine Verzweigung den Befehlsfluß in der Pipeline unterbricht und einen Neuanlauf erforderlich macht. Um den hierdurch bewirkten Geschwindigkeitsverlust abzumildern, wird herkömmlicherweise viel Aufwand getrieben. Es werden zwei Prinzipien im Verbund angewendet:

a) Sprungvorhersage. Stößt die Befehlspipeline auf einen Verzweigungsbefehl, so führt sie das Befehlslesen zunächst in die Richtung weiter, die als wahrscheinlichste angesehen wird. Ein Neuanlauf der Pipeline ist nur dann notwendig, wenn diese Vorhersage nicht eingetreten ist.
b) Sprungzielpufferung. Die als Sprungziele adressierten Befehle werden in einem speziellen Pufferspeicher (Branch Target Cache) abgelegt, so daß sie ggf. sofort (ohne erneuten Speicherzugriff) erreichbar sind und auf schnellstem Wege in die Befehlspipeline einfließen können.

Es handelt sich herkömmlicherweise um ein autonom gesteuertes Raten und Probieren, wobei Konflikte erkannt und ggf. aufgelöst werden müssen. Die Steuer- und Überwachungsschaltungen sind entsprechend aufwendig. In einem erfindungsgemäßen System hingegen kann die Verzweigungsvorbereitung und Pufferung durchgängig programmseitig gesteuert werden; komplizierte Steuerschaltungen sind nicht erforderlich (die entsprechende Schaltkreisfläche könnte z. B. für größere Puffer verwendet werden).
In der Anordnung von 15 kann die Verzweigungsadresse früh genug (vor der eigentlichen Verzweigung) bereitgestellt werden, so daß es möglich wird, die Befehle, zu denen verzweigt werden soll (Verzweigungsziele, Sprungziele), rechtzeitig heranzuschaffen.
16 zeigt eine Plattform gemäß 15, die um einen Sprungzielpuffer BTB erweitert ist. Der Sprungzielpuffer BTB ist an den Speicherdateneingang angeschlossen und über eine Auswahlschaltung dem Befehlsregister IR vorgeschaltet. Mit der Verzweigungsadresse wird zum Speicher zugegriffen, um den betreffenden Befehl (das Verzweigungsziel) vorbeugend in den Sprungzielpuffer BTB zu laden. Wird die Verzweigung wirksam, so wird der Inhalt des Sprungzielpuffers BTB ins Befehlsregister IR übernommen.
Das Prinzip kann auf mehrere Verzweigungsziele erweitert werden. 17 zeigt die wesentlichen Abwandlungen gegenüber 16. Es sind ein Verzweigungsadreßpuffer 11, ein Verzweigungszielpuffer 12 und ein Verzweigungsbedingungspuffer 13 vorgesehen. Die Verzweigungsadressen werden in den Verzweigungsadreßpuffer 11 geladen, die zugehörigen Verzweigungsbedingungen in den Verzweigungsbedingungspuffer 13 (z. B. mittels p-Operator). Gemäß den Adressen im Verzweigungsadreßpuffer 11 werden die jeweiligen ersten Befehle der Sprungziele aus dem Speicher geholt und in den Verzweigungszielpuffer 12 gebracht. Das kann von der Plattform automatisch ausgelöst werden, und zwar vorzugsweise dann, wenn keine anderen Zugriffe auszuführen sind. Dieses voreilende (spekulative) Holen von Befehlen entspricht dem Stand der Technik. Es ist in marktgängigen Hochleistungsprozessoren vorgesehen und muß deshalb nicht näher beschrieben werden. Eine Vereinfachung ergibt sich, wenn die Befehle, die als Verzweigungsziele in Frage kommen, direkt – also programmgesteuert – in den Verzweigungszielpuffer 12 eingetragen werden, z. B. mit p-Operatoren.
Von den Verarbeitungsressourcen signalisierte Bedingungen (l-Operatoren oder Verkettung) betreffen den Verzweigungsbedingungspuffer 13 (es gibt kein allgemeines Bedingungsbitregister BC, sondern einen Bedingungsbitparameter je Eintrag). Die Verarbeitungs ressourcen übergeben ihre Bedingungssignale nicht an das allgemeine Bedingungsbitregister BC, sondern an den Bedingungsbitparameter des jeweiligen Puffereintrags. Ist die jeweilige Bedingung erfüllt, so wird der zugehörige Eintrag im Verzweigungszielpuffer 12 aktiviert. Je nach Auslegung wird dieser Eintrag entweder sofort oder nach Auslösen eines entsprechenden y-Operators über die Auswahlschaltung in das Befehlsregister IR transportiert. Sinngemäß gelangt die zugehörige Befehlsadresse aus dem Verzweigungsadreßpuffer 11 in den Befehlszähler IC. In Weiterbildung der Anordnung von 17 können bestimmte Bedingungssignale der Verarbeitungsressourcen verwendet werden, um Einträge im Verzweigungsadreßpuffer 11 und im Verzweigungszielpuffer 12 direkt zu adressieren. Hierdurch kann ein Verzweigen zu einem von mehreren Verzweigungszielen veranlaßt werden. Eine derart ausgelegte Plattform kann folgende Verzweigungsarten unterstützen:

1. herkömmliche Verzweigung. Für jede derartige Verzweigung ist ein Eintrag in die Pufferspeicher 11, 12, 13 erforderlich. Die Verzweigungsbedingung wird im Verzweigungsbedingungspuffer 13 eingestellt. Die jeweilige Verarbeitungsressource schickt ihre Bedingung zum betreffenden Eintrag. Entspricht die gesendete Bedingung der eingestellten, so wird die betreffende Verzweigung aktiv.
2. bedingte Mehrfachverzweigung. Mehrere Einträge werden genutzt, um in Abhängigkeit von bestimmten Bedingungen in mehrere Richtungen zu verzweigen. So können sich beispielsweise bei einem arithmetischen Vergleich von Zahlen folgende Bedingungen ergeben: <, <=, =, >, >=. Demgemäß können fünf Einträge belegt werden, um eine Mehrfachverzweigung gemäß dem jeweiligen Vergleichsergebnis zu unterstützen. Hierzu muß im Verzweigungbedingungspuffer 13 eine besondere Betriebsart eingestellt werden.
3. unbedingte Mehrfachverzweigung. Mehrere Einträge werden für ein Verzweigen ohne Bedingungsauswertung benutzt. Dabei werden die von den Verarbeitungsressourcen kommenden Bedingungssignale direkt als Auswahladresse verwendet (beispielsweise kann mit 3 Bedingungsbits einer von 8 Folgebefehlen ausgewählt werden).

Die 18 und 19 veranschaulichen, wieviele Verzweigungen erforderlich sind, um übliche Programmkonstrukte zu unterstützen, und zwar 18 anhand der Fallunterscheidung IF...THEN...ELSE und 19 anhand einer FOR-Schleife.
Sowohl die elementare Fallunterscheidung (18) als auch die Programmschleife (19) kommt mit jeweils zwei Verzweigungen aus, einer bedingten (BRANCH) und einer unbedingten (GOTO). Demgemäß sollten Puffereinrichtungen (z. B. ähnlich 17) für wenigstens zwei Verzweigungen ausgelegt werden. Hierdurch wird es möglich, Fallunterscheidungen und Schleifen so vorzubereiten, daß in den einzelnen Durchläufen die Verzweigungen nicht mehr neu eingerichtet, sondern nur noch ausgelöst werden müssen (y-Operatoren oder Verkettung).
Anhand der 20 bis 24 sollen einige weitergebildete Plattformstrukturen erläutert werden. Hierbei wird – aus Gründen der Überschaubarkeit – darauf verzichtet, Vorkehrungen zum Beschleunigen von Verzweigungen darzustellen.
Beim Erweitern der Plattform geht es im Grunde stets um einen Kompromiß zwischen Plattform-Ausstattung und Ressourcen-Ausstattung. So wird man beispielsweise die Plattform auf einem FPGA-Schaltkreis nur so aufwendig auslegen, wie dies für den jeweiligen Anwendungsfall erforderlich ist. Um alle Operatoren zu unterstützen, muß es möglich sein, Parameter im Speicher zu adressieren und Unterprogramme aufzurufen. 20 veranschaulicht eine aus der Anordnung von 16 entsprechend weitergebildete Plattform, die Parameterzugriffe mit Adressen unterstützt, die als Direktwerte in den entsprechenden Befehlen enthalten sind (Absolutadressierung). Die Speicheradreßleitungen sind hierfür an eine Auswahlschaltung angeschlossen, die mit dem Befehlszähler IC und mit Teilen des Befehlsregisters IR verbunden ist. Die Speicherdatenleitungen sind als bidirektionaler Datenbus ausgebildet und sowohl an das Befehlsregister IR als auch an ein Speicherdatenregister MDR angeschlossen. Neben dem Befehlslesen gibt es folgende Signalflüsse:

14: Adressierung eines Parameters im Speicher (p- und a-Operator),
15: Lesen von Speicherinhalten ins Speicherdatenregister MDR. Die gelesenen Daten
: werden zu den Verarbeitungsressourcen weitergeleitet (p-Operator).
16: Laden des Verzweigungsadreßregisters BA und des Verzweigungsbedingungs
: registers BCTL (Parameter der Plattformressource),
17: Schreiben von Daten, die von den Verarbeitungsressourcen geliefert werden, ins
: Speicherdatenregister MDR und weiter in den angeschlossenen Speicher (a-
: Operator).

21 zeigt eine weitergebildete Plattform, die neben der Absolutadressierung von Parametern auch Unterprogrammruf und Rückkehr unterstützt. Die in 20 gezeigten Schaltmittel sind um ein Stackpointerregister SP und um eine Auswahlschaltung zwischen Befehlszähler IC und Verzweigungsadreßregister BA erweitert, deren zweiter Eingang an den Stackpointer SP angeschlossen ist. Die den Speicheradtenleitungen vorgeordnete Auswahlschaltung ist zusätzlich mit dem Stackpointer SP verbunden. Der Befehlszähler IC kann auf die Speicherdatenleitungen aufgeschaltet werden (z. B. nach dem Tri-State-Prinzip). Der Stackpointer SP ist auf bekannte Weise als Vorwärts-Rückwärts-Zähler ausgebildet. Es handelt sich um den allgemein bekannten Stackmechanismus zur Rettung der Rückkehradresse beim Unterprogrammruf. Hierbei ergeben sich folgende Signalflüsse:

18: Unterprogrammruf. Der Stackpointerinhalt wird um Eins vermindert (Predecre
: ment), so daß der Stackpointer SP auf die nächste freie Position im Stack zeigt.
: Der Stackpointer SP wird zur Adressierung des Speichers verwendet, der Befehls
: zähler IC wird auf die Speicherdatenleitungen geschaltet. Ein Schreibzugriff
: bewirkt somit, daß der aktuelle Befehlszählerinhalt (er zeigt auf den Folgebefehl)
: in den Speicher gerettet wird.
19: Rückkehr. Der Stackpointer SP wird zur Adressierung des Speichers verwendet.
: Es findet ein Lesezugriff statt. Der gelesen Speicherinhalt (die Rückkehradresse)
: gelangt über die Auswahlschaltung in den Befehlszähler IC. Anschließend wird
: der Stackpointerinhalt um Eins erhöht (Postincrement), so daß der Stackpointer
: wieder auf die oberste belegte Position im Stack zeigt.
20: der Stackpointer SP ist eine Ressource wie jede andere und kann mit einem
: beliebigen Direktwert geladen werden (p-Operator).

In vielen Anwendungsfällen ist es von Vorteil, wenn die Plattform jene Adressierungsweisen unterstützt, die für die Laufzeitsysteme der gängigen Programmiersprachen typisch sind:

a) Relativadressierung nach dem Prinzip Basis + Displacement,
b) Verfügbarkeit mehrerer Basisregister,
c) für Datenzugriffe zugänglicher Stack,
d) Stack-Oganisation auf Grundlage von Stack Frames.

22 zeigt eine Erweiterung der Speicheradressierung, die Zugriffe nach dem Prinzip Basis + Displacement unterstützt. Neben dem Stackpointer SP sind ein Frame Pointer FP und ein Global Pointer GP vogesehen. Diese drei Adreßregister können als Basisadreßregister verwendet werden. Es gibt folgende Speicherzugriffe:

22: Befehlslesen. Adresse aus Befehlszähler IC, Daten ins Befehlsregister IR.
23: Stackzugriffe (PUSH/POP). Adresse aus Stackpointer SP mit Erhöhen oder
: Vermindern des Stackpointerinhalts (Predecrement/Postincrement). PUSH:
: Schreibzugriff mit Daten aus Befehlszähler IC (Unterprogrammruf, Unterbre
: chung) oder Speicherdatenregister MDR (Daten auf Stack legen). Predecrement.
: POP: Lesezugriff. Daten in den Befehlszähler IC (Rückkehr) oder ins Speicher
: datenegister MDR (Daten vom Stack abholen). Postdecrement.
24: Parameter lesen oder schreiben. Auswahl eines der Basisregister SP, FP, GP, zu
: dem die Displacementangabe aus dem Befehlsregister IR addiert wird. Solche
: Angaben sind z. B. in p- und a-Operatoren enthalten. Die Daten werden in das
: Speicherdatenregister MDR eingetragen (Lesen) oder aus diesem entnommen
: (Schreiben). Entsprechende Maschinenbefehle veranlassen zudem, daß die Daten
: zu den Verarbeitungsressourcen geschickt oder aus diesen abgeholt werden,

Die Nutzung des Stackpointers SP und des Frame Pointers FP entspricht den üblichen Gepflogenheiten (vgl. die bekannten Prinzipien des Funktionsaufrufs in C-Programmen, Pascal-Programmen usw.). Der Global Pointer GP kann verwendet werden, um beliebige andere Basisadressen zu halten (für globale Variable, für Zugriffe zum Heap usw.). Die Anordnung von 22 kann durch weitere Basisadreßregister ergänzt werden.
23. gibt einen Überblick über die Adressierungshardware einer Plattform, die die typischen Abläufe des Unterprogrammaufrufs und der Rückkehr unterstützt (solche Abläufe sind in den Lehrbüchern der Systemprogrammierung eingehend beschrieben). Der Befehlszähler IC ist hier in seinen Teilen dargestellt: Befehlsadreßregister IA, Zählnetzwerk CT und Auswahlschaltung (vgl. auch 15). Der eigentliche Unterprogrammruf ist eine Verzweigung (Verzweigungsadresse in Register BA), dem ein Retten der in IA gehaltenen Folgeadresse (= Rückkehradresse) vorausgeht. Beim anschließenden ENTER-Ablauf (Eintritt ins Unterprogramm) wird Inhalt des Frame Pointer FP auf den Stack gelegt (PUSH FP). Anschließend wird der aktuelle Stackpointer zum neuen Frame Pointer (SP => FP). Beim Leave-Ablauf (Verlassen des Unterprogramms) wird der Stackpointer mit der Belegung des Frame Pointer überladen (FP => SP). Anschließend wird der alte Frame Pointer aus dem Stack geholt (POP FP). Der eigentliche Rückkehrbefehl lädt das Befehlsadreßregister IA mit dem Rückkehradresse aus dem Stack (POP IA). Die diversen Adreßregister (BA, SP, FP, GP) können aus dem Speicher, von den Verarbeitungsressourcen oder mit einem Direktwert aus dem Befehlsregister geladen werden.
24 zeigt eine Übersicht über die Parameter einer kleineren, aber bereits praxisbrauchbaren Plattform. Hieraus geht hervor, wieviele Parameteradressen für eine Plattform beiseite zu setzen sind, die man sich als Zusammenfassung der vorstehend beschriebenen Auslegungen vorstellen kann. Gegenüber den 22 und 23 wurde ein weiteres Basisregister hinzugenommen (Auxiliary Pointer AP). Weitere vier Parameter sind als Steuerworte vorgesehen, um verschiedene Betriebsarten einstellen zu können. Das betrifft u. a. die Verzweigungssteuerung und die Unterbrechungsauslösung. Die Nutzung von Steuerworten und Steuerregistern zur Betriebsartensteuerung ist an sich bekannt und in vielen Prozessorarchitekturen vorgesehen. Der Verzweigungsadreßpuffer 11 und der Verzweigungsbedingungspuffer 13 sind für insgesamt 16 Verzweigungen (einschließlich Unterprogrammrufe) ausgelegt. Das genügt, um z. B. eine Schleife mit mehreren IF-THEN-ELSE-Konstrukten und Funktionsaufrufen zu unterstützen. Plattformen für Hochleistungssysteme brauchen wesentlich größere Verzweigungspuffer. Insgesamt werden 40 Parameteradressen benötigt. Das entspricht einer Adreßangabe von 6 Bits Länge.
Nachfolgend sollen anhand der 25 bis 28 typische Prinzipien der Speicheradressierung erläutert werden. Speichermittel enthalten Speicherzellen, die Anweisungen oder Daten aufnehmen. Es gibt keine Einschränkungen hinsichtlich des Zugriffsprinzips. Typische Zugriffsprinzipien sind:

a) verschiedene Arten der Adressierung,
b) assoziative Auswahl.

25 veranschaulicht zwei Arten der herkömmlichen Adressierung. Im einfachsten Fall (25a) wird eine einzige Adreßangabe (absolute Adresse) verwendet, um die betreffende Speicherposition auszuwählen. Die so adressierten Angaben müssen aber stets in den gleichen Speicherpositionen untergebracht werden. Es ist nicht möglich, Programme und Datenbereiche je nach der aktuellen Speicherbelegung an anderen Positionen unterzubringen. Um diese sog. Verschieblichkeit (Relocatability) zu gewährleisten, werden Vorkehrungen zur Adreßrechnung eingeführt. Eines der einfachsten Prinzipien besteht darin, zu einer Basisadresse eine Versatzangabe (Displacement, Offset) zu addieren (25b). Die Basisadresse zeigt auf den Beginn des jeweiligen Speicherbereichs, die Versatzangabe auf die einzelne Speicherposition. Die Basisadresse wird von der Systemsoftware eingestellt. Die Versatzangaben beziehen sich auf den Beginn des Speicherbereichs (dessen erste Speicherposition hat das Displacement 0, die zweite Speicherposition hat das Displacement 1 usw.).
Durch assoziative Auswahl kann man die gespeicherten Angaben über ihre Eigennamen aufrufen, gleichgültig, an welcher Stelle im Speicher sie sich befinden. Der Eigenname wird typischerweise durch Status- und Prädikatangaben ergänzt, die u. a. die Gültigkeit des betreffenden Wertes kennzeichnen (26). Assoziative Speicher sind aufwendig, da zu jedem Wert auch der Eigenname sowie die Status- und Prädikatangaben gespeichert werden müssen (Assoziativteil). Um die Zugriffszeiten kurz zu halten, ist in jeder Speicherposition eine Vergleichseinrichtung erforderlich, die den Inhalt des Assoziativteils mit den aktuellen Zugriffsangaben vergleicht. Deshalb kommen Assoziativspeicher nur für spezielle Zwecke in Frage (Caches, TLBs, Mikrobefehlspuffer in Superskalarmaschinen, kleinere Ressourcen-Konfigurationen). Die Speicherung von Daten und Programmen beruht dem Stand der Technik gemäß vor allem auf adressierbaren Speichern. Solche Speicher haben typischerweise eine starre Zugriffsbreite von beispielsweise 8, 16, 32 oder 64 Bits. Dem gängigen Stand der Technik zufolge ist das Byte (8 Bits) die kleinste adressierbare Einheit (Byteadressierung). Die anwendungsseitigen Datenstrukturen sind aber vielgestaltig. Um zwischen der hardware- und der anwendungsseitigen Adressierung zu vermitteln, gibt es zwei Prinzipien, die sich darin unterscheiden, wann die Adreßumsetzung bzw. Adreßrechnung stattfindet:

1. zur Compilierzeit. Die gängige und einfache Lösung. Zur Laufzeit beschänkt man sich typischerweise auf das Prinzip Basis + Displacement (vgl. 25b), um die Verschieblichkeit der Programme und Datenbereiche zu gewährleisten. Alle anderen Formen der Adreßrechnung werden ausprogrammiert (bei Nutzung höherer Programmiersprachen erledigt dies der Compiler).
2. zur Laufzeit. Im Extremfall beschränkt sich der Compiler darauf, die mnemonischen Bezeichner in laufende Nummern (Ordinalzahlen) umzusetzen. Die eigentliche Adreßumsetzung findet statt, wenn das Programm ausgeführt wird. Diese Auslegung hat einige Vorteile: man kann Zugriffsrechte usw. für jede einzelne Variable festlegen, die Variablen zur Laufzeit beliebig verschieben usw. Bei entsprechender Auslegung ist es auch möglich, ein einziges Programm für verschiedenartige Datentypen auszunutzen (z. B. einmal mit 32-Bit-Binärzahlen und ein andermal mit 64-Bit-Gleitkommazahlen zu arbeiten), ohne jedesmal neu compilieren zu müssen (objektorientierte Zugriffsweise). Der hardwareseitige Aufwand ist aber höher, und die Zugriffszeiten sind länger, da dem eigentlichen Speicherzugriff typischerweise noch Tabellenzugriffe und Rechenabläufe vorausgehen müssen (27, 28).

Bei Nutzung einer objektorientierten Zugriffsweise werden Programme und Datenbereiche als Objekte aufgefaßt. Objekte sind Behälter für Information, die jeweils als Ganzheit behandelt werden. Jedes Objekt hat eine Namen bzw. – zur Laufzeit – eine binär codierte Ordinalzahl, die das jeweilige Objekt aus der Menge aller Objekte auswählt. Die Programme beziehen sich nicht auf Adressen, sondern auf Objekte. Diese werden durch Objektdeskriptoren beschrieben, die in Objekttabellen zusammengefaßt sind:

a) ist das Objekt im Arbeitsspeicher anwesend, enthält der Deskriptor einen Zeiger auf den betreffenden Speicherbereich (Anfangsadresse + Länge),
b) ist das Objekt nicht anwesend, enthält der Deskriptor eine Positionsangabe für den Massenspeicher.

Die Objektverwaltung sorgt dafür, daß die jeweiligen Objekte in den Speicher geschafft oder ausgelagert werden.
27 veranschaulicht das einstufige Zugriffsschema. Die Variablen im Programm bezeichnen unmittelbar die jeweiligen Objekte. Das entspricht einer Programmumgebung mit ausschließlich globalen Variablen.
28 zeigt das zweistufige Zugriffsschema (Capability Based Addressing). Die Variablen im Programm bezeichnen Eintrittspunkte in eine zur Laufzeit aktuelle Zugriffstabelle (Capability Table), die die Objekt-Identfier enthält, mit denen wiederum die Objekttabelle aufgesucht wird. Dieses Prinzip isoliert die Objektmenge von den Programmen und erlaubt eine feinfühlige Zuordnung von Schutzrechten (bis auf die einzelne Variable genau). Die Zugriffstabelle entspricht praktisch einem Stack Frame mit den Objekt-Identifiern der aktuellen lokalen Variablen.
Es gibt mehrere Möglichkeiten, die Speichermittel 2 in Vorrichtungen, die das erfindungsgemäße Verfahren durchführen, zu gestalten:

a) als herkömmlichen gemeinsamen Arbeitsspeicher (v.Neumann-Organisation),
b) als herkömmliche Speicher für Programme und Daten (Harvard-Organisation),
c) als Verbund verschiedener zweckgebundener Speicher (Programme, Daten, Ressourcenverwaltung, Emulation usw.),
d) als Teil des Ressourcenvorrats.

Es ist möglich, Speichereinrichtungen als Ressourcen auszulegen und Speicherbereiche wie Ressourcen zu verwalten. Solche Speicherbereiche können mit s-Operatoren angefordert und mit r-Operatoren freigegeben werden. Somit läßt sich das erfindungsgemäße Verfahren auch auf die Speicherverwaltung anwenden. Typische Vorteile:

1. die Anforderungen hinsichtlich Speicherkapazität, Nutzung der Speichereinrichtungen usw. gehen unmittelbar aus der Programmierabsicht hervor. Sie sind deshalb präziser als Angaben, die übliche Betriebssysteme nur durch Beobachten des Zugriffsverhaltens ermitteln können.
2. alle Einzelheiten können programmseitig gesteuert werden,
3. es ist möglich, eigens Ressourcen aufzubauen, die die Speicherverwaltung unterstützen,
4. es wird praktikabel, Anordnungen zu verwalten, in denen Speicher- und Verarbeitungseinrichtungen unmittelbar gekoppelt sind (z. B. die weiter unten beschriebenen sog. Ressourcenzellen). Das unmittelbare Zusammenwirken von Speicher- und Verarbeitungshardware ergibt geringere Latenzzeiten (weil nicht so viele Pipeline-Stufen zu durchlaufen sind) und einen höheren Datendurchsatz (weil eine Vielzahl von Ressourcenzellen gleichzeitig und unabhängig voneinander arbeiten kann).

Speicherressourcen können Lese- und Schreiboperationen ausführen. Die Operanden einer Schreiboperation sind Adreßangaben und zu schreibende Daten. Beim Schreiben gibt es keine Ergebnisse. Die Operanden einer Leseoperation sind Adreßangaben. Die gelesenen Daten werden als Ergebnis zurückgeliefert. Zusätzliche Ergebnisse können z. B. Trefferanzeigen in einem virtuellen Speicheradreßraum (vgl. die Funktionsweise der üblichen virtuellen Speicher) oder Fehlermeldungen umfassen (solche Ergebnisse können auch bei Schreibzugriffen geliefert werden).
In Rechnerarchitekturen, die dem Stand der Technik entsprechen, bevorzugt man große, universell genutzte Speicheranordungen, die über einen einheitlichen linearen Adreßraum zugänglich sind. Dieses Prinzip liegt auch den folgenden Beschreibungen zugrunde.
Zum Zugriff auf Speichereinrichtungen können besondere Zugriffsressourcen vorgesehen werden. Sie können beispielsweise nach jedem der anhand der 25 bis 28 erläuterten Prinzipien ausgelegt sein. Diese Prinzipen gehören zum allgemeinen Fachwissen, so daß eine genauere Beschreibung der verschiedenen Varianten nicht erforderlich ist. Die weiteren Beispiele betreffen deshalb vor allem die herkömmliche Auslegung (Adreßumsetzung zur Compilierzeit, Adreßrechnung nach dem Prinzip Basis + Displacement). Derartige Zugriffsressourcen wurden – als Teil der Plattform – bereits weiter oben u. a. anhand von 23 beschrieben. Ein erfindungsgemäßes System kann aber auch höherentwickelte Zugriffsressourcen enthalten, die beispielsweise gemäß 28 ausgebildet sind. Es können mehrere derartige Ressourcen vorgesehen werden, und sie können als spezialisierte Hardware (mit Rechenwerken, besonderen Tabellenspeichern usw.) ausgeführt werden. Zudem sind sie in vollem Maße programmseitig steuerbar. Hierdurch lassen sich die Leistungsschwächen der bisher bekannten Lösungen vermeiden.
Die Zugriffsressourcen können außerhalb der jeweiligen Speichereinrichtung angeordnet oder in diese eingebaut sein. Die Anzahl und Auslegung der Speichereinrichtungen ist im Grunde beliebig; es ist sowohl möglich, einen einzigen Speicher vorzusehen, der alle Angaben (Anweisungen und Daten) aufnimmt (v. Neumann-Prinzip), als auch mehrere jeweils nach Speicherkapazität, Zugriffsbreite, Zugriffsverfahren usw. zweckgerichtet ausgelegte Speichereinrichtungen anzuordnen (die typische Auslegung von Spezialrechnern). 29 veranschaulicht ein System mit zwei Speichereinrichtungen, einem Programmspeicher 25 und einem Datenspeicher 26 (Harvard-Organisation).
Die Adreßeingänge des Programmspeichers 25 sind an Aktivierungsressourcen 27 angeschlossen. Den Datenausgängen sind Interpreterressourcen 28 nachgeschaltet. Der Datenspeicher 26 ist mit einer Verarbeitungsressourcensammlung 29 verbunden. Es gibt folgende grundsätzliche Daten- und Adreßwege bzw. Informationsflüsse:

30: Aufruf (Adressierung) von Maschinenbefehlen seitens der Aktivierungsressour
: cen 23,
31: Lieferung der Steuerangaben im jeweiligen Maschinencode an die Interpreterres
: sourcen 24. Dort erfolgt die Befehlsdecodierung.
32: Steuerung der Verarbeitungsressourcensammlung 29 (über Anweisungen, die den
: erfindungsgemäßen Operatoren entsprechende Wirkungen hevorrufen),
33: Adressierung des Datenspeichers 22 vom Maschinencode aus (u. a. im Rahmen
: von p- und a-Operatoren),
34: Datenzugriffe seitens der Verarbeitungsressourcen 29 (a – Adresse; b – Daten),
35: Bedingungssignale aus den Verarbeitungsressourcen 29 wirken auf die
: Aktivierungs- und Interpreterressourcen 37, 28 ein,
36: die E-A-Schnittstellen werden über die Verarbeitungsressourcen 29 angesteuert.

Programmspeicher 25 und Datenspeicher 26 können zusammengefaßt werden (v.Neumann-Organisation). Im Beispiel von 29 sind die Adreßwege 30, 33 und 34a zu einem Adreßbus und die Datenwege 31 und 34b zu einem Datenbus zusammenzuschalten.
Die Ein- und Ausgabe erfolgt entweder über bestimmte Adreßbereiche (Memory Mapped I/O) oder über spezielle Ressourcen (E-A-Ports, Interfaceadapter, Impulsmustergeneratoren, Zeitgeber usw.; vgl. die Ausstattung der üblichen Mikrocontroller).
Eine Eingabe-Ressource kann nur Ergebnisse liefern, aber keine Operanden empfangen; sie hat – im Sinne des Systems – keine Eingänge (ihre Eingänge werden von außen erregt; sie sind somit nicht ladbar und können auch nicht das Ziel einer Verkettung sein). Eine Ausgabe-Ressource kann nur Operanden empfangen, aber keine Ergebnisse liefern; sie hat – im Sinne des Systems – keine Ausgänge (ihre Ausgänge gehen nach außen; sie sind somit nicht abholbar und können auch nicht als Quelle einer Verkettung wirksam werden).
In einfacheren Systemen entsprechen die Aktivierungs-Ressourcen 27 und die Interpreter-Ressourcen 28 einer elementaren Plattformstruktur, wie sie weiter oben u. a. anhand der 23 beschrieben wurde. Höherentwickelte Systeme können mehrere und leistungsfähigere Plattformen haben (z. B. solche, die mehrere Maschinenbefehle auf einmal holen und decodieren). Zudem ist es möglich, auch die Aktivierungs- und Interpreterressourcen aus einem entsprechenden Ressourcenvorrat nach dem erfindungsgemäßen Verfahren ad hoc zu konfigurieren (z. B. große Verzweigungspuffer, Anordnungen zur Implementierung des Zugriffsverfahrens gemäß 28, Assoziativspeicheranordnungen usw.). Elementare Plattformstrukturen – z. B. gemäß 23 – dienen dann nur noch zur Initialisierung und zu Konfigurations- und Verwaltungszwecken.
Ressourcen, die als Funktionseinheiten zum Konfigurieren von Plattformen vorgesehen sind, müssen in der Lage sein, ausdrücklich Befehlszugriffe anzufordern. Hierzu kann beispielsweise ein gesondertes Zugriffskommando „Befehlslesen" (Instruction Fetch) im Rahmen der jeweiligen Signalprotokolle vorgesehen werden. 30 veranschaulicht die Signalflüsse des Befehlslesens in einem einfachen System gemäß 10. Ein entsprechendes Zugriffskommando wirkt folgendermaßen:

37: die betreffende Ressource 3 stellt die Befehlsadresse bereit und löst das Befehls
: lesekommando aus,
38: der Speicher 2 führt den Lesezugriff aus und liefert die gelesenen Daten als
: Befehle an die eigentliche Plattform-Ressource 1,
39: die Plattform-Ressource 1 übernimmt die Befehlsdecodierung und löst die Be
: fehlswirkung aus.

Ein derart ausgestaltetes System kann beispielsweise folgendermaßen genutzt werden:

1. die Plattform richtet auf bisher beschriebene Weise die Verarbeitungsressourcen ein (vor allem mit s-, p- und c-Operatoren),
2. y-Operatoren setzen die Verarbeitungsabläufe in Gang. Hiermit wird das weitere Befehlslesen an entsprechend eingestellte Verarbeitungsressourcen übergeben,
3. mit dem letzten Befehl, den die Plattform selbst liest, versetzt sie sich in eine Art Wartezustand,
4. die Verarbeitungsressourcen sind in der Lage, die Plattform zu veranlassen, mit dem Befehlslesen fortzufahren, z. B. über einen speziellen Fortsetzungsbefehl oder durch Aktivieren einer Plattformressource (über y-Operator oder Verkettung), die die Programmfortsetzung in der Plattform auslöst.

In weiterentwickelten Systemen ist das Kommando „Befehlslesen" nicht nur mit der Befehlsadresse, sondern zusätzlich mit einer Ressourcenadresse verknüpft, die jene Plattformressource bezeichnet, zu der die Befehle geschickt werden sollen.
Nachfolgend sollen anhand der 31 bis 33 Auslegungen typischer Verarbeitungsressourcen näher erläutert werden. Verarbeitungsressourcen bestehen aus Speichermitteln für die Parameter (Operanden und Ergebnisse) und aus zwischengeordneten Verarbeitungsschaltungen. Sie unterscheiden sich vor allem in Hinsicht auf

a) die Anzahl der Operanden und Ergebnisse,
b) die Art der Datenstrukturen (der Operanden und Ergebnisse),
c) die Anzahl der ausführbaren Operationen (eine oder mehrere),
d) die Verarbeitungsbreite,
e) die Art der Parameterübergabe (beispielsweise als Wert oder über Adresse (by Value, by Reference)),
f) die Verkettung (einbezogene Parameter, Auslegung der Verkettungssteuerung),
g) die zugeordneten Verarbeitungszustände (zustandsfreie Auslegung oder Einbeziehung von Parametern in den Verarbeitungszustand bzw. Programmkontext),
h) die Zusatzfunktionen (Überwachung von Wertebereichen, Registrieren der Nutzungshäufigkeit usw. (Instrumentierung)).

31 veranschaulicht eine einfache Ressource, die nur eine bestimmte Art von Informationswandlungen ausführt (Operation fest, Verarbeitungsbreite fest). Die Speichermittel für Operanden und Ergebnisse sind typischerweise als Register ausgebildet. Die Operanden werden als Werte übergeben, die Ergebnisse als Werte hinterlegt. In ganz einfachen Ressourcen ist keine Verkettung vorgesehen. Anwendbare Operatoren: p, y, a, l.
Soll die Parameterübergabe über Adresse (by Reference) unterstützt werden, sind entsprechende Adreßregister und Zugangswege zum Speicher vorzusehen. Schaltmittel für Adressierung und Datentransport sind in die Verarbeitungsressourcen eingebaut oder als gesonderte (vor- und nachzuschaltende) Ressourcen ausgebildet. Sie bestehen aus den eigentlichen Adressierungsvorkehrungen und den Mitteln der Zugriffssteuerung, deren Auslegung sich nach der jeweiligen Speicherschnittstelle (Bus, Schaltverteiler o. dergl.) richtet. Manche Einrichtungen haben zudem Pufferanordnungen (Register, FIFOs o. dergl.) zum Zwischenspeichern der zu transportierenden Daten.
Adressierungsvorkehrungen können u. a. ausgebildet sein:

a) als Adreßregister,
b) als Adreßregister mit Zählfunktion (Increment, Decrement),
c) als Adreßrechenwerk (z. B. Basis + Displacement),
d) als Iterator, z. B. für die Laufvariablen in typischen FOR-Schleifen.

32 veranschaulicht eine Verarbeitungsressource, die neben den Operanden- und Ergebnisregistern mit zusätzlichen Adreßregistern 40, 41 ausgerüstet ist. Diese Adreßregister sind ausgangsseitig auf Speicheradreßleitungen 42 geführt. In 32 ist hierzu eine Auswahlschaltung vorgesehen, es ist aber ebenso möglich, die Ausgänge der Adreßregister 40, 41 auf interne Busleitungen aufzuschalten (vgl. 13). Eine Ablaufsteuerung 43 ist vorgesehen, um die Speicherzugriffe und Verarbeitungsvorgänge auszulösen. Eine solche Anordnung wirkt folgendermaßen:

1. die Operandenadressen werden in die Operandenadreßregister 40 geschrieben, die Ergebnisadresse kommt ins Ergebnisadreßregister 41 (p-Operatoren oder l-Operatoren oder Verkettung),
2. der Verarbeitungsablauf wird ausgelöst (über y-Operator oder infolge der eingangsseitigen Verkettung),
3. die Ablaufsteuerung 43 tritt in Tätigkeit. Sie veranlaßt zunächst zwei Lesezugriffe zum Speicher, wozu sie die Operandenadreßregister 40 auf die Speicheradreßleitungen 42 schaltet. Die gelesenen Operanden werden in die den Verarbeitungungsschaltungen vorgeordeten Operandenregister eingetragen. Dann wird die Berechnung des Ergebnisses ausgelöst. Ist das Ergebnis gebildet, veranlaßt die Ablaufsteuerschaltung 43 einen Schreibzugriff zum Speicher und schaltet dazu das Ergebnisadreßregister 41 auf die Speicheradreßleitungen 42 auf.

Eine alternative Auslegung besteht darin, Verarbeitungsressourcen, die für die Wertübergabe (by Value) eingerichtet sind, weitere Ressourcen vor- bzw. nachzuschalten, die die Speicherzugriffe ausführen (Adressierungsressourcen). Elementare Adressierungsressourcen haben als Parameter eine Adreßangabe und ein Datenangabe. Die Adreßangabe steht im Adreßregister, die Datenangabe im Datenregister. Die Adresse ist ein Operand. Soll die Adressierungsressource Lesezugriffe ausführen, ist die Datenangabe ein Ergebnis, soll sie Schreibzugriffe ausführen, ist die Datenangabe ein weiterer Operand.
33 zeigt eine Verarbeitungsressource 44, der zwei Adressierungsressourcen 45 für die Operanden vorgeschaltet sind und die ausgangsseitig an eine weitere Adressierungsressource 46 für das Ergebnis angeschlossen ist. Die Verbindungen zwischen den Ressourcen 44, 45, 46 sind typischerweise keine Festverbindungen, sondern sie werden zeitweise durch Verkettung gebildet (c-Operatoren). Die Ergebnisregister der Adressierungsressourcen 45 werden mit den Operandenregistern der Verarbeitungsressource 44 verkettet. Das Ergebnisregister der Verarbeitungsressource 44 wird mit dem Datenregister der Adressierungsressource 45 verkettet.
Eine solche Anordnung wirkt folgendermaßen:

47: die Adressen der Operanden und des Ergebnisses werden in die Adreßregister
: (OP 1 ADRS, OP 2 ADRS, RES ADRS) der Adressierungsressourcen 45 und 46
: eingetragen (p-Operatoren oder l-Operatoren oder Verkettung).
48: die Adressierungsressourcen 45 werden aktiviert (über y-Operatoren oder infolge
: der eingangsseitigen Verkettung). Sie führen daraufhin Lesezugriffe zum Spei
: cher aus.
49: sind die gelesenen Daten im jeweiligen Datenregister (OP 1 DATA, OP 2 DATA)
: der Adressierungsressourcen 45 angekommen, so wird deren Verkettung mit den
: Operandenregistern der Verarbeitungsressource 44 wirksam. Die Operandenwerte
: werden übertragen, und der Verarbeitungsablauf in der Verarbeitungsressource 44
: wird ausgelöst (als weitere Wirkung der Verkettung).
50: hat die Verarbeitungsressource 44 ihr Ergebnis gebildet, so wird die Verkettung
: des Ergebnisregisters mit dem Datenregister (RES DATA) der Adressierungs
: ressource 46 wirksam.
51: die Adressierungsressource 46 löst einen Schreibzugriff aus, um den Daten
: registerinhalt in den Speicher zu übertragen.

Anhand der 34 bis 39 werden im folgenden typische Adressierungsvorkehrungen in Verarbeitungsressourcen näher erläutert. 34 zeigt eine Adressierungsschaltung, die als Adreßaddierer wirkt und eine Speicheradresse nach dem Prinzip Basis + Displacement bildet. Es hängt von der Auslegung des gesamten Systems ab, ob man diese Adreßaddition in den Verarbeitungs- bzw. Adressierungsressourcen oder zentral in der Plattform ausführt (in letzterem Fall erhalten die weiteren Ressourcen von der Plattform vorab berechnete Adreßparameter). In einigen Anwendungsfällen kann man sogar mit absoluten (zur Compilierzeit festgelegten) Adressen arbeiten (das betrifft z. B. manche Embedded Systems mit ROM-residenten Programmen).
Es ist von Vorteil, Adressierungseinrichtungen so auszubilden, daß aufeinanderfolgende Zugriffe stattfinden können, ohne daß die Adreßparameter jedesmal neu eingetragen werden müssen. Hierzu können die Adreßregister (vgl. die 32 und 33) als Adreßzähler ausge führt werden. Nach jedem Zugriff wird die Adresse um Eins (bzw. gemäß der jeweiligen Zugriffsbreite) erhöht, so daß nacheinander auf fortlaufend gespeicherte Daten zugegriffen werden kann.
In der Weiterbildung gemäß 35 ist die Zählweite nicht Eins, sondern als zusätzlicher Parameter einstellbar. Die gezeigte Anordnung errechnet die Speicheradresse aus einer Basisadresse A, einem Displacement B und einer Abstandsangabe D. Das Basisadreßregister A und das Displacementregister B sind an einen Adreßaddierer 52 angeschlossen, der ausgangsseitig über ein Adreßregister X mit den Speicheradreßleitungen verbunden ist. Dem Basisadreßregister B und dem Abstandswertegister D ist ein Displacementaddierer 53 nachgeschaltet, dessen Ausgänge auf das Displacementregister B zurückgeführt sind. Hierüber wird das Displacement nach jedem Zugriff verändert. Rechengänge:

1. Speicheradresse := A + B,
2. Displacement B := B + D (Autoincrement). Der Abstandswert D wird hierbei vorzeichengerecht verrechnet.

Zugriffsbeispiel: eine zweidimensionale Matrix aus Gleitkommazahlen, die zeilenweise gespeichert ist.

a) Zugriff auf aufeinanderfolgende Elemente einer Zeile: mit D = 1 (Wortadressierung) bzw. Länge der Gleitkommazahl in Bytes (Byteadressierung),
b) Zugriff auf aufeinanderfolgende Elemente einer Spalte: mit D = Spaltenanzahl (Wortadressierung) bzw. Spaltenanzahl·Länge der Gleitkommazahl in Bytes (Byteadressierung). Der jeweilige Wert ist vor den Zugriffen einmalig einzustellen.

36 veranschaulicht eine Weiterbildung der Adressierungsschaltung gemäß 35, die den Zugriff auf aufeinanderfolgende gleich lange Datenstrukturen der Länge Z auf Grundlage einer Indexangabe (= laufende Nummer 0, 1, 2, 3 usw.) unterstützt. Basisadresse in A, aktueller Index in B, Länge der Datenstruktur in C, Abstandsangabe in D. In die Verbindung zwischen Adreßaddierer 52 und Displacementregister B ist ein Multiplizierer 54 eingefügt, dem ein Längenregister C vorgeschaltet ist. Der Multiplizierer 54 dient dazu, die auf den Feldanfang bezogene Displacementadresse des n-ten Elements (n = 0, 1, 2, ...) einer eindimensionalen Feldstruktur (Datentyp „Array") zu errechnen, wenn die Länge des einzelnen Feldelements = C ist. In den meisten leistungskritischen Anwendungen ist diese Länge eine nicht allzu große Zweierpotenz (z. B. 2, 4, 8, 16). Soll die Anordnung nur derartige Zugriffe unterstützen, so kann der Multiplizierer 54 als einfaches Verschiebenetzwerk aufgebaut sein (die Multiplikation mit einem Wert 2ⁿ entspricht einer Linksverschiebung um n Bits).
Rechengänge:

1. Speicheradresse := A + (B·C),
2. Displacement B := B + D (Autoincrement).

Zugriffsbeispiel: eine zweidimensionale Matrix aus Gleitkommazahlen, die zeilenweise gespeichert ist. Es gilt die Byteadressierung. Die Gleitkommazahlen sind 8 Bytes lang. Somit ist C = 8 einzustellen.

a) Zugriff auf aufeinanderfolgende Elemente einer Zeile: mit D = 1,
b) Zugriff auf aufeinanderfolgende Elemente einer Spalte: mit D = Spaltenanzahl (dieser Wert ist vor den Zugriffen einmalig einzustellen).

Viele aufeinanderfolgende Zugriffe werden in Programmschleifen ausgeführt. Beim Ausführen von Programmschleifen besteht das Problem, zu erkennen, wann die Schleife zu verlassen ist (Schleifenende). Im allgemeinen Fall wird die Schleifenbedingung über eine bedingte Verzweigung abgefragt (vgl. 19). Die in den gängigen Programmiersprachen üblichen Schleifenkonstrukte können durch entsprechende Ressourcen unterstützt werden.
37 veranschaulicht eine Ressourcenanordnung (nachfolgend Iterator genannt) zur Unterstützung typischer FOR-Schleifen. Operanden: Anfangswert A, Schrittweite B, Endwert C. Ergebnisse: aktueller Schleifenwert X, Endebedingung. Dem Schleifenwertregister X ist über eine Auswahlschaltung das Anfangswertregister A und ein Addierer vorgeschaltet, der mit dem Schrittweitenregister B und mit dem rückgeführten Schleifenwertregister X beschaltet ist. Des weiteren ist dem Schleifenwertregister X ein Vergleicher nachgeordnet, dem weiterhin das Endwertregister C vorgeschaltet ist. Der Vergleicherausgang liefert die Endebedingung. Das Schleifenwertregister X kann als Quelle einer Speicheradresse oder eines aktuellen Variablenwertes verwendet werden, der den Schleifendurchlauf kennzeichnet. Die beschriebene Anordnung unterstützt Schleifen des Typs FOR X := A TO C STEP B. Sie kann beispielsweise wie folgt genutzt werden:

1. ggf. erforderliche Verkettungen werden hergestellt (c-Operatoren),
2. Anfangsadresse, Schrittweite und Endwert werden eingetragen (p-Operatoren, l-Operatoren oder Verkettung),
3. die Programmschleife wird aktiviert (über y-Operator oder als Wirkung einer eingangsseitigen Verkettung). Die Ablaufsteuerung tritt in Tätigkeit. Im ersten Schritt wird der Inhalt des Anfangswertregisters A über die Auswahlschaltung ins Schleifenwertregister X transportiert. In den folgenden Schritten wird der Inhalt des Schrittweitenregisters B zum Inahlt des Schleifenwertregisters X addiert.
4. der Inhalt des Schleifenwertregisters X wird mit dem Inhalt des Endwertregisters C verglichen. Der Schleifendurchlauf wird zyklisch wiederholt, solange C < X. Ist C = X, wird die Schleife ein letztes Mal durchlaufen, und die Endebedingung wird wirksam.

Die Anordnung gemäß 37 kann im Einzeldurchlauf oder im kontinuierlichen Durchlauf betrieben werden.

a) Einzeldurchlauf jeder y-Operator oder eine eingangseitige Verkettung (z. B. von der Ablaufsteuerung zum Iterator) löst einen Schleifendurchlauf aus. Dann werden die Operatoren des Schleifenkörpers ausgeführt. Schleifenanfang: y (Operator) – Schleifenkörper – y (Verzweigung) – weiter oder zurück zum Schleifenanfang
b) kontinuierlicher Durchlauf ein y-Operator oder die eingangsseitige Verkettung löst das Durchlaufen der gesamten Schleife aus. Bei Fortsetzung der Schleife wird die aus gangsseitige Verkettung des Schleifenwertregisters X wirksam (bedingte Verkettung), bei Schleifenende die Endebedingung (die z. B. mit der Plattform verkettet werden kann). Über die ausgangsseitige Verkettung des Schleifenwertregisters X stößt die Iteratorressource die nachfolgenden Verarbeitungsressourcen an, die die Funktionen des Schleifenkörpers ausführen.

Es ist bekannt, das mehrfache Durchlaufen einer Schleife durch entsprechend mehrfache Parallelausführung der Operationen des Schleifenkörpers zu ersetzen (Loop Unrolling). Ist die Durchlaufzahl (1) von Anfang an (zur Compilierzeit) bekannt und (2) nicht allzu groß, so bereitet dies in einem erfindungsgemäßen System keine besonderen Schwierigkeiten.
Beispiel:

FOR n = 1 TO 20
– Schleifenkörper –
NEXT N

wird parallelisiert (aufgerollt), indem die zur Implementierung des Schleifenkörpers erforderliche Ressourcenausstattung 20mal angefordert und entsprechend mit Parametern versorgt wird.
Stehen nicht genügend Ressourcen zur Verfügung, so ist nur eine abschnittsweise Parallelausführung möglich.
Beispiel: Im Ausdruck

FOR n = 1 TO 20
– Schleifenkörper –
NEXT N

können beispielsweise nur vier Schleifenkörperfunktionen parallel unterstützt werden (weil die Anzahl der nutzbaren Verarbeitungsressourcen entsprechend begrenzt ist). Hierzu ist die Schleife umzuformen:
FOR n = 1 TO 20 STEP 5
1. Schleifenkörper|2. Schleifenkörper|3. Schleifenkörper|4. Schleifenkörper
NEXT N
Die Ressourcenausstattung des Schleifenkörpers wird viermal angefordert; die Schleife wird in 5 Durchläufen ausgeführt.
Ist die Durchlaufzahl zur Compilierzeit nicht bekannt (Beispiel: FOR n = 1 TO x), so ist diese einfache Form des Aufrollens nicht möglich. Ein Ausweg besteht darin, eine gewisse Anzahl an Verarbeitungsressourcen zwecks Parallelausführung pauschal bereitzustellen und deren Nutzung über entsprechend ausgebildete Iterator- und Speicherzugriffsressourcen zu steuern.
Die Anzahl der parallel unterstützten Verarbeitungsressourcen wird im folgenden als Parallelisierungsgrad P bezeichnet (P = 1: 1 Ressource, P = 2: 2 Ressourcen usw.). Die Nutzung wird üblicherweise vom Compiler gesteuert. Er ordnet z. B. einer bestimmten Schleife 4 Verarbeitungsressourcen zu (P = 4) und korrigiert die Schrittweite entsprechend:
Aus FOR n = 1 TO x wird FOR n = 1 TO x STEP P.
Beispiel:

Aus FOR n = 1 TO 14 wird mit P = 4 FOR n = 1 TO 14 STEP 4.

Werte für n (jede Verarbeitungsressource erledigt jeweils einen dieser Werte):
im 1. Durchlauf 1, 2, 3, 4
im 2. Durchlauf: 5, 6, 7, 8
im 3. Durchlauf: 9, 10, 11, 12
im 4. Durchlauf: 13, 14
Ersichtlicherweise sind im letzten Durchlauf nicht alle vier Verarbeitungsressourcen beschäftigt. Um den letzten Durchlauf zu erkennen, wird der aktuelle Wert vom Endwert subtrahiert: Restwert R = E – A. Ist der Restwert kleiner als der Parallelisierungsgrad (R < P), so ist das Schleifenende erreicht. Ist R = 0, so wird die Schleife verlassen. Ist R > 0, so handelt es sich um einen letzten Durchlauf, in dem nicht alle Verarbeitungsressourcen beschäftigt sind.
38 zeigt eine gegenüber 37 entsprechend weitergebildete Iteratorressource. Zusätzlich zu den in 37 dargestellten Operandenregistern ist ein weiteres Operandenregister P vorgesehen. Dessen Inhalt gibt den Parallelisierungsgrad an. Schleifenwertregister X und Endwertregister C sind an eine Subtraktionsschaltung angeschlossen, der wiederum eine arithmetische Vergleichsschaltung nachgeordnet ist, deren zweiter Eingang dem Parallelisierungsgradregister P nachgeschaltet ist. Rechengänge:

1. die Subtraktionsschaltung ermittelt den aktuellen Restwert = Endwert – Schleifenwert,
2. die arithmetische Vergleichsschaltung erkennt die Endebedingung Restwert < Parallelisierungsgrad. Ist diese Bedingung gegeben, so ist es erforderlich, im letzten Durchlauf einige der Verarbeitungsressourcen stillzusetzen.

Da das Aktivieren und Versorgen der parallel arbeitenden Verarbeitungsressourcen koordiniert werden muß, ist es zweckmäßig, alle betreffenden Verarbeitungsressourcen einer einzigen entsprechend ausgelegten Speicherzugriffsressource nachzuschalten. Einer Speicherzugriffsressource sind beispielsweise vier gleichartige Verarbeitungsressourcen durch Verkettung nachgeordnet. Die Speicherzugriffsressource muß – wie das gesamte Speichersubsystem – die Speicherbandbreite unterstützen können, die nötig ist, um die parallel arbeitenden Verarbeitungsressourcen mit Daten zu versorgen und die anfallenden Ergebnisse abzutransportieren.
Beispiel: wenn vier Ressourcen mit einer Zugriffsbreite von 64 Bits angeschlossen sind, werden die Speicherzugriffe mit einer Zugriffsbreite von 256 Bits ausgeführt (oder z. B. mit 128 Bits und doppelter Datenrate). Datenpuffer, die Zugriffe mit verschiedener Breite auf verschiedene Adressen sammeln und in Zugriffe mit größerer Breite umsetzen können, sind u. a. in modernen Hochleistungsprozessoren und in Bussteuerschaltkreisen (Bridges, Hubs usw.) enthalten. Sie entsprechen somit dem Stand der Technik und müssen nicht näher beschrieben werden.
39 veranschaulicht eine Speicherzugriffsressource, die einen Iterator 55 gemäß 38 enthält. Der Iterator 55 liefert die Speicheradresse. Die Speicherschnittstelle enthält weiterhin einen Speicherdatenpuffer 56. Der Speicherdatenpuffer 56 ist für eine Speicherbandbreite ausgelegt, die sich aus der mit dem Parallelisierungsgrad multiplizierten Speicherbandbreite der einzelnen Verarbeitungsressource ergibt. Im Beispiel wird diese Bandbreite durch eine vierfache Zugriffsbreite (bei gleicher Datenrate) gewährleistet (z. B. 256 Bits für vier Verarbeitungsressourcen mit 64-Bit-Datenwegen). Dem Speicherdatenpuffer 56 sind je Verarbeitungsressource ein Datenpuffer 57 und eine Verkettungssteuerung 58 zugeordnet. Ein Verkettungsvorgang wird ausgelöst, wenn Daten bereitstehen (Lesen) oder abzuholen sind (Schreiben). Eine Verkettungssteuerung 58 wird nur dann wirksam, wenn ihr Erlaubniseingang aktiv ist. Die Erlaubniseingänge werden von einem Restwertdecoder 59 erregt, der den Restwertleitungen des Iterators 55 nachgeschaltet ist. Der Restwertdecoder 59 ist eine kombinatorische Schaltung, die Erlaubnissignale E1 ... E4 für die Verkettungssteuerungen 58 abgibt (Tabelle 1). Handelt es sich nicht um den letzten Schleifendurchlauf so sind alle vier Verkettungssteuerungen 58 aktiv. Im letzten Schleifendurchlauf richtet sich die Aktivierung nach dem Restwert.
Tabelle 1
Im folgenden werden anhand der 40 bis 48 weitere Einzelheiten der Auslegungen typischer Verarbeitungsressourcen näher erläutert. Hierbei geht es um die Funktionsauswahl und um die Einstellung der Verarbeitungsbreite. Es gibt Verarbeitungsressourcen mit festen Funktionen und solche, die jeweils eine von mehreren Informationswandlungen ausführen können. Zur Funktionsauswahl werden zusätzliche eingangsseitige Parameter vorgesehen. Diese Auslegung erlaubt auch eine vom Verarbeitungsablauf abhängige Funktionswahl (die jeweils auszuführende Operation wird von vorgeordneten Ressourcen berechnet, aus Tabellen entnommen o. dergl.). In diesem Sinne ist es zweckmäßig, jeweils einen unwirksamen Funktionscode (No Operation, NOP) vorzusehen. Ist ein solcher Funktionscode eingestellt, so verändert die Ressource keinen Parameter. Der Verarbeitungszustand (Programmkontext) bleibt erhalten; ausgangsseitige Verkettungen werden nicht ausgelöst. Hierdurch ist es möglich, die Ressource in Abhängigkeit vom Verarbeitungszustand zu umgehen (bedingte Ausführung).
40 veranschaulicht eine einfache Verarbeitungsressource, die ein Funktionscoderegister FC als zusätzlichen eingangsseitigen Parameter hat. Es gibt folgende Möglichkeiten, eine Ressource auf eine bestimmte Funktion einzustellen:

a) der Funktionscode wird wie ein üblicher Parameter behandelt, kann also über p-Operatoren, l-Operatoren oder Verkettung geladen werden. Diese Verfahrensweise ist dann von Vorteil, wenn es um Ressourcenkonfigurationen geht, die bei gleichem strukturellen Aufbau für verschiedene Datentypen genutzt werden sollen (es wird beispielsweise ein bestimmtes Datenflußschema durch Verkettung aufgebaut und je nach Bedarf auf die Verarbeitung von 16-Bit-Binärzahlen, von 32-Bit-Binärzahlen, von Gleitkommazahlen usw. umgestellt).
b) es gibt eine Version des y-Operators, der die Funktion nicht nur auslöst, sondern auch den betreffenden Funktionscode mitbringt,
c) der Funktionscode wird vom s-Operator eingestellt. Diese Verfahrensweise entkoppelt die Formulierung der Programmierabsicht von der technischen Ausstattung der Systeme. Aus Sicht des erfindungsgemäßen Verfahrens entspricht jede Informationswandlung einer eigenen Ressourcenart. Die Programme fordern mit s-Operatoren alle jeweils benötigten Ressourcen an. Hat das System diese Ressourcen tatsächlich als Hardware vorrätig, so werden sie direkt zugeteilt. Verfügt es über universelle Ressourcen, so werden diese (vom s-Operator) für die geforderten Funktionen eingerichtet.

41 zeigt eine Verarbeitungsressource, die für die Parameterübergabe durch Adressierung (by Reference) ausgelegt ist. Ergänzend zu den in 32 dargestellten Adreßregistern 40, 41 ist ein Funktionscodeadreßregister 60 vorgesehen. Der Ablaufsteuerung 43 ist ein Funktionscoderegister 61 vorgeschaltet. Vor der Aktivierung der Ressource ist die Adresse des Funktionscodes in das Funktionscodeadreßregister 60 zu transportieren (p-Operator, l-Operator, Verkettung). Eine Funktionsauslösung (z. B. mittels y-Operator) bewirkt, daß die Ablaufsteuerung 43 zunächst einen Speicherzugriff veranlaßt, der den eigentlichen Funktionscode in das Funktionscoderegister 61 einträgt.
In weiterentwickelten Ressourcen dieser Art ist das Funktionscodeadreßregister 60 als Zähler ausgebildet. Nach Ausführung einer Funktion veranlaßt die Ablaufsteuerung 43 das Weiterzählen und das Holen des nächsten Funktionscodes. Auf diese Weise können Operationsfolgen (also Programmstücke) von der Ressource autonom ausgeführt werden; es handelt sich gleichsam um ein Programm im Programm. Diese autonome Funktionsausführung wird durch eigens dafür vorgesehene Funktionscodes beendet. In der Weiterbildung derartiger Ressourcen gemäß 42 ist das Funktionscodeadreßregister 60 als Befehlszähler (wie in üblichen Universalrechnern) ausgebildet und eingangsseitig mit Teilen des Funktionscoderegisters 61 beschaltet. Diese Anordnung unterstützt die Ausführung bedingter Verzweigungen. In manchen Ressourcen ist zudem eine Beschaltung mit Teilen der Ergebnisregister zweckmäßig. Hierdurch wird es möglich, Funktionsverzweigungen in Abhängigkeit von bestimmten Ergebnissen auszuführen.
Bei der programmierten Ablaufsteuerung innerhalb der Verarbeitungsressource handelt es sich vorzugsweise um eine Art Mikroprogrammsteuerung auf Grundlage einer elementaren Befehlsliste. Die Auslegung von Mikrobefehlen und einfachen Maschinenbefehlen gehört zum allgemeinen Fachwissen. Genauere Beschreibungen können somit entfallen. Diese Auslegung kann u. a. dazu genutzt werden, mit vergleichsweise einfacher Hardware komplizierte Funktionen auszuführen, z. B. Ressourcen bereitzustellen, die trigonometrische Funktionen berechnen. Eine weitere Nutzungsmöglichkeit besteht beispielsweise darin, derartigen Ressourcen die Ausführung elementarer Unterprogramme oder innerster Schleifen zu übertragen (d. h. von Unterprogrammen, die keine weiteren Unterprogrammaufrufe, und von Schleifen, die keine weiteren Schleifenkonstrukte enthalten).
Es gibt Ressourcen mit fester und mit veränderlicher Verarbeitungsbreite. 43 veranschaulicht eine gegenüber 40 weitergebildete einfache Ressource, die mit einem zusätzlichen Verarbeitungsbreitenregister (BITS) ausgerüstet ist. Die dort angegebene Verarbeitungsbreite gilt für alle Parameter. Verarbeitungsbreiten werden ebenso eingestellt wie Funktionscodes (vgl. die Erläuterungen zu 40). Operanden werden nur gemäß der eingestellten Breite verarbeitet, Ergebnisse nur gemäß der eingestellten Breite abgeliefert. Die Behandlung überschüssiger Bitpositionen hängt von der Auslegung der Ressourcen und (was u. a. das Speichern betrifft) von der Plattform ab. Auslegungsbeispiele:

a) Auffüllen mit Nullen (Nullerweiterung),
b) Auffüllen mit der Belegung der jeweils (gemäß eingestellter Breite) höchstwertigen Bitposition (Vorzeichenerweiterung),
c) überschüssige Bits ignorieren, kürzere Operanden rechtsbündig einfügen (wobei die restliche Belegung erhalten bleibt).

Zwecks Verarbeitung werden die Operanden typischerweise auf die maximale Verarbeitungsbreite der Verarbeitungsschaltungen erweitert (Nullerweiterung, Vorzeichenerweiterung usw.). Die Einzelheiten der Operandenerweiterung für numerische und nichtnumerische Elementaroperationen gehören zum allgemeine Fachwissen.
44 zeigt eine Verarbeitungsressource, die es ermöglicht, die Breite verschiedener Parameter einzeln einzustellen. Im Beispiel sind zwei Verarbeitungsbreitenregister BIT_1, BIT_2 vorgesehen, denen jeweils eine Operandenerweiterungsschaltung 62, 63 nachgeschaltet ist. Die Operandenerweiterungsschaltungen 62, 63 sind in die Signalwege zwischen den Operandenregistern und den eigentlichen Verarbeitungschaltungen eingefügt. Sie wirken so, daß sie den eigentlichen Verarbeitungsschaltungen Operanden zuführen, die auf die jeweilige maximale Verarbeitungsbreite erweitert sind.
Verarbeitungsbreiten sind nicht nur einzustellen, sonden gelegentlich auch abzufragen – die Ressourcen und die Plattform müssen wissen, aus wievielen gültigen Bits die einzelnen Parameter bestehen. Hierzu können u. a. folgende Prinzipien genutzt werden:

1. die aktuelle Zugriffsbreite wird in entsprechenden Tabellen vermerkt (solche Tabellen werden weiter unten anhand der 80 bis 85 beschrieben). Diese universelle und wenig aufwendige Lösung hat den Nachteil, daß zur Laufzeit den Operandenzugriffen jeweils entsprechende Tabellenzugriffe vorausgehen müssen, um die jeweils aktuelle Zugriffsbreite abzufragen.
2. der Maschinencode enthält Angaben zur Zugriffsbreite. Diese Lösung ähnelt dem herkömmlichen Stand der Technik (es gibt Befehle zum Transportieren von Bytes, Worten, usw.). Soll der Aufwand nicht übermäßig ansteigen, können nur wenige Zugriffsbreiten unterstützt werden. Zudem muß die jeweilige Verarbeitungsbreite zur Compilierzeit festliegen; ein dynamisches Umschalten (zur Laufzeit) ist nicht möglich.
3. die Speichermittel in den Ressourcen, die die Verarbeitungsbreite angeben (Verarbeitungsbreitenregister, TAG-Bits), werden abfragbar ausgelegt. Diese Angaben werden jeweils zusammen mit den Datenbits übertragen bzw. sind von anderen Ressourcen abfragbar. Hierzu werden die Schnittstellen zwischen den Ressourcen (Bussysteme, Punkt-zu-Punkt-Interfaces o. dergl.) entsprechend ergänzt.

45 zeigt eine Verarbeitungsressource, deren Parameterregister um Kennzeichnungsbits (TAG-Bits) erweitert sind, die die jeweilige Zugriffsbreite angeben. Vor- und nachgeschaltete Ressourcen können diese Angaben über zusätzliche Busleitungen abfragen. Hierzu sind der Operanden- und der Ergebnisbus durch zusätzliche Leitungen (TAG-Bus) ergänzt. Bei allen Informationstransporten (p-Operatoren, l-Operatoren, a-Operatoren, Verkettung) wird die Belegung der TAG-Bits abgefragt (nur Lesezugriffe). Schreibzugriffe über den TAG-Bus finden nur statt, um TAG-Bits einzustellen, z. B. beim Ausführen von s-Operatoren.
Die Ressourcen können für verschiedene Formen der Parameterübergabe ausgelegt werden (Wertübergabe, Adreßübergabe usw. sowie beliebige Kombinationen). 46 veranschaulicht eine gegenüber 43 weitergebildete, in der Parameterübergabe umschaltbare Verarbeitungsressource, die an einen universellen Speicherbus und an (nicht näher dargestellte) Signalleitungen zur Wertübergabe angeschlossen ist (z. B. an einen Operanden- und an einen Ergebnisbus gemäß 11). Einige der Parameterregister 64 sind fest für die Wertübergabe vorgesehen. Den umschaltbar ausgelegten Operandenregistern 65 sind Auswahlschaltungen vorgeordnet. Um bei Adreßübergabe die Parameter im Speicher adressieren zu können, ist je Parameter ein Adreßgenerator 66 vorgesehen. Im einfachsten Fall handelt es sich jeweils um ein Adreßregister, das als Zähler ausgebildet ist. Die Adreßgeneratoren 66 können aber auch beispielsweise gemäß den 35 bis 37 gestaltet sein.
Varianten der Umschaltung:

a) durch Operationsauswahl (über eine Angabe im Rahmen des Funktionscodes),
b) durch Zustandssteuerung im Innern der Ressource. Die Form der letzten Übergabe vor der Operationsauslösung (y-Operator oder Verkettung) wird als gültig angesehen. 1. Beispiel: das Eintragen eines Parameters in den ersten der Adreßgeneratoren 66 führt dazu, daß für den 1. Operanden die Adreßübergabe eingestellt wird. 2. Beispiel: ein p-Operator, der den zweiten Operanden direkt einträgt, veranlaßt, daß der zweite der Adreßgeneratoren 66 außer Funktion gesetzt wird (Einstellung auf Wertübergabe).

Die 47 und 48 veranschaulichen typische Beispiele elementarer, universell nutzbarer Ressourcen. Solche Ressourcen können u. a. vorteilhaft als Arithmetik-Logik-Einheiten (ALUs) ausgebildet werden, und zwar sowohl mit fester als auch mit veränderlicher Verarbeitungsbreite.
47 zeigt eine Arithmetik-Logik-Einheit mit einem üblichen Funktionsumfang. Den Operandenregistern sind Schaltmittel zur Nullerweiterung (Zero Extend) und zur vorzeichengerechten Erweiterung (Sign Extend), ein Schaltung zur Ausführung logischer Verknüpfungen, eine Additions- und Subtraktionsschaltung sowie eine Verschiebeeinrichtung nachgeschaltet. Diese Verarbeitungsschaltungen sind über eine Auswahlschaltung mit dem Ergebnisregister und mit einem Bedingungsbitregister (Flagregister) verbunden. Die Operationsauswahlsignale (OP) stammen aus dem Funktionscoderegister (vgl. beispielsweise 43). Der Funktionscode stellt jede der Verknüpfungsschaltungen auf eine bestimmte Funk tion ein und adressiert die nachgeordnete Auswahlschaltung, um die jeweils gewünschte Art der Verknüpfung (Logik, Addition/Subtraktion, Verschieben/Rotieren) auszuwählen.
Beispiel eines Operationsvorrates:

1) Addieren,
2) Addieren mit Ausgangsübertrag,
3) Subtrahieren,
4) Subtrahieren mit Ausgangsübertrag,
5) bitweise Konjunktion (AND),
6) bitweise Disjunktion (OR),
7) bitweise Antivalenz (XOR),
8) bitweise Negation (NOT),
9) Zweierkomplement,
10) nach links verschieben/rotieren,
11) nach rechts verschieben/rotieren,
12) keine Wirkung (NOP).

Einzelheiten des Aufbaus solcher Verarbeitungsschaltungen gehören zum allgemeinen Fachwissen, so daß eine genauere Beschreibung nicht erforderlich ist. Anordnungen ähnlich 47 sind u. a. in Mikrocontrollern und Prozessoren des mittleren Leistungsbereichs üblich. 48 veranschaulicht eine universelle Verarbeitungsressource, deren Funktionsumfang dem im Bereich der Hochleistungsprozessoren üblichen Stand der Technik entspricht. Sie besteht aus einer Arithmetik-Logik-Einheit, die mit Registerspeichern und einem Steuerwerk (Sequencer) SEQ verbunden ist. Die Ressource hat vier Operandenregister A, B, C, D, ein Funktionscoderegister FC, zwei Ergebnisregister X, Z sowie – als weiteres Ergebnisregister – ein Bedingungsbitregister (Flagregister). Die Datenstrukturen sind ganze Binärzahlen und Bitfelder. Tabelle 2 gibt einen Überblick über den Funktionsumfang. Zu jeder Funktion ist angegeben, wieviele Operanden benötigt, wieviele Ergebnisse gebildet und welche Register verwendet werden. Die Unterstützung von Einzelbits, Zeichenketten, Gleitkommazahlen usw. ist nicht dargestellt.
Als universelle Arithmetik-Logik-Einheiten ausgelegte Ressourcen sollen auch zur Adreßrechnung und Speichereradressierung sowie zur Unterstützung von Speicherzugriffsfunktionen genutzt werden; es soll möglich sein, mit derartigen Ressourcen Anordnungen aus Adressierungs- und Verarbeitungsressourcen aufzubauen (vgl. 33).
Ladefunktionen (LOAD) holen den adressierten Speicherinhalt und stellen ihn als Ergebnis bereit, das an die eigentlichen Verarbeitungsressourcen geliefert wird (l-Operatoren oder Verkettung). Speicherfunktionen (STORE) speichern einen als Operanden gegebenen Wert, der zuvor von den eigentlichen Verarbeitungsressourcen angeliefert wurde (l-Operatoren oder Verkettung).
48a zeigt die Auslegung als typische Verarbeitungsressource. Die Register A, B, C, D können Operanden aufnehmen, die Register X, Z Ergebnisse liefern (zur Zusammenschaltung mit einer entsprechenden Anschlußsteuerung vgl. 13). Soll eine solche Ressource zu Adressierungs- und Speicherzugriffszwecken dienen, so wird beispielsweise das Ergebnisregister X als Speicheradreßregister verwendet. Beim Laden wird das aus dem Speicher geholte Datenwort beispielsweise in das Operandenregister C geschrieben und weiter ins Ergebnisregister Z geschafft. Von dort aus kann es mit l-Operatoren oder durch Verkettung zu den Verarbeitungsressourcen transportiert werden. Ein zu speicherndes Datenwort ist zunächst in das Operandenregister C zu schreiben (l-Operator oder Verkettung). Es wird ins Ergebnisregister Z übertragen und von dort aus in den Speicher geschrieben, wobei die Speicheradresse aus dem Ergebnisregister X entnommen wird. Die verbleibenden Operandenregister A, B, D stehen zu Adreßrechnungszwecken zur Verfügung. Hiermit lassen sich beispielsweise die Rechengänge gemäß 35 unterstützen.
48b zeigt eine Abwandlung, die u. a. auf Adreßrechengänge gemäß 36 erweitert werden kann. Hierzu wird ein weiteres Operandenregister benötigt. Um nach wie vor mit ingesamt 8 Registeradressen (3 Adreßbits) auszukommen, ist das Ergebnisregister Z als bidirektionales Register für Speicherdaten ausgebildet. Es kann als Operanden- und als Ergebnisregister verwendet werden (INOUT-Parameter; vgl. 91) und ist sowohl für die eingangsseitige als auch für die ausgangsseitige Verkettung ausgelegt. Beim Laden wirkt Z als Ergebnisregister. Das aus dem Speicher geholte Datenwort wird ins Register Z geschrieben und kann von dort aus an die Verarbeitungsressourcen weitergegeben werden (l-Operatoren oder Verkettung). Beim Speichern wirkt Z als Operandenregister. Das zu speichernde Datenwort wird in Register Z als Parameter übergeben und von dort aus zum Speicher weitergeleitet.
Tabelle 2
Anmerkungen zu Tabelle 2:

1) Z|X und A|B = höherwertiges Wort in Z oder A, niederwertiges Wort in X oder B.
2) LOAD, STORE = Laden und Speichern gemäß Adreßrechnung Basis + Displacement mit nachträglicher Erhöhung der Displacementangabe. Basis in A, Displacement in B, Erhöhung in D. Unterstützt Zugriffe zu aufeinanderfolgenden gleich langen Datenstrukturen der Länge D (vgl. die Erläuterungen zu 35). Wird von Ressourcen gemäß 48a unterstützt. Berechnete Speicheradresse in X. Gelesene Daten gelangen aus dem Speicher nach C und von dort aus weiter nach Z. Zu schreibende Daten werden in C übergeben und gelangen über Z zum Speicher.
3) LOAD_A, STORE_A = Laden und Speichern gemäß Adreßrechnung Basis + Displacement mit nachträglicher Erhöhung der Displacementangabe. Basis in A, Displacement in B, Erhöhung in D. Unterstützt Zugriffe zu aufeinanderfolgenden gleich langen Datenstrukturen der Länge D (vgl. die Erläuterungen zu 35). Speicherdaten werden in Register Z übergeben. Erfordert Auslegung nach 48b.
4) LOAD_X, STORE_X = Laden und Speichern gemäß Indexangabe mit nachträglicher Erhöhung des Indexwertes. Unterstützt Zugriffe zu aufeinanderfolgenden gleich langen Datenstrukturen auf Grundlage einer Indexangabe (= laufende Nummer 0, 1, 2, 3 usw.). Basisadresse in A, Indexangabe in B, Länge der Datenstruktur in C, Erhöhung in D (vgl. auch die Erläuterungen zu 36). Speicherdaten werden in Register Z übergeben. Erfordert Auslegung nach 48b.
5) FORLOOP = FOR X := A TO C STEP B. Vgl. auch die Erläuterungen zu 37.

Ersichtlicherweise kommt man mit maximal 8 Registern aus. Es genügt somit eine Parameteradresse von 3 Bits. Hiermit kann man auch die weiteren in modernen Hochleistungsprozessoren üblichen Operationen (über Gleitkommazahlen, Zeichenketten, Einzelbits usw.) unterstützen.
Jede Verarbeitungsfunktion in Tabelle 2 entspricht – aus Sicht der Systemarchitektur – wenigstens einem Ressourcentyp (es gibt Abwandlungen in Hinsicht auf die Operandenlängen usw.). Die Hardware gemäß 48 wird mit s-Operatoren auf die jeweilige Funktion eingestellt.
Im folgenden soll anhand der 49 bis 58 die Verkettung von Ressourcen näher erläutert werden. Ausgänge können mit Eingängen nachgeordneter Ressourcen verkettet werden. Der Zweck der Verkettung besteht darin, Verbindungen zwischen den Ressourcen so einzurichten, daß die Ressourcenanordnung dem Datenflußschema des jeweiligen Anwendungsproblems entspricht. Herstellen einer Verkettung: mittels c-Operator. Auflösen einer Verkettung: mittels d-Operator. Varianten der Ausführung:

1. die Verbindungen werden physisch generiert (z. B. bei Aufbau mit programmierbarer Hardware),
2. die Verbindungen werden physisch geschaltet (z. B. über Bussysteme oder Schaltverteiler (Switch Fabric)),
3. die Verbindungen werden mit Verkettungszeigern oder in Verkettungslisten beschrieben. Auf Grundlage dieser Angaben führen die Ressourcen die jeweiligen Datenübertragungen selbsttätig aus (z. B. über ein Bussystem, an dem sie als Busmaster aktiv werden, oder über einen Schaltverteiler).
4. die den Verkettungen entsprechenden Datentransporte werden von der Plattform emuliert (die Plattform führt entsprechende Lese- und Schreibzugriffe zu den verketteten Ressourcen aus, beispielsweise auf Grundlage gespeicherter Verkettungslisten).

Es hängt von der jeweiligen Ressource ab, welche Parameter in die Verkettung einbezogen werden können und welche nicht. Zu verkettende Ergebnisse müssen um Angaben erweitert werden, die die Ziele der Verkettung beschreiben. Handelt es sich um Hardware-Ressourcen, sind zusätzliche Schaltmittel erforderlich, um die entsprechenden Informationstransporte zu steuern. Technische Lösungen zur Angabe von Verkettungszielen:

a) Zeiger,
b) Zeigerliste,
c) gespeicherte Tabellen mit Quell- und Zieladreßangaben,
d) eine Art horizontaler Mikrobefehl, der die Signalwege steuert,
e) Versenden von Datenpaketen mit entsprechenden Bestimmungsangaben.

49 zeigt, wie das Ergebnis einer einfachen Verarbeitungsressource ausgangsseitig verkettet wird. Das eigentliche Ergebnisregister (Ergebniswertregister) wird durch ein Zeigerregister 67 ergänzt. Diesem Zeigerregister 67 ist ein Zustandsregister 68 zugeordnet, dem eine Zugriffssteuerung 69 nachgeschaltet ist. Das Zeigerregister 67 wird über c-Operatoren geladen. Es enthält einen Adreßzeiger, der auf die eingangsseitig verkettete (= nachgeordnete) Ressource verweist. Das Zustandsregister 68 enthält im Beispiel lediglich ein Bit. Belegung: 0 = keine Verkettung; 1 = Verkettung aktiv.
Wirkung des c-Operators: Eintragen der Verkettungsadresse in das Zeigerregister 67 und Setzen des Bits im Zustandsregister 68. Wirkung des d-Operators: Löschen des Bits im Zustandsregister 68. Wirkung des y-Operators:

1. das Ergebnis wird gebildet,
2. ist das Bit im Zustandsregister 68 gesetzt, so wird die Zugriffssteuerung 69 aktiv, um das Ergebnis gemäß Adreßangabe im Zeigerregister 67 zur adressierten Ressource zu transportieren (z. B. durch Anfordern eines entsprechenden Buszugriffs).

Jede Ressource, die Ziel einer Verkettung ist, muß wissen, wann sie zu rechnen anfangen soll. Es gibt mehrere Möglichkeiten, solche Ressourcen zu aktivieren:

a) Auslösung über y-Operator In den betreffenden Ressourcen sind keine besonderen Vorkehrungen erforderlich. Die Plattform muß aber eine strikt sequentielle Ausführungsreihenfolge der Operatoren gewährleisten. Der jeweils nächste Operator darf erst wirksam werden, nachdem der vorhergehende Operator vollständig ausgeführt wurde. Das schließt auch die Datentransporte der Verkettung ein. Die Ausführung eines y-Operators für eine Ressource ähnlich 49 dauert so lange, bis das verkettete Ergebnis abtransportiert wurde. Erst dann wird der nächste Operator wirksam. Die Reihenfolge der y-Operatoren der verketteten Ressourcen muß der Verkettungsreihenfolge entsprechen. Vorteilhaft ist die Einfachheit. Bei der softwareseitigen Emulation und in kleineren Systemen (z. B. mit einem einzigen Universalbus) ergibt sich die strikte Ausführungsreihenfolge praktisch von selbst (da zu jeder Zeit nur ein Befehl oder Datentransport ausgeführt werden kann). Leistungsfähigere Hardware kann allerdings nicht in vollem Maße ausgenutzt werden. Auch spart man – gegenüber Programmabläufen ohne Verkettung – nur die l-Operatoren ein, nicht aber die y-Operatoren.
b) Neuberechnung bei Änderung der Eingangsbelegungen. Gemäß 50 sind den Operandenregistern Vergleichsschaltungen 70 nachgeordnet, die den bisherigen Inhalt mit dem neuen (an den Eingängen anliegenden) Inhalt vergleichen. Der Operandenvergleich findet dann statt, wenn neue Operanden eingetragen werden. Unterscheidet sich der neue (ankommende) Operand vom bisherigen Inhalt des jeweiligen Operandenregisters, so wird die betreffende Vergleichsschaltung 70 aktiv. Die Ausgänge aller Vergleichsschaltungen 70 sind über ein Auswahlnetzwerk 71 mit einer Verkettungssteuerung 72 verbunden. Dem Auswahlnetzwerk 71 ist zudem ein Maskenregister 73 vorgeordnet. Das Auswahlnetzwerk 71 bestimmt, wann eine Neuberechnung ausgelöst wird. Typische Betriebsarten: 1) jede Änderung eines Operanden führt zu einer Neuberechnung, 2) die Neuberechnung wird nur dann ausgelöst, wenn sich alle Operanden geändert haben, 3) die Neuberechnung wird ausgelöst, wenn bestimmte Kombinationen von Operandenänderungen aufgetreten sind. Die jeweilige Betriebsart wird über das Maskenregister 73 programmseitig ausgewählt. Das Maskenregister 73 wird beispielsweise über s-Operatoren eingestellt (zusammen mit der Funktionsauswahl).
c) Gültigkeitssteuerung. Den einzelnen Parametern (= eingangsseitigen Registern oder Speicherpositionen) werden Zustände zugeordnet: 1) nicht verkettet (not connected), 2) frei (invalid), 3) gültig (valid), 4) Gültigkeit halten (stick on valid), aber frei, 5) Gültigkeit halten (stick on valid) und gültig.

Diese Zustände können beispielsweise in drei Zustandsbits codiert werden, die dem jeweiligen Operandenregister zugeordnet sind. Tabelle 3 veranschaulicht eine Zustandscodierung. 51 zeigt eine Ressource mit Operandenregistern, die durch Zustandsbits STA erweitert sind.
Tabelle 3
Ein c-Operator veranlaßt das Laden des Zeigers und das Aktivieren der Verkettung. Wirkung gemäß der Zustandscodierung von Tabelle 3: STA0 = 0 (frei); STA2 = 1 (verkettet). Ein d-Operator veranlaßt das Deaktivieren der Verkettung. Wirkung gemäß der Zustandscodierung von Tabelle 3: STA2 = 0 (nicht verkettet).
Die Gültigkeitssteuerung wird vorteilhafterweise so ausgestaltet, daß es möglich wird, auf y-Operatoren zur Funktionsauslösung zu verzichten. Hierzu wird die Ergebnisberechnung stets dann ausgelöst, wenn alle Operanden gültig sind, gleichgültig auf welche Weise sie angeliefert wurden. In Hinsicht auf Tabelle 3 bedeutet das, daß die Auslösung der Ergebnisberechung nur von STA0 und STA1 abhängt, nicht aber von STA3. Die Verkettungssteuerung wirkt folgendermaßen:

1. die Operandenregister sind zunächst frei (STA0 = 0).
2. die Zulieferung von Operanden macht sie gültig (STA = 1). Ein Operand wird immer dann gültig (valid), wenn er angeliefert wird, gleichgültig auf welche Weise die Lieferung erfolgt (Verkettung, p-Operator, l-Operator).
3. sind alle Operandenregister einer Ressource gültig, werden die Ergebnisse berechnet.
4. stehen die Ergebnisse in ihren Registern bereit, werden die Operandenregister wieder freigemacht (das ist erforderlich, um Verkettungen mit Eingängen derselben Ressource (Rückführungen) zu unterstützen). Ausnahme: Operandenregister mit Zustand „Gültigkeit halten" (STA1 = 1) bleiben gültig. Derart gekennzeichnete Operanden haben keinen Einfluß auf die Funktionsauslösung (die Wirkung dieses Zustandes entspricht dem Ausschließen über das Maskenregister 73 in 50). Diese Betriebsweise wird beispielsweise durch s-Operatoren, p-Operatoren oder u-Operatoren eingestellt. Nutzung: u. a. für Festwerte, die nur einmal eingetragen werden.
5. die verketteten Ergebnisse werden an ihren Zielen abgeliefert, falls diese frei sind. Ansonsten wird gewartet (oder in einen Puffer geschrieben).

Gelegentlich ist es zweckmäßig, die Verkettungsmechanismen der Ressource insgesamt ein- und ausschalten zu können (generelle Verkettungserlaubnis), z. B. um zu vermeiden, daß während des Einrichtens oder Umstellens der Betriebsart einzelne Steuerautomaten unberechtigt anlaufen. Hierzu können u. a. spezielle u-Operatoren vorgesehen werden. Auch ist es möglich, den y-Operator als generelle Starterlaubnis zu verwenden (nach dem Einstellen der Betriebsweise wird die Ressource mittels y-Operator gleichsam scharfgeschaltet).
Manchmal ist es von Vorteil, Verkettungsabläufe von Bedingungen abhängig zu machen (bedingte Verkettung). Das betrifft sowohl die ausgangsseitige Weitergabe von Ergebnissen an durch Verkettung nachgeordnete Ressourcen (bedingte Ausgangsverkettung) als auch die bedingte eingangsseitige Funktionsauslösung (bedingte Eingangsverkettung). Hierdurch ist es u. a. möglich, den Informationsfluß in Abhängigkeit von den Verarbeitungsergebnissen verschiedene Wege durch die verketteten Ressourcen nehmen zu lassen, auf besondere Bedingungen zu reagieren und Verarbeitungsabläufe mit bestimmten Ereignissen zu synchronisieren.
52 veranschaulicht ein Beispiel der bedingten Ausgangsverkettung. Hier ist eine Speicherzugriffsressource (mit Iterator) 74 (z. B. eine Anordnung gemäß 39) mit zwei nachgeordneten Verarbeitungsressourcen 75 sowie mit der Plattform 1 verkettet. Während der Schleifendurchläufe schickt die Speicherzugriffsressource 74 ihre aktuellen Werte zu den Verarbeitungsressourcen 75. Ist das Schleifenende erreicht, werden die Verarbeitungsressourcen 75 nicht mehr beliefert. Statt dessen wird die entsprechende Endebedingung an die Plattform 1 signalisiert.
Zur Realisierung der bedingten Eingangsverkettung können Parameter ausgenutzt werden, die nur zur Funktionsauslösung dienen (Funktionscodes; vgl. beispielsweise den Parameter FC in 43). Diese Parameter werden in die Verkettung einbezogen. Hierbei ist es vorteilhaft, die Verkettungssteuerung in der Ressource so auszubilden, daß es nicht nur möglich ist, die Verarbeitungsfunktionen anzustoßen, sondern auch aufzuhalten. Es ist zweckmäßig, die Funktionscodes so zu gestalten, daß folgende Wirkungen codiert werden können:

1. gar keine Wirkung (No Op),
2. Ressource anhalten,
3. Ressource starten (mit dem bisherigen Funktionscode),
4. Eintragen eines neuen Funktionscodes. Ressource wird angehalten.
5. Eintragen eines neuen Funktionscodes. Ressource wird gestartet.

Die Codes 1, 2 und 3 bewirken nur die jeweilige Steuerfunktion, werden aber nicht in das Funktionscoderegister FC übernommen (vielmehr bleibt die alte Belegung erhalten). Diese Auslegung ermöglicht es, Verarbeitungsabläufe erst dann zu starten, wenn außerhalb der Ressource bestimmte Bedingungen erfüllt sind.
Eine weitere vorteilhafte Nutzung der Verkettungsvorkehrungen besteht darin, Operanden gleichzeitig an mehrere Ressourcen zu schicken (Eingangsverkettung). In 53 ist dargestellt, daß die Eingangsverkettung mehrerer Operanden praktisch einer Parallelschaltung der beteiligten Operandenregister entspricht.
Die Verkettungssteuerschaltungen in den Ressourcen wirken normalerweise so, daß die aktuellen Daten zunächst an alle verketteten Operandenpositionen weitergegeben und dann erst die Ergebnisse berechnet werden. Alle entsprechend verketteten Ressourcen erhalten somit die Operanden nahezu gleichzeitig (das entspricht der in 53 veranschaulichten Parallelschaltung).
Eine Abwandlung ist die bedingte Operandenverkettung. Hierbei wird erst das Ergebnis berechnet und dann über die Weitergabe des Operanden entschieden (gemäß einer einstellbaren Bedingung). Nutzung: beispielsweise in datenabhängigen Schleifen oder zu Debugging-Zwecken.
Gemäß 49 ausgelegte Ressourcen können ein Ergebnis nur zu einem einzigen Operanden transportieren (Einzelverkettung); ein Ausgang kann lediglich mit einem einzigen Eingang (einer nachgeschalteten Ressource) verkettet werden. 54 zeigt, daß diese Art der Verkettung verwendet werden kann, um inverse Baumstrukturen aufzubauen. Derartige Strukturen entstehen beim Auswerten geklammerter bzw. geschachtelter Ausdrücke, z. B. der typischen Formelausdrücke des numerischen Rechnens (in 54 sind drei Beispiele dargestellt). Herkömmlicherweise nutzt man hierzu elementare Stackmaschinen (Wandlung des Ausdrucks in eine umgekehrte polnische Notation, die direkt in Befehle der Stackmaschine umgesetzt wird). Sinngemäß lassen sich solche Ausdrücke in inverse Baumstrukturen umsetzen, wobei jeder Verknüpfungsoperation eine Ressource entspricht. Somit ist bereits einfachste Form der Verkettung geeignet, viele anwendungspraktisch wichtige Konfigurationen von Ressourcen zu unterstützen.
Um einen Ausgang mit mehreren Eingängen zu verketten (Mehrfachverkettung), kann man dem Ausgang Speicheranordnungen zuordnen, die mehrere Zeiger- und Zustandsangaben aufnehmen können. Sinngemäß können Operandenregister, die für die Eingangsverkettung vorgesehen sind, mit entsprechenden Speicheranordnungen ergänzt werden. Gemäß 55 werden die Zeigerangaben zu einer Zeigerliste zusammengefaßt, wobei jedem Zeiger ein Zustandsbit (Verkettungzustand) zugeordnet ist. Es handelt sich praktisch um eine Mehrfachanordnung der Schaltmittel 67, 68 gemäß 49. Hat eine solche Ressource ihre Ergebnisse berechnet (oder wurde der betreffende Operand eingetragen), so adressiert die Zugriffssteuerung die Zeigerliste, holt alle Zeiger mit gesetztem Zustandsbit und transportiert den jeweiligen Wert zu den in den Zeigern angegebenen Ressourcen.
Vorteile:

1. in den nachgeordneten Ressourcen sind keine besonderen Vorkehrungen erforderlich,
2. bei entsprechender Auslegung der Hardware (mit mehreren Bussystemen oder über Schaltverteiler verbundenen Signalwegen) ist es möglich, ein Ergebnis gleichzeitig an mehrere verkettete Ressourcen zu senden (Parallelisierung).

Nachteil: die Anzahl der Verkettungen ist beschränkt.
Ein Ausweg: die Zeigerliste wird im Speicher untergebracht, so daß sie beliebig groß sein darf. Das hat aber den Nachteil, daß die Verkettungsabläufe mehr Zeit benötigen.
Die 56 bi 58 veranschaulichen eine Alternative: die Mehrfachverkettung über Zeigerverkettung (Daisy Chain). Hiermit kann eine Verkettung beliebig viele Ressourcen umfassen. Diese Art der Verkettung muß aber auch seitens jener Ressourcen unterstützt werden, die die verketteten Ergebnisse als Operanden empfangen (Unterstützung der Eingangsverkettung). Jeder derart zu verkettende Operand braucht einen oder zwei Zeiger. Die Ressource, die das Ergebnis liefert (Quelle), hat nur einen Zeiger. Dieser verweist auf den ersten verketteten Operanden, der dort vorgesehene Zeiger auf den zweiten usw. Das Ende der Verkettung wird in der letzten Ressource durch eine besondere Zeigerbelegung gekennzeichnet (z. B. durch einen Nullzeiger).
Ist es nicht nötig, die Verkettung dynamisch (zur Laufzeit) umzubauen, so genügt ein einziger Zeiger je Parameter. Ist das Umbauen von Verkettungen (mit d- und c-Operatoren) zu unterstützen, werden jeweils zwei Zeiger vorgesehen, wobei der zweite den Rückverweis auf die jeweils vorgeordnete Ressource (Vorgänger) enthält. 56 veranschaulicht eine entsprechende Anordnung.
Empfängt eine Ressource einen Operanden, zu dem ein Nachfolger angegeben ist, so wird dieser nicht nur ins eigene Operandenregister eingetragen, sondern auch zur jeweiligen nächsten Ressource weitergeleitet.
Ein c-Operator wirkt so, daß die gegebene Zeigerkette abgefragt wird. In der letzten Position dieser Kette wird die Endekennung (z. B. ein Nullzeiger) durch einen Zeiger auf die neu hinzugekommene Ressource ersetzt.
Ein d-Operator wirkt so, daß die Zeigerangaben der Ressource, die aus der Verkettung herausgenommen werden soll, dazu verwendet werden, um die Zeiger in der vorhergehenden und in der nachfolgenden Ressource umzustellen:

1. die Nachfolgerangabe wird zur Nachfolgerangabe der vorhergehenden Ressource (die ihrerseits über die Vorgängerangabe adressiert wird),
2. die Vorgängerangabe wird zur Vorgängerangabe der nachfolgenden Ressource (die ihrerseits über die Nachfolgerangabe adressiert wird),.

57 veranschaulicht, wie eine Mehrfachverkettung dynamisch umgebaut wird:

a) Beispiel einer Zeigerbelegung. Der Quelle sind die Ressourcen 1, 2 und 3 nachgeschaltet. Die Pfeile deuten die zum Entfernen der Ressource 2 erforderlichen Zeigertransporte an.
b) die Ressource 2 wird aus der Verkettung entfernt (Operator d (Quelle => 2)). In Ressource 1 wird der Nachfolger auf Ressource 3 umgestellt, in Ressource 3 der Vorgänger auf Ressource 1. In Ressource 2 wird ggf. die Verkettungsfunktion abgeschaltet (z. B. durch entsprechendes Laden eines Zustandsregisters).

58 veranschaulicht einen typischen Verkettungsablauf in einer Ressource:

a) Ausgangszustand: es wurden Ergebnisse berechnet. (Die Operanden der Ressource wurden ggf. freigemacht (invalid), um Rückführungen auf die eigenen Eingänge zu unterstützen.) Die verketteten Ergebnisse werden gemäß den jeweiligen Zeigerangaben zu ihren Zielressourcen transportiert.
b) die neuen Operanden gelangen in die Operandenregister. Ein derart geladenes Operandenregister wird automatisch gültig.
c) ist ein Operand mit einer weiteren Ressource eingangsseitig verkettet, so wird er weitergegeben.
d) sind alle Operanden gültig, so werden die Ergebnisse berechnet.
e) die Operandenregister werden wieder freigemacht (Ausnahme (nicht dargestellt): Zustand = Gültigkeit halten). Das Spiel beginnt von neuem.

Im folgenden soll anhand der 59 bis 70 veranschaulicht werden, wie Ressourcen mit Speichermitteln verbunden und in Speichereinrichtungen eingebaut werden können. Der Datenaustausch zwischen Verarbeitungsressourcen und Speicher ist typischerweise zeitaufwendig. Um diese Transportzeiten zu verringern, können die Ressourcen mit eigenen Speichermitteln ausgerüstet werden. Varianten:

a) jede einzelne Verarbeitungsressource hat eigene Speichermittel (59). Die als Beispiel dargestellte Ressource entspricht weitgehend 46. Speicherdatenbus und Speicheradreßbus dienen als Zugang zum eigenen (lokalen) Speicher. Die gesamte Ressource ist über eine Anschlußsteuerung mit dem Rest des Systems verbunden. Die Anschlußsteuerung unterstützt zum einen den direkten Zugriff auf die Ressource (Operatoren, Verkettung usw.). Zum andern ermöglicht sie dem System den Zugriff auf die lokalen Speichermittel.
b) mehrere Verarbeitungsressourcen sind zu einem Bündel (Cluster) zusammengefaßt und mit gemeinsamen (lokalen) Speichermitteln verbunden (60). Die Erweiterung gegenüber 59 besteht darin, daß mehrere Ressourcen auf die lokalen Speichermittel zugreifen.
c) mehrere (auch: sehr viele) Anordnungen aus Verarbeitungsressourcen und Speichermitteln sind zu einer aktiven Speicheranordnung zusammengefaßt (61). Die einzelne Ressourcenanordnung mit Speicher (z. B. gemäß 59) stellt praktisch eine aktive Speicherzelle dar (Ressourcenzelle). Die gesamte Speicherausstattung bildet einen einzigen zusammenhängenden Adreßraum.

In der aktiven Speicheranordnung bilden Speicher und Verarbeitungsressourcen eine Einheit. Der Aufbau großer Halbleiterspeicher (vor allem DRAMs) aus einer Vielzahl von Speichermatrizen (Banks) gehört seit längerem zum Stand der Technik, ebenso die Verbindung dieser Speicherbanks mit synchron arbeitenden (taktgesteuerten) Hochgeschwindigkeitsschnitt stellen. Eine aktive Speicheranordnung kann beispielsweise gebildet werden, indem im Speicherschaltkreis jeder Speicherbank entsprechende Verarbeitungsschaltungen zugeordnet werden. Speicheranordnungen mit eingebauten Verarbeitungsressourcen können auf vielfältige Weise genutzt werden, beispielsweise im Rahmen der bekannten Verfahren zur Parallelverarbeitung. Zudem ist es u. a. möglich, jedem Funktionsaufruf eigene Ressourcenzellen zuzuordnen. Die Vorteile:

1. zur Laufzeit entfällt der Verwaltungsaufwand (Overhead); es sind nur die aktuellen Parameter zu transportieren, aber keine Stack-Frames auf- und abzubauen, lokale Variable zu initialisieren usw.
2. alle Funktionen, deren Aufruf irgendwie parallelisierbar ist, können auch tatsächlich parallel ausgeführt werden.

62 zeigt das Blockschaltbild eines Direct-Rambus-Speicherschaltkreises (DRDRAM). Die Speicherbanks 76 sind über Leseverstärker 77 mit internen Datenwegen 78 verbunden (die im Beispiel jeweils 72 Bits breit sind). Zwischen den Leseverstärkern 77 und den internen Datenwegen 78 können Verarbeitungsressourcen 79 angeordnet werden.
Verarbeitungsressourcen können in beliebige Speichereinrichtungen eingebaut werden, z. B. in Caches, Registersätze, Pufferspeicher und zweckgebundene Speicherbereiche (z. B. für Objekttabellen oder für Stack Frames). Die ein- und ausgangsseitigen Speichermittel der Verarbeitungsressourcen sind hierbei Speicherzellen der jeweiligen Speichereinrichtung. Der grundsätzliche Vorteil besteht darin, daß sich die Verarbeitungsressourcen gleichsam an Ort und Stelle befinden, so daß besondere Informationstransporte (aus Speicherzellen in Register und umgekehrt) entfallen (sind – aus technologischen Gründen- besondere Register nicht zu vermeiden, so ergeben sich vergleichsweise geringe Latenzzeiten, da die Transporte typischerweise nur über kurze Punkt-zu-Punkt-Verbindungen zwischen den Registern und dem jeweiligen Speicher-Array laufen).
Verarbeitungsressourcen in universell genutzten Speichereinrichtungen (z. B. in Caches und Universalregistersätzen) müssen ihrerseits universell ausgelegt sein. Verarbeitungsressourcen in speziellen Speichereinrichtungen (z. B. in solchen, die zum Speichern von Objekttabellen genutzt werden (vgl. 28)) können hingegen so ausgestaltet werden, daß sie die Informationswandlungen, die in der betreffenden Speichereinrichtung vorrangig auszuführen sind, in besonderer Weise unterstützen (spezielle Veknüpfungsschaltungen, Signalwege usw.). Das wird weiter unten anhand eines Beispiels (70) veranschaulicht.
Zunächst soll die Unterbringung von Verarbeitungsressourcen in Caches näher beschrieben werden. Caches sind typischerweise in Form von Blöcken (Cache Lines) organisiert. Zu jedem Block gehört ein Datenteil (der üblicherweise 32 ... 256 Datenbytes aufnehmen kann) und ein Assoziativteil. Der Assoziativteil enthält die jeweilige Speicheradresse. Wird ein Speicherzugriff eingeleitet, so wird die Zugriffsadresse mit dem Inhalt des Assoziativteils verglichen. Bei Gleichheit (Cache Hit) wird kein Arbeitsspeicherzugriff ausgeführt, sondern ein Zugriff zum jeweiligen Datenteil des Caches. Hierdurch ergibt sich eine beträchtlich kürzere Zugriffszeit. Bei Ungleichheit (Cache Miss) findet hingegen der Arbeitsspeicherzugriff statt. Dabei wird der Arbeitsspeicherinhalt in den Datenteil des Blocks transportiert (so daß er beim nächsten Zugriff dort bereitsteht). Gemäß 63 können die die Datenteile der einzelnen Blöcke mit Verarbeitungsressourcen verbunden werden. Befinden sich die gewünschten Daten im Cache (Cache Hit), so können sie von den eingebauten Ressourcen unmittelbar verarbeitet werden. Das jeweilige Trefferanzeigesignal ADRS MATCH bewirkt, daß die entsprechenden Verarbeitungsfunktionen ausgeführt werden. Ist ADRS MATCH inaktiv, so handelt es sich um einen Cache Miss, und die betreffenden Daten müssen zunächst auf an sich bekannte Weise (wie bei herkömmlichen Caches) aus dem Arbeitsspeicher geholt werden. Eine solche Auslegung erspart den Einbau von Verarbeitungsressourcen in DRAM-Schaltkreise, ergibt aber für übliche Programme (ohne massive Parallelverarbeitung) ähnliche Verarbeitungsleistungen (Trefferrate des Caches mal Verarbeitungsleistung einer (fiktiven) aktiven Speicheranordnung, die die gesamte Arbeitsspeicherkapazität umfaßt).
Eine andere Weiterbildung sieht vor, Verarbeitungsressourcen in Registersätzen unterzubringen. Große universelle Registersätze (mit typischerweise 32 bis ca. 256 Registern) sind seit längerem üblich, wenn es darum geht, besonders leistungsfähige Prozessoren zu bauen. Sie werden vor allem als Schnellzugriffsspeicher für jene Daten genutzt, mit denen gerade gearbeitet wird (z. B. für die lokalen Variablen der aktuell ausgeführten Funktion). Entsprechende Programme laufen so ab, daß zunächst die betreffenden Variablen in die Register geladen werden. Die eigentlichen Verarbeitungsbefehle beziehen sich dann nur noch auf die Register; sie führen keine Speicherzugriffe aus. Am Ende werden die Ergebnisse aus den Registern in den Arbeitsspeicher transportiert (Load-Store-Prinzip). In üblichen Prozessoren dieser Art holen die Verarbeitungsbefehle die zu verknüpfenden Daten aus den Registern und bringen die Ergebnisse dorthin zurück. Eine typische Verknüpfung der Art X := A OP B (Dreiadreßoperation) erfordert entweder drei aufeinanderfolgende Registerzugriffe oder eine Registeranordnung mit drei Zugriffswegen. Soll mehr als eine Verknüpfung zu einer Zeit ausgeführt werden (Superskalarprinzip), sind entsprechend viele zusätzliche Zugriffswege erforderlich. Solche Registeranordnungen brauchen viel Platz auf dem Schaltkreis. Sind extrem hohe Taktfrequenzen gewünscht, so müssen mehr Stufen in der Verarbeitungspipeline vorgesehen werden (der Ablauf Lesen => Verknüpfen => Zurückschreiben ist nicht in einem einzigen Taktzyklus zu schaffen). Das hat höhere Latenzzeiten zur Folge, so daß in all den Fällen, in denen der fortlaufende Fluß durch die Pipeline unterbrochen werden muß, die Verarbeitungsleistung deutlich absinkt.
Um dies zu vermeiden, werden die Register direkt mit Verarbeitungsressourcen verbunden. 64 zeigt ein Beispiel. Je vier Register sind mit einer üblichen Arithmetik-Logik-Einheit (ALU) verbunden. Es ist aber auch möglich, spezielle Verarbeitungswerke vorzusehen.
Zwei Register nehmen die Operanden auf (Operandenregister), eines das Ergebnis (Ergebnisregister) und eines eine Angabe, die die auszuführende Operation beschreibt (Kommandoregister). Das Kommandoregister wird vorzugsweise über s-Operatoren geladen (der s-Operator weist der an sich universellen Verarbeitungsressource (ALU) eine spezielle Funktion zu).
Eine solche Registeranordnung braucht nur zwei Zugriffswege, einen für die angeschlossenen Ressourcen und einen für allgemeine Lese- und Schreibzugriffe (Datentransport). Der zweite Zugriffsweg kann auf Schreibzugriffe zu den Operanden- und Kommandoregistern und auf Lesezugriffe zu den Ergebnisregistern beschränkt werden. Derart eingeschränkte Zugriffe können parallel zu den eigentlichen Verarbeitungszugriffen stattfinden. Die Operandenregister lassen sich über die ALU und das Ergebnisregister lesen, das Ergebnisregister läßt sich über die ALU von jedem der Operandenregister aus laden.
Eine Anordnung mit beispielsweise 32 Registern kann 8 Verarbeitungseinheiten (ALUs) enthalten, eine mit 128 Registern 32 Verarbeitungseinheiten. Die direkten Verbindungen zwischen Registern und Verarbeitungsschaltungen ermöglichen es, mit wenigen Pipeline-Stufen auszukommen (oft dürfte eine einzige genügen).
Es sind allerdings keine wahlfreien Verknüpfungen mehr möglich, z. B. <R7> := <R1> OP <R22>. Vielmehr müssen die zu verknüpfenden Operanden in die der betreffenden Ressource vorgeschalteten Register geschafft werden. Kompliziertere Verarbeitungsabäufe bestehen somit aus Folgen von Verknüpfungen und Transportvorgängen (wodurch die Ergebnisse zu Operanden der folgenden Verknüpfungen werden). Um einen Teil dieser Transportvorgänge einzusparen, kann man gemäß 65 bestimmte Register kombiniert als Operanden- und Ergebnisregister verwenden, so daß das aktuelle Ergebnis als Operand an der nächsten Verknüpfung teilnehmen kann. Varianten:

a) das Ergebnis wird auf Operandenregister zurückgeführt, die somit als eine Art Akkumulator wirken,
b) das Ergebnis wird in Operandenregister anderer Ressourcen eingetragen (elementare Form der Verkettung).

Diese Varianten können einzeln oder in Kombination vorgesehen werden. In Kombinationslösungen wird die Art der Ergebnisspeicherung über einen Operationscode gesteuert. Sind alle beschriebenen Auslegungen kombiniert, ergeben sich folgende Möglichkeiten:

1. Rückführung auf Operandenregister,
2. Speichern im Ergebnisregister,
3. Weitergabe in Operandenregister der nächsten Ressource,
4. beliebige Kombinationen von 1. bis 3.

Da der Registersatz vergleichsweise einfach aufgebaut ist (es ist nicht nötig, mehrere parallele Zugriffswege vorzusehen), kann man auf einer gegebenen Schaltkreisfläche mehr Register unterbringen. Hierdurch wird es möglich, Variablenwerte ggf. mehrfach zu speichern und somit Transporte während der Verarbeitungsabläufe zu vermeiden.
Um die Transporte zu beschleunigen, ist es von Vorteil, die Zugriffsweg gemäß 66 so auszulegen, daß eine Datenbelegung gleichzeitig in mehrere Zielregister geladen werden kann. Der Registersatz besteht beispielsweise aus 128 Registern. Jeweils 4 Register sind einer Verarbeitungsressource zugeordnet. Es gibt insgesamt 32 Verarbeitungsressourcen. Zwei Register sind jeweils für Schreibzugriffe zugänglich, eines für Lesezugriffe. Die entsprechenden Transportanweisungen haben eine Bitmaske zum Steuern des Ladens und ein Registeradreßfeld zum Auswählen des zu lesenden Registers. Es gibt folgende Arten von Transportanweisungen:

a) Laden mit Kommandocodes (entspricht s-Operator),
b) Laden mit Datenwort vom Speicher (entspricht p-Operator),
c) Speichern Ergebnis (entspricht a-Operator),
d) Datentransport zwischen Registern (entspricht l-Operator).

Durch entsprechendes Setzen der Bitmaske in den Transportanweisungen ist es möglich, eine beliebige Kombination von Registern auf einmal zu laden. Weitere Zugriffe werden über die ALUs geführt. Hierzu sind entsprechende Kommandocodes zu laden. Ein Kommandoregister kann mehrere Kommandocodes aufnehmen.

1. Ausführung: das Kommandoregister ist gemäß 67 als Schieberegister ausgebildet, wobei jeder y-Operator jeweils einen Kommandocode zur Wirkung bringt. Anschließend wird dieser Kommandocode heraus- und zum anderen Ende wieder hereingeschoben. Aufeinanderfolgende y-Operatoren bewirken, daß zyklisch Kommando für Kommando ausgeführt wird.
2. Ausführung: die y-Operatoren haben Adreßangaben, über die jeweils eines der gespeicherten Kommandos ausgewählt wird.
3. Ausführung: nach der Aktivierung mittels y-Operator laufen die Kommandos selbsttätig ab (es handelt sich um eine Art kurze Maschinenbefehle).

In einer weiteren alternativen – eher dem Herkömmlichen angenäherten – Auslegung enthält das Kommandoregister nur einen Kommandocode, der vom jeweiligen y-Operator eingetragen und sofort zur Wirkung gebracht wird (Operatorvariante y_f). Hierbei ist es zweckmäßig, die Kommandoregister gesondert zu adressieren (so daß sie keine Positionen des eigentlichen Registeradreßraums belegen).
Die beschriebenen Auslegungen ermöglichen es, die Parallelausführung mehrerer Operationen (im Beispiel bis zu 32) mit vergleichsweise kompakten Befehlsformaten zu unterstützen. 68 veranschaulicht sowohl herkömmliche als auch erfindungsgemäße Befehlsformate:

a) Operationsbefehl eines marktgängigen Hochleistungsprozessors. Der Registersatz umfaßt 128 Register. Der einzelne Befehl ist 41 Bits lang. Ein 128-Bit-Wort kann 3 solcher Befehle aufnehmen. Es ist möglich, alle 3 Befehle parallel auszuführen.
b) modifiziertes Befehlsformat zum Steuern der zuvor beschriebenen Anordnung. Bis zu zwei Ressourcen können gleichzeitig zur Wirkung gebracht werden, indem ein Kommandocode ins jeweilige Kommandoregister geladen wird.
c) Format eines y-Operators, der mittels Bitmaske jede beliebige Kombination der 32 Verarbeitungsressourcen aktivieren kann.

Verarbeitungsressourcen können in beliebige Speicheranordnungen eingebaut werden. U. a. können Speicherbereiche, die für besondere Informationsstrukturen vorgesehen sind, eigens mit speziellen Ressourcen bestückt werden, die beispielsweise die typische Nutzung von Objekttabellen, Stack Frames, E-A-Puffern usw. in jeweils angemessener Weise unterstützen.
In den bisher beschriebenen Ausführungen sind die Verarbeitungsressourcen den einzelnen Speicherblöcken bzw. Speicherzellen fest zugeordnet. Das ergibt vergleichsweise einfache Strukturen, erfordert aber, daß sich alle von einer Ressource zu verarbeitenden Daten im jeweiligen Speicherblock befinden. Um diese Einschränkung aufzuheben, sind in einer alternativen Ausführung universelle Verbindungseinrichtungen zwischen den Ressourcen vorgesehen, z. B. Bussysteme oder Schaltverteiler. Im Unterschied zu den vorstehend erläuterten Auslegungen gehören hier nicht alle Register der Ressourcen zum Adreßraum der Speicheranordnung. 69 zeigt eine Anordnung, in der in jeder Ressource ein Operandenregister über den Speicheradreßaum erreichbar ist. Die weiteren Register sind an die uni versellen Verbindungseinrichtungen angeschlossen. Als Beispiel veranschaulicht 70 eine mit Ressourcen versehene Speicheranordnung, die zur Aufnahme von Objekttabellen vorgesehen ist. Jede Speicherzelle nimmt Operanden auf und ist mit Verarbeitungsressourcen verbunden, z. B. mit einer universellen ALU. Ergebnisleitungen der Verarbeitungsressourcen sind auf die Speicherzelle zurückgeführt, so daß sie ggf. im Sinne eines Akkumulators genutzt werden kann. Weitere Operanden- und Ergebnisregister sind an eine universelle Verbindungseinrichtung angeschlossen, z. B. an einen Universalbus oder an einen Schaltverteiler (Switch Fabric). Somit kann jede beliebige Verknüpfung zwischen Registerinhalten ausgeführt werden.
Im Beispiel gemäß 70 soll die Objekttabelle die Adressen der Datenobjekte aufnehmen, aber auch das Rechnen mit den zugehörigen Werten unterstützen. Die Objekte sind hier Zahlen, deren Wertebereich durch einen Größt- und einen Kleinstwert begrenzt ist (vgl. die Bereichsangaben (range) in der Programmiersprache Ada). Zudem ist eine Meßzählerangabe vorgesehen, um z. B. die Nutzungshäufigkeit des Objekts zu ermitteln oder um darüber Buch zu führen, wieviele Programme sich derzeit auf das Objekt beziehen (Reference Count). In 70 bedeuten:

80: es kann wahlweise mit der Adresse oder mit dem aktuellen Wert gerechnet wer
: den (Auswahl),
81: der zweite Operand wird über die universellen Verbindungseinrichtungen her
: angeführt,
82: das Ergebnis kann auf die Operandenregister zurückgeführt und über die uni
: versellen Verbindungseinrichtungen abgeholt werden,
83: Kontrolle des Wertebereichs,
84: Meßzähler,
85: Ablaufsteuerung.

Das Einstellen der Bereichsgrenzen, das Abholen des Meßzählerinhalts usw. ist nicht dargestellt. Es liegt aber nahe, die betreffenden Register an die Zugangswege 81 der universellen Verbindungseinrichtungen oder an ein weiteres Bussystem anzuschließen (besondere Zugangswege für Verwaltungszwecke u. dergl. werden weiter unten näher erläutert).
Im folgenden soll anhand der 71 bis 79 dargestellt werden, wie Ressourcenanordnungen in Schaltkreise – vorzugsweise in programmierbare – eingebaut werden können. 71 veranschaulicht, wie größere programmierbare Schaltkreise (Field Programmable Gate Arrays; FPGAs) üblicherweise aufgebaut sind. Sie enthalten programmierbare Zellen (Logikzellen) 86, die über ebenfalls programmierbare Verbindungswege 87 und Koppelschaltungen (Verteiler) 88 zusammengeschaltet sind. Die einzelnen Logikzellen sind vergleichsweise elementar. Mit einer einzigen Zelle kann man beispielsweise eine kombinatorische Verknüpfung von 4 ... 8 Eingängen und eine Speicherstelle (= 1 Flipflop) realisieren. Der Hardwareaufwand zum Programmieren der Logikzellen und der Verbindungsnetzwerke ist beachtlich. Um einen bestimmten Funktionsumfang zu verwirklichen, braucht man oft weit mehr als die zehnfache Anzahl an Transistoren im Vergleich zum „echten" anwendungsspezifischen Schaltkreis (auf dem die Schaltung bis auf den Transistor optimiert ist).
Deshalb enthalten manche FPGA-Schaltkreise einige besonders aufwendige und oft benötigte Schaltungskomplexe in optimierter, nicht-programmierbarer (harter) Form (das betrifft Schnittstellensteuerungen usw. bis hin zu kompletten Prozessoren). Solche Schaltkreise sind aber vergleichsweise teuer und auch weniger universell. Es kann z. B. sein, daß der eingebaute harte Prozessor für die betreffende Anwendung zu groß ist (Schaltkreis zu teuer) oder daß er nicht genug leistet (aufwendige Zusatzhardware erforderlich).
Um diese Nachteile zu vermeiden, kann man Ressourcenzellen vorsehen, die Verarbeitungsschaltungen und eine gewisse Speicherausstattung umfassen. Die Ressourcenzellen sind hart aufgebaut (sie bestehen nicht aus programmierbaren Logikzellen, sondern aus zweckgerecht verschalteten Transistoren bzw. Gattern). Einstellbar sind lediglich Funktionsweise und Verarbeitungsbreite. Als Ausführungsbeispiel sei eine gemäß 59 aufgebaute Ressourcenzelle mit folgenden Merkmalen angenommen:

a) Funktionsweise: Arithmetik-Logik-Einheit (ALU),
b) Verarbeitungsbreite: einstellbar (maximal 32 Bits),
c) Verkettung: wird für alle Parameter unterstützt,
d) Speicherausstattung: 1k Worte zu 32 Bits.

Die programmierbaren Verbindungswege sind für typische Nutzungsweisen der Ressourcen optimiert (sie können vergleichsweise einfach ausgelegt werden, da es nicht erforderlich ist, x-beliebige Verbindungen zwischen allen Zellen auf dem Schaltkreis zu unterstützen). Die 72 bis 78 zeigen verschiedene Anordnungen von Ressourcenzellen. Solche Anordnungen können sowohl in programmierbaren als auch in anwendungsspezifischen Schaltkreisen untergebracht werden.
72 veranschaulicht die Anordnung von Ressourcenzellen auf einem Schaltkreis. Die Ressourcenzellen sind über Bussysteme untereinander verbunden. Jedes Bussystem ist in der Lage, eine zeilenförmige Anordnung von Ressourcenzellen mit Parametern zu versorgen und die Ergebnisse der jeweils darüberliegenden Ressourcenzellen-Zeile abzutransportieren. Die Bussteuerung stellt die Verbindung zwischen den einzelnen Bussystemen her. Auf dem Schaltkreis sind weiterhin eine gemeinsame Speicherausstattung sowie die Schaltmittel der Plattform angeordnet.
73 zeigt, wie eine solche Anordnung mit externen Speichern erweitert werden kann. Oft braucht man sehr große Speicherkapazitäten (Mega ... Gigabytes). Es ist dann von Vorteil, auf das Angebot des Massenmarktes zurückzugreifen und (außerhalb des FPGA-Schaltkreises) kostengünstige Speicherschaltkreise (z. B. DDR-DRAMs) bzw. Speichermoduln einzusetzen. Die erforderliche Speichersteuerung ist hart aufgebaut.
74 veranschaulicht eine Alternative zur Verbindung über Busstrukturen: die Verschaltung von Ressourcenzellen als invertierte Baumstrukturen (Im Beispiel: als Binärbäume). Die Auswerung geschachtelter (geklammerter) Ausdrücke läßt sich gut auf invertierte Baumstrukturen abbilden (vgl. 54). Der Vorteil: die Verbindungen zwischen den Zellen der Baumstruktur sind einfache Punkt-zu-Punkt-Verbindungen. Sie sind kurz (also schnell durchlaufen) und brauchen keine Programmiervorkehrungen auf dem Schaltkreis. Um die Schaltkreisfläche gut auszunutzen, werden gemäß 75 zwei Baumstrukturen gegenläufig angeordnet. Zum Einspeisen der Operanden und zum Abholen der Ergebnisse sind zwei Bussysteme vorgesehen. Die Ein- und Ausgänge der aufeinanderfolgend angeordneten invertierten Baumstrukturen werden umschichtig an beide Bussysteme angeschlossen (das erste Bussystem ist mit den Operandeneingängen der ersten und den Ergebnisausgängen der zweiten Baumstruktur beschaltet, das zweite Bussystem mit den Operandeneingängen der zweiten und den Ergebnisausgängen der ersten Baumstruktur usw.). Infolge der umschichtigen gegenläufigen Anordnung wird jedes der Bussysteme in gleicher Weise zu Schreib- und Lesezugriffen ausgenutzt (gleichmäßige Lastverteilung). Auch in elektrischer Hinsicht werden beide Bussysteme gleichmäßig belastet (gleiche Anzahl an jeweils angeschlossenen Empfängern und Treibern).
Eine tiefe Baumstruktur kann nicht immer sinnvoll ausgenutzt werden. Ist die Schachtelungstiefe (Nesting Depth) der Verarbeitungsvorgänge nicht allzu groß, ist eine Kombination zwischen Baumstruktur und Stack von Vorteil. Die letzte Verarbeitungseinrichtung der Baumstruktur bezieht einen ihrer Operanden aus dem Stack und legt auch ihre Ergebnisse im Stack ab. Um die Stackzugriffe zu beschleunigen, wird für jede Baumstruktur ein Stack Cache vorgesehen. Dieser kann z. B. gemäß 76 als herkömmliche Cache-Anordnung ausgebildet sein, die von einem Stackpointer auf bekannte Weise adressiert wird. 77 zeigt, daß durch gegenläufige Anordnung solcher Baumstrukturen (vgl. 75) die Schaltkreisfläche gut ausgenutzt werden kann. Die Freiflächen in 77 ergeben sich lediglich als Folge der unmaßstäblichen Darstellung. Sollten sie in der Praxis tatsächlich auftreten, können sie z. B. ausgenutzt werden, um die Stack Caches zu vergrößern.
Zur Nutzung derartiger Schaltkreise:

1. das Anwendungsproblem wird mit geeigneten Mitteln beschrieben (graphische Darstellungen, Zustandsdiagramme, Programmiersprachen),
2. die Entwicklungsumgebung erzeugt daraus einen entsprechenden Code (der Ressourcen anfordert, mit Parametern versorgt usw.),
3. demgemäß wird ein Schaltkreis mit passender Ressourcenausstattung gewählt, und der Code wird entsprechend abgewandelt.

Herkömmlicherweise muß der Entwickler entscheiden, welche Funktionen er mittels Software (auf einem eingebauten Prozessor) und welche er mittels Hardware (= programmierbarer Logik) löst. Hier entfällt diese Trennung. Vielmehr wird von der Entwicklungsumgebung sowie – zur Laufzeit – von der eingebauten Plattform eine jeweils zweckgerechte Ressourcen-Konfiguration erzeugt und bedarfsweise dynamisch geändert (Prozessoren entstehen bei Bedarf (on the fly) und werden ggf. auch wieder abgebaut).
Universelle Hochgeschwindigkeitsinterfaces, die über Schaltverteiler miteinander verkoppelt werden, sind eine Alternative zu Busstrukturen. Sie werden u. a. in verschiedenen FPGA-Schaltkreisfamilien unterstützt. 78 veranschaulicht die Konfiguration eines Schaltkreises, dessen Ressurcenzellen 89 über Punkt-zu-Punkt-Interfaces an Verteiler 90 angeschlossen sind, die ihrerseits überprogrammierbare (globale) Signalwege 91 untereinander verbunden sind.
Universelle harte Ressourcen (z. B. ALU-Strukturen) sind für manche Anwendungsaufgaben nicht geeignet. Deshalb ist es oftmals zweckmäßig, nicht den gesamten Schaltkreis mit harten Ressourcenzellen zu belegen (z. B. gemäß 72), sondern Bereiche mit herkömmlichen programmierbaren Logikzellen vorzusehen, um bedarfsweise x-beliebige Verarbeitungs- und Steuerschaltungen aufbauen zu können. Solche Anordnungen können aber nicht ohne weiteres mit den anderen (harten) Ressourcen zusammenwirken. Deshalb werden diese Zellenbereiche mit harten Schnittstellen umgeben, die denen der harten Ressourcenzellen entsprechen (Parameterregister, Verkettungshardware, Bus-Interfaces usw.).
79 zeigt eine entsprechende programmierbare (weiche) Ressourcenzelle 92, die aus programmierbaren Logikzellen mit programmierbaren Verbindungen aufgebaut ist. Deren Eingänge sind über programmierbare Signalwege 93 eingangsseitigen harten Ressourcenschnittstellen 94 nachgeschaltet (z. B. einigen Operandenregistern). Sinngemäß sind die Ausgänge über programmierbare ausgangsseitige Signalwege 95 an harte ausgangsseitige Ressourcenschnittstellen 96 angeschlossen, z. B. an einige Ergebnisregister und an ein Bedingungsregister. Solche weichen Ressourcenzellen werden wie die harten Ressourcenzellen mit den Signalwegen des Schaltkreises verbunden, z. B. an die in 72 dargestellten Bussysteme (die Eingänge der Operandenregister (Ressourcenschnittstellen 94) werden gemäß 72 an das jeweils obere Bussystem angeschlossen, die Ausgänge der Ergebnisregister (Ressourcenschnittstellen 96) an das jeweils untere). Sämtliche Register der Ressourcenschnittstellen 94, 96 sind mit entsprechenden Zugriffs- und Verkettungsvorkehrungen versehen (Zustandsregister, Zeigerregister, Verkettungssteuerschaltungen usw.; vgl. die 49, 51 und 56). Da es sich um harte Schaltungen handelt, benötigen diese Zusätze nur vergleichsweise wenig Schaltkreisfläche.
Es gibt FPGA-Schaltkreise, in denen die Programmierdaten der Logikzellen und der verbindenden Signalwege in RAM-Strukturen gehalten werden. Sie werden herkömmlicherweise nach jedem Einschalten neu programmiert (durch Eintragen der RAM-Belegungen), und zwar vor Aufnahme des eigentlichen Betriebs. Während des Betriebs (zur Laufzeit) ist ein Umprogrammieren nicht möglich. Mit harten Ressourcenzellen ausgerüstete Schaltkreise kann man hingegen so auslegen, daß sich auch zur Laufzeit umprogrammieren lassen (da die aus harten Zellen bestehende Struktur – z. B. gemäß 72 – bestehen bleibt, während die weichen Zellen umprogrammiert werden). Das Umprogrammieren kann durch s-Operatoren (Ressourcenbereitstellung), u-Operatoren (Ressourcenverwaltung) sowie c- und d-Operatoren (Verkettung) veranlaßt werden. Hierzu sind die Programmiersignalwege der betreffenden weichen Zellen an entsprechende harte Strukturen anzuschließen, z. B. an eine Plattformeinrichtung (die auf dem Schaltkreis oder außerhalb des Schaltkreises angeordnet sein kann).
Nachfolgend soll anhand der 80 bis 85 ein Überblick über die Ressourcenverwaltung gegeben werden. Sowohl zur Compilierzeit als auch zur Laufzeit ist es manchmal erforderlich, die in erfindungsgemäßen Systemen vorhandene Ressourcen zu verwalten. Hierzu braucht man Übersichten über:

a) die im System verfügbaren Ressourcentypen,
b) die Eigenschaften der einzelnen Ressourcentypen,
c) die Zustände der vorhandenen Ressourcen (wieviele je Typ vorhanden sind, wieviele davon noch verfügbar sind usw.),
d) die dem einzelnen laufenden Programm (Task, Prozeß o. dergl.) zugeordneten Ressourcen.

Es liegt nahe, diese Angaben in Tabellenstrukturen unterzubringen. Ähnliche Aufgaben gibt es beim Verwalten eines virtuellen Speichers, in Dateisystemen, beim Compilieren von Programmen usw. Der Aufbau von Tabellenstrukturen und die entsprechenden Zugriffsverfahren gehören zum allgemeinen Fachwissen der Informatik. Deshalb genügt eine knappe Beschreibung anhand von Beispielen. Tabelleneinträge können auf verschiedene Art erreicht werden:

1. über einen Namen (Zeichenkette),
2. über eine laufende Nummer (Ordinalzahl),
3. über eine Adreßangabe.

Die folgende Beschreibung bezieht sich auf den Zugang über die laufenden Nummern (Ordinalzahlen) der Einträge. Diese Art des Zugangs ist nur geringfügig langsamer als die direkte Adressierung (es genügt eine einfache Umrechung, um aus der Ordinalzahl die Adresse zu ermitteln). Die Tabellenstrukturen können ohne weiteres ergänzt werden, um den Zugang über Namen zu unterstützen. Einschlägige Verfahren gehören zum allgemeinen Fachwissen der Informatik; entsprechende Funktionen sind in jedem Assembler oder Compiler vorgesehen. Sie müssen deshalb nicht näher beschrieben werden. Es gibt drei Arten von Tabellen: die Ressourcenvorratstabelle (eine im System), die – bedarfsweise vorzusehende – Ressourcenvorratstabelle (eine je Ressourcentyp) und die Prozeßressourcentabelle (eine in jedem laufenden Programm (Prozeß)).
Die Ressourcentyptabelle enthält die beschreibenden und die Verwaltungsangaben zu den einzelnen Ressourcentypen. Sie hat einen Eintrag je Ressourcentyp. Ein solcher Eintrag enthält:

a) eine allgemeine Typkennung,
b) Angaben zu den Parametern (Operanden und Ergebnissen),
c) Verwaltungsangaben.

Die Angaben zu den Parametern enthalten:

a) die Anzahl der Parameter,
b) eine Beschreibung jedes einzelnen Parameters.

Die Verwaltungsangaben umfassen:

a) die Anzahl der insgesamt vorhandenen Ressourcen des jeweiligen Typs,
b) die Anzahl der aktuell verfügbaren Ressourcen,
c) den Zustand jeder einzelnen Ressource. Im einfachsten Fall genügt ein Bit je Ressource, um zwischen den Zuständen „frei" und „besetzt" zu unterscheiden. Manchmal ist es von Vorteil, eine Verweisangabe auf das Programm (den Prozeß) mitzuführen, in dem die Ressource zur Zeit genutzt wird.

Die Verwaltung der Ressourcen entspricht weitgehend den Verwaltungsfunktionen, die in einem Dateisystem oder einer virtuellen Speicherorganisation erforderlich sind. Das betrifft z. B. das Auffinden eine geeigneten freien Ressource bei der Ausführung eines s-Operators. Entsprechende Prinzipien gehören zum allgemeinen Fachwissen der Informatik.
Jeder Parameter wir durch folgende Angaben beschrieben:

a) eine Typkennung,
b) die Art des Parameters (Operand, Ergebnis oder beides),
c) Angaben zur Verkettungssteuerung,
d) die Länge in Bits.

Ggf. erforderliche Arbeitsbereiche der Ressourcen werden mit besonderen Parameterangaben beschrieben (an der Typkennung erkennbar).
80 gibt einen Überblick über den Inhalt einer Ressourcentyptabelle:

a) die Ressourcentyptabelle insgesamt. Jeder Ressourcentyp hat einen Eintrag.
b) der Inhalt eines Eintrags: Typkennung (eine Art Eigenname), Beschreibung der Parameter, Verwaltungsangaben.
c) elementare Verwaltungsangaben betreffen die Anzahl der vorhandenen Ressourcen dieses Typs und geben Auskunft darüber, welche dieser Ressourcen im Moment verfügbar sind. Das ist beispielsweise in einer Bitliste vermerkt (ein Bit je Ressource).
d) die Parameterbeschreibung insgesamt. Jeder Parameter hat einen Eintrag.
e) der Inhalt eines Eintrags: Typkennung (elementare Typen sind z. B. Binär- und Gleitkommazahlen), Art des Parameters, Länge des Parameters, Strukturbeschreibung (bedarfsweise). Die Länge wird zunächst pauschal in Bits angegeben, unabhängig von der Struktur. Das unterstützt erste Entscheidungen zur Bereitstellung von Speicherplatz, zum Transport über Bussysteme und Interfaces usw. (alle Parameter sind letzten Endes Bitketten, die transportiert und gespeichert werden müssen). Kompliziertere Parameter haben zusätzlich eine Strukturbeschreibung.
f) so wird die Art des Parameters beschrieben: je ein Bit für die grundsätzliche Nutzungsweise (Eingang und Ausgang) sowie eine Verkettungsangabe (kennzeichnet, ob eine Verkettung überhaupt möglich ist und gibt die Art der Verketung an).

Da die Ressourcen unterschiedlich aufgebaut sind, ergeben sich verschieden lange Tabelleneinträge. In der Informatik gibt es vielfältige Lösungen des Problems, solche Tabellen in praktisch handhabbaren Datenstrukturen unterzubringen. Deshalb genügt hier die Kurzbeschreibung einer beispielhaften Ausführung.
Die Tabellen bestehen aus aus einem Kopf, der je Tabelleneintrag eine fest formatierte Angabe enthält. Diese Tabelleneinträge können direkt adressiert werden. Dem Tabellenkopf folgt ein variabler Teil, in dem die verbleibenden Angaben untergebracht werden. Jeder Eintrag im Tabellenkopf enthält einen Zeiger, der auf den zugehörigen Bereich im variablen Teil verweist. Am Anfang dieses Bereichs steht ein Rückverweis auf den Tabellenkopf, um die Verwaltung des variablen Teils zu unterstützen (81, 82).
81 zeigt ein Beispiel für die entsprechende Formatierung einer Ressourcentyptabelle:

a) die Tabellenstruktur insgesamt,
b) ein Eintrag im Tabellenkopf. Im Beispiel enthält er lediglich einen Deskriptor, der den zugehörigen Bereich im variablen Teil beschreibt (Adreßzeiger, Längenangabe). Andere Implementierungen können weitere fest formatierte Angaben enthalten, z. B. zur Anzahl und zur Verfügbarkeit der Ressourcen.
c) so sieht ein Bereich im variablen Teil aus. Er enthält die weiteren Angaben zum Ressourcentyp (vgl. 80).

Die Parametereinträge können zusätzliche Angaben enthalten, die die Ressourcennutzung und Verwaltung unterstützen. Im folgenden werden anhand von 82 zwei Beispiele – Funktions- und Erreichbarkeitsangaben – kurz erläutert.
Funktionsangaben dienen dazu, universelle, für mehrere Funktionen geeignete Ressourcen auf die jeweils geforderte Funktion einzustellen. Es gibt zwei Prinzipien der Funktionseinstellung:

a) die universelle Ressource wird mittels s-Operator angefordert und durch Eintragen entsprechender Steuerangaben (z. B. mit p- oder mit u-Operatoren) auf die jeweilige Funktion eingestellt. Beispiel: es wird eine universelle ALU angefordert und mittels p-Operator auf 16 Bits Arbeitsbreite und auf Addition eingestellt.
b) die einzelnen funktionellen Varianten werden als gesonderte Ressourcen verwaltet. Es gibt z. B. 8-Bit-Addierwerke, 16-Bit-Addierwerke usw. als jeweils eigene Ressourcentypen. Wird mittels s-Operator z. B. ein 16-Bit-Addierwerk angefordert, so wird eine universelle ALU bereitgestellt und automatisch (als Zusatzwirkung des s-Operators) als 16-Bit-Addierwerk konfiguriert.

Im zweiten Fall ist zwischen logischen und physischen Ressourcen zu unterscheiden. Beide Arten werden in der Ressourcentyptabelle geführt. Fordert der s-Operator eine logische Ressource an (z. B. einen 32-Bit-Addierer), so trifft er auf einen Eintrag, der zur jeweiligen physischen Ressource verweist (z. B. auf eine universelle 64-Bit-ALU). Dieser Verweis ist in den Funktionsangaben untergebracht. Dort ist auch angegeben, auf welche Weise die physische Ressource zu konfigurieren ist (z. B. durch Funktionscodes, die in bestimmte Register zu laden sind).
Erreichbarkeitsangaben betreffen besondere Abläufe, die erforderlich sind, um Parameter in die Ressourcen zu übertragen oder von dort abzuholen. Die jeweiligen Operatoren (p, a, l) müssen je nach Ressource und Parameter unterschiedliche Steuerwirkungen veranlassen (z. B. Bussysteme aktivieren, Register adressieren usw.). Das gilt sinngemäß für die Verkettungsabläufe. EinschlägigeAngaben können in der Ressourcentyptabelle mitgespeichert werden. Es kann sich dabei u. a. handeln um:

a) Zugriffssteuerworte, Mikrobefehle oder Mikrobefehlsfolgen, die bestimmte Signalflüsse in der Hardware steuern,
b) Folgen elementarer Maschinenbefehle (Transportroutinen),
c) Zeiger auf entsprechende Transportroutinen,
d) Adreßangaben (z. B. mit Busadressen der Hardware).

Erforderlichenfalls kann für jede Zugriffsart (p-Operatoren, a-Operatoren, l-Operatoren, Verkettung) eine besondere Angabe vorgesehen sein.
Es kann vorkommen, daß jede einzelne Ressource auf eigene Weise erreichbar ist (z. B. unter speziellen Adressen), daß also nicht alle Ressourcen eines Typs gleichsam pauschal behandelt werden können. Dann kann es zweckmäßig sein, je Ressourcentyp zusätzlich eine Ressourcenvorratstabelle zu führen, die die entsprechenden Angaben zu jeder einzelnen Ressource enthält. Prinzip:

a) die pauschalen Parameterbeschreibungen (Art, Länge usw.) stehen in der Ressourcentyptabelle,
b) die Zustands- und Erreichbarkeitsangaben stehen in der Ressourcenvorratstabelle. Sie können ggf. durch zusätzliche Verwaltungsgaben ergänzt werden (die Aufschluß über die Nutzungshäufigkeit, die Anzahl der Zugriffe usw. geben).

Manche Ressourcen werden aus anderen Ressourcen aufgebaut (Rekursion), manche sind gar nicht als Hardware vorhanden. Ihre Funktionsweise wird vielmehr programmseitig nachgebildet (Emulation, Simulation). Zudem können Ressourcen auf entsprechenen programmierbaren Schaltkreisen bedarfsweise erzeugt werden. Die hierzu erforderlichen Angaben können z. B. gemäß 83 in der Ressourcentyptabelle untergebracht werden. 83 zeigt einen Eintrag im variablen Bereich einer Ressourcentyptabelle gemäß den 81 und 82. Der Eintrag ist um einen Bereich verlängert, der den Operatorcode zum Aufbauen der Ressource aus einfacheren Ressourcen (Rekursion), ein Maschinenprogramm (Emulation) oder eine entsprechende Schaltungsbeschreibung (Netzlisten, Boolesche Gleichungen o. ä.) enthält. Die Verwaltungsangaben der betreffenden Ressourcentypen enthalten einen Deskriptor, der diesen Bereich beschreibt (Anfang, Länge). Die hierin gespeicherten Operatorcodes, Maschinenprogramme usw. sind typischerweise eine Art Muster mit Platzhaltern, die bedarfsweise mit Ressourcennummern oder Adressen gefüllt werden (maschinenunabhängige bzw. „logische" Codierung). Beispiel: eine Ressource wird aus vier anderen Ressourcen aufgebaut. Der gespeicherte Operatorcode spricht diese Ressourcen über laufende Nummern 1, 2, 3, 4 an. Nun soll eine solche Ressource tatsächlich aufgebaut werden. Als Bausteine stehen die Ressourcen Nr. 11, 19, 28 und 53 zur Verfügung. Die Operatoren müssen dann statt Ressource 0 Ressource 11 ansprechen usw. (Ersatz der „logischen" durch „physische" Ressourcennummern). 84 zeigt eine Ressourcenvorratstabelle in Zusammenhang mit der Ressourcentyptabelle:

a) Ressourcentyptabelle ähnlich 81,
b) zu verschiedenen Ressourcentypen gibt es jeweils eine Ressourcenvorratstabelle, die individuelle Angaben zu den einzelnen Ressourcen enthält,
c) die Einträge im Kopf der Ressourcentyptabelle enthalten zwei Deskriptoren, einen für den Bereich im variablen Teil der Ressourcentyptabelle und einen für die zugehörige Ressourcenvorratstabelle.

Die Prozeßressourcentabelle beschreibt die vom jeweiligen laufenden Programm (Prozeß, Task o. dergl.) angeforderten Ressourcen (85). Jede dieser Ressourcen hat einen Eintrag. Dieser enthält:

a) den Ressourcentyp (Rückverweis),
b) die Ordinalzahl (laufende Nummer) der Ressource des betreffenden Typs,
c) eine Erreichbarkeitsangabe. Im einfachsten Fall ist dies eine Speicher- oder Hardwareadresse. Es kann sich aber auch um Mikrobefehle, Zeiger auf Transportroutinen usw. handeln. Solche Angaben werden – als Wirkung des s-Operators – aus der Ressourcentyptabelle oder aus der Ressourcenvorratstabelle übernommen, wobei sie ggf. abgewandelt werden (indem beispielsweise logische Adressen durch physische ersetzt werden).

Bei einer Softwarelösung (Emulation) ist die Erreichbarkeitsangabe typischerweise ein Zeiger in den Ressourcenemulationsbereich. Das ist der Speicherbereich, der die Parameter sowie ggf. erforderliche Arbeitsbereiche aufnimmt (vgl. 5). Oft genügt ein einziger Zeiger, weil die Parameter fortlaufend adressiert werden. Manchmal ist aber eine gesonderte Zeigerangabe je Parameter erforderlich.
Die Tabellen werden typischerweise folgendermaßen genutzt: Der s-Operator geht in die Ressourcentyptabelle und findet dort eine verfügbare Ressource. Dieser Ressource wird eine laufende Nummer (Ordinalzahl) zugeordnet. Ggf. werden verschiedene Einstellungen vorgenommen (Funktion, Verarbeitungsbreite usw.). Die für die weiteren Operatoren erforderlichen Angaben werden in die Prozeßressourcentabelle übernommen. Die laufende Nummer dieses Eintrags ergibt eine weitere Ordinalzahl, mit der sich alle anderen Operatoren auf diese Ressource beziehen.
Beispiel:

1. es wird ein 16-Bit-Addierer benötigt. Aufruf s (ADD_16). Dieser Ressourcentyp habe die Ordinalzahl 25. Also lautet der s-Operator im symbolischen Maschinencode s(25).
2. der s-Operator findet die Ressource Nr. 6 dieses Typs als verfügbar vor,
3. die Ressource wird als belegt gekennzeichnet. Ggf. wird die Ressource durch Eintragen von Funktionseinstellungen für die geforderte Verarbeitungsfunktion eingerichtet.
4. die Ressource wird in die nächste freie Position der jeweiligen Prozeßressourcentabelle eingetragen (Ressourcentyp 25, Ressource Nummer 6 usw.). Die 11. Position der Prozeßressourcentabelle sei frei. Somit wird der Ressource die Ordinalzahl 11 zugeordnet.
5. alle p-Operatoren, y-Operatoren usw. beziehen sich auf Ressource Nr. 11 und greifen mit diesem Wert auf die Prozeßressourcentabelle zu, um physische Adressen und andere Erreichbarkeitsangaben zu erhalten.

In der Praxis finden diese Abläufe typischerweise zur Compilier- und (teilweise) zur Ladezeit statt. Lauffähige Maschinenprogramme enthalten physische Ressourcenadressen und andere Erreichbarkeitsangaben; sie müssen nicht mehr auf Tabellen zugreifen.
Bei softwareseitiger Emulation läuft die Adreßauflösung zur Compilierzeit folgendermaßen ab: Der s-Operator geht in Ressourcentyptabelle und holt dort den Speicherbedarf (im Ressourcenemulationsbereich). Die Prozeßressourcentabelle wird nur temporär beim Compilieren verwendet. Die Operation wird im Ressourcenemulationsbereich gespeichert. Zugriffe zur Laufzeit erfolgen nur über "gewöhnliche" (= vom Compiler festgelegte) Adressen (alle Zugriffe zur Laufzeit beziehen sich auf Adressen im Ressourcenemulationsbereich). Der Ressourcenemulationsbereich kann ggf. in Hardware-Registern angelegt werden.
Es gibt Varianten des s-Operators, über die ganz bestimmte Ressourcen angesprochen werden können, z. B. Rechenwerk Nr. 22 oder Spezialprozessor MAX über IP-Adresse 123.45.67.89.
Um die Formate der Tabellenstrukturen, beschreibenden Angaben usw. festlegen zu können, muß man wissen, mit welchen Anzahlen an Ressourcen, Parametern usw. zu rechnen ist. Erfindungsgemäße Systeme unterscheiden sich u. a. dadurch, wieviele Ressourcen jeweils zur Verfügung stehen. Es gibt folgende grundsätzliche Auslegungen:

1. finit. Es handelt sich um eine feste Anzahl, die für eine bestimmte Implementierung gilt. Beispiel: ein Prozessor mit 16 Verarbeitungswerken. Somit können nicht mehr als 16 Verarbeitungsressourcen gleichzeitig vergeben werden.
2. transfinit. Die Anzahl der Ressourcen wird lediglich beschränkt durch die Grenzen des Adressierungsvermögens der beschreibenden Datenstrukturen.

Werden Ressourcen softwareseitig nachgebildet (Emulation), so kann die Anzahl im Grunde transfinit sein; sie ist nur durch die Größe des verfügbaren Speichers (Ressourcenemulationsbereich) beschränkt; s- und r-Operatoren steuern lediglich die Belegung des Emulationsbereichs. Der einschlägige Verwaltungsaufwand ist Ermessenssache. Es geht hierbei um das in der Informatik wohlbekannte Problem der Freispeicherverwaltung einschließlich der sog. Garbage Collection, also darum, stückweise freigegebene Speicherbereiche wieder zur Nutzung bereitzustellen oder durch entsprechende Datentransporte einen einzigen zusammenhängenden freien Bereich zu schaffen. Eine Verwaltungsstrategie könnte darin bestehen, auf eine Freispeicherverwaltung zunächst zu verzichten, also mit jedem s-Operator nur bisher freien Speicher zu vergeben und die Wirkung der r-Operatoren auf ein bloßes Vermerken der freigegebenen Speicherbereiche zu beschränken. Eine Garbage Collection findet lediglich an markanten Punkten im Programmablauf statt, beispielsweise dann, wenn ein bestimmter Programmzweig wirklich zu Ende gekommen ist und nicht erneut durchlaufen wird. Die Freispeicherverwaltung könnte hierbei z. B. durch entsprechende h- und u-Operatoren unterstützt werden.
Werden Ressourcen tatsächlich als Hardware aufgebaut, so ist deren Anzahl letzten Endes finit. Jede einzelne Ressource muß verwaltet werden (zumindest ist zu konstatieren, ob sie verfügbar ist oder nicht).
Es folgen einige Beispiele für Adreßlängen, Anzahlen usw., mit denen in der Praxis zu rechnen ist:

a) Analogie zur herkömmlichen Superskalarmaschine: 1) 64 ... 256 Ressourcentypen (= Hardware zum Ausführen von Maschinenbefehlen), 2) maximal 4 ... 8 Parameter. Einfache Operationen erzeugen aus 2 Operanden ein Ergebnis zuzüglich einer Zustandsmeldung (Flagbits). Manche Operationen, die man üblicherweise als elementar ansieht, brauchen einge Parameter mehr. Das betrifft z. B. die Multiplikation und Divison von Binärzahlen (vgl. 48 und Tabelle 2). 3) 16 ... 256 aktive Ressourcen (herkömmliche Superskalarmaschinen haben typischerweise 4 ... 16). Künftige Großschaltkreise können beispielsweise 4 ... 16 herkömmliche Prozessoren aufnehmen, deren Ressourcenausstattung jeweils 4 ... 16 Verarbeitungswerken entspricht (vgl. weiter unten die Erläuterungen zu den 111 und 112).
b) massive Parallelverarbeitung mit herkömmlichen Operationen: 1) 64 ... 256 Ressourcenarten (= Hardware zum Ausführen von Maschinenbefehlen), 2) maximal 4 ... 8 Parameter (vgl. obigen Punkt 2), 3) Anzahl der aktiven Ressourcen: transfinit (Richtwerte: 1k ... 64k).
c) Emulation: 1) Anzahl der Ressourcenarten: transfinit, 2) Anzahl der aktiven Ressourcen: transfinit, 3) Parameter: verschiedene Stufen, z. B. 4, 8, 16, 32, 64, 512, 4k, transfinit. Erfahrungstatsache: mehr als 4k Parameter kommen praktisch nicht vor; die weitaus meisten Funktionen haben weniger als 64 Parameter.

Transfinit bedeutet hier, daß mit der vollständigen Ausnutzung des Wertebereichs bzw. Adreßraums gemäß Verarbeitungsbreite zu rechnen ist, also 2¹⁶ bei einer 16-Bit-Maschine, 2³² in einer 32-Bit-Maschine usw. In maschinenunabhängigen Codierungen ist die volle Bitanzahl gemäß Verarbeitungsbreite bzw. Adreßraum anzusetzen (16, 32, 64 Bits usw.). Maschinenspezifische Codes hingegen dürfen entsprechende Einschränkungen aufweisen (z. B. 40 statt 64 Adreßbits).
Es folgt ein Überblick über weitere Probleme der Ressourcenverwaltung.

1. Numerierung der Ressourcen. Die Ressourcennummern (Ordinalzahlen) werden beim Auswählen der Ressourcen (s-Operator) zugeordnet. Alle weiteren Operatoren beziehen sich dann auf diese zugeordneten Nummern. Typische Probleme der Zuordnung: a) die Nutzung der Ressourcennummern als Adressen (bzw. Umwandlung dieser Nummern in Adressen oder in andere hardwareseitige Erreichbarkeitsangaben, z. B. in Zugriffssteuerworte), b) die Behandlung von Ressourcen, die zwischenzeitlich zurückgegeben werden (r-Operator). Es sind verschiedene Verfahren nutzbar: a) die Ressourcen werden beim Auswählen aus dem Ressourcenvorrat (s-Operatoren) fortlaufend durchnumeriert, b) die Numerierung kann mit u-Operatoren gesteuert werden (z. B. durch Einstellen eines Anfangswertes), c) die Ordinalzahl- oder Adreßangaben werden in die s-Operatoren aufgenommen (s_a-Operatoren): s_a (Ressourcentyp => Ressourcennummer bzw. Adresse).
2. Numerierung und Freigabe (r-Operator). Es ist typischerweise unzweckmäßig, auf jede Freigabe durch Umstellen der Numerierung zu reagieren (Verwaltungsaufwand). Die Alternative: die Durchnumerierung in den s-Operatoren wird fortgesetzt, unabhängig davon, ob zwischenzeitlich Ressourcen freigegeben werden oder nicht. Freigegebene Ressourcen können ohne weiteres neu zugewiesen werden; sie erhalten dann lediglich höhere laufende Nummern (Ordinalzahlen). Die Numerierung beginnt nur dann von neuem, wenn die aktuelle Ressourcenzuweisung komplett aufgelöst wurde (z. B. am Programmende).
3. Ressourcen auf- und abbauen. Es bringt offensichtlich keine Vorteile, Ressourcen einzeln anzufordern, zu benutzen und sofort wieder freizugeben. Um den inhärenten Parallelismus maximal auszunutzen, wäre es am besten, alle zu einem bestimmten Programmablauf benötigten Ressourcen auf einmal anzufordern und – soweit möglich -parallel zu betreiben (das Programm beginnt mit einem s-Operator, der alle benötigten Ressourcen anfordert und endet mit einem r-Operator, der alle Ressourcen freigibt). Das ist aber nicht immer durchführbar (begrenzte Anzahl an Hardware-Ressourcen, begrenzte Speicherkapazität). Deshalb ist die Ressourcennutzung gleichsam stückweise zu organisieren. Übliche Trennstellen, an denen ein komplexes Progamm in überschaubare Abläufe zerlegt werden kann, sind u. a.: a) einzeln compilierte Programmstücke einschließlich der darin aufgerufenen Funktionen, b) reguläre Programmkonstrukte (Fallunterscheidungen, Schleifen usw.), c) Programmblöcke (das, was in üblichen Programmiersprachen zwischen BEGIN und END oder zwischen geschweiften Klammern steht) einschließlich der darin aufgerufenen Funktionen, d) Basisblöcke (lineare Folgen von Datentransporten und Verknüpfungen; ein Basisblock endet mit einer Verzweigung oder mit einem Funktionsaufruf). Basisblöcke in herkömmlichen Maschinensprachen umfassen typischerweise weniger als 10 Befehle. Für das jeweilige Programmstück werden alle Ressourcen angefordert, genutzt und wieder freigegeben. Ein einfaches Zuordnungsverfahren besteht darin, zunächst mit den Basisblöcken zu beginnen. Sind noch Ressourcen frei, nachdem der aktuelle Basisblock versorgt wurde, kann z. B. die nachfolgend aufgerufene Funktion berücksichtigt werden usw.

Nachfolgend werden anhand der 86 bis 95 nähere Einzelheiten der Ressourcenadressierung erläutert. Es entspricht dem Stand der Technik, nur zur Compilierzeit mit Ordinalzahlen, zur Laufzeit aber mit Adreßangaben zu arbeiten. In Byte- und Maschinencodes sind Ressourcen und deren Parameter zu adressieren. Es stehen zwei Auslegungen zur Wahl ( 86):

a) geteilter Ressourcenadreßraum: unabhängige Adreßangaben für die Ressourcen und für die Parameter innerhalb der Ressource,
b) flacher Ressourcenadreßraum: eine einzige Adreßangabe, die auf einen bestimmten Parameter innerhalb einer bestimmten Ressource verweist.

86a veranschaulicht einen geteilten Ressourcenadreßraum. Es gibt zwei Angaben: die eine wählt die jeweilige Ressource aus (Ressourcenadresse) und die andere den Parameter innerhalb der Ressource (Parameteradresse).
Vorteile:

1. die meisten Ressourcen haben nur wenige Parameter (Richtwert: 3 ... 8). Wenn man die Ressourcenadresse entsprechend zwischenspeichert (z. B. in Zustandspuffern (Halteregistern)), müssen in vielen Operatoren nur die Parameteradressen mitgeführt werden (Verkürzung).
2. kürzere Adreßangaben in den y- und r-Operatoren,
3. vergleichsweise geringer Aufwand zur Adreßdecodierung im Innern der Ressource (vgl. die üblichen Lösungen in den gängigen Mikrocontrollern, Peripherieschaltkreisen usw.),
4. die Adressierung im Innern der Ressourcen ist unabhängig davon, welche anderen Ressourcen zu unterstützen sind.

Nachteile:

1. kompliziertere Maschinencodes (da zwei Adreßarten zu berücksichtigen sind),
2. es sind eigens Halteregister oder andere Zustandspuffer erforderlich,
3. Parameteradreßangaben müssen auch die Ressource mit den meisten Parametern unterstützen können. Kommen Ressourcen mit sehr vielen Parametern vor, wird die Parameteradresse lang, und zwar auch für all jene Ressourcen, die nur wenige Parameter haben. Sieht man – als Abhilfe – verschiedene Parameteradreßlängen vor, wird der Maschinencode komplizierter.

Zur Gestaltung der Parameteradresse im geteilten Ressourcenadreßraum stehen wiederum zwei Auslegungen zur Wahl:

1. getrennte Adressierung von Operanden und Ergebnissen. In Abhängigkeit vom jeweiligen Operator betrifft die Parameteradreßangabe entweder einen Operanden oder ein Ergebnis. In p-Operatoren werden Operanden adressiert, in a-Operatoren Ergebnisse. In l-, c- und d-Operatoren betrifft die jeweils erste Parameteradreßangabe ein Ergebnis, die jeweils zweite einen Operanden. Wird der Funktionscode bei der Ressourcenauswahl (s-Operator) eingerichtet, müssen die entsprechenden Speichermittel (z. B. Funktionscoderegister) nur in entsprechenden Befehlen bzw. u-Operatoren adressiert werden. Der y-Operator muß typischerweise nur die Ressource adressieren; eine Parameteradresse ist nicht erforderlich).
2. gemeinsame Adressierung von Operanden und Ergebnissen. Die Parameteradreßangabe betrifft alle Parameter.

Die getrennte Adressierung spart typischerweise ein Bit je Adreßangabe ein. Beispiel: es gibt höchstens 4 Operanden und 3 Ergebnisse. Die getrennte Adressierung erfordert 2 Bits, die gemeinsame 3 Bits. Dem steht gelegentlich ein höherer Aufwand in der Hardware gegenüber – es ist nicht nur die Adresse zu berücksichtigen, sondern auch die Art ihrer Nutzung (die z. B. in einem Bussystem über besondere Leitungen übermittelt werden müßte). Sonderfunktionen müßten ggf. im Maschinencode berücksichtigt werden (z. B. wären zur Unterstützung der Eingangsverkettung spezielle Varianten der c- und d-Operatoren vorzusehen).
Eine weitere Möglichkeit zur Codeverkürzung ergibt sich daraus, daß die Ressourcen typischerweise mehr Operanden-Parameter als Ergebnis-Parameter haben. Somit kann gelegentlich die Adreßlänge für Ergebnisse kürzer ausgelegt werden als für Operanden.
86b veranschaulicht einen flachen Ressourcenadreßraum. Es gibt einen einzigen Adreßraum, in dem jedem Parameter jeder Ressource eine bestimmte Adresse zugeordnet ist (fortlaufende Adressierung).
Vorteile:

1. einfacherer Maschinencode,
2. der einheitliche lineare Adreßraum ist ein seit langem bewährtes Architekturprinzip,
3. eine hinreichende Adreßlänge erlaubt es, beliebige Mischungen von Ressourcen mit beliebig vielen Parametern auf einfache Weise zu unterstützen.

Nachteile:

1. gelegentlich höherer Speicherbedarf für den Maschinencode (wegen der längeren Adreßangaben),
2. gelegentlich aufwendigere Adreßdecodierung (in der Hardware), da für jeden einzelnen Parameter die Adresse in voller Länge decodiert werden muß. Sieht man eine bereichsweise Adreßdecodierung vor, um die Decodier-Hardware zu vereinfachen (vgl. PCI-Bus), ergibt sich gelegentlich eine schlechte Ausnutzung des Adreßraums (was dazu zwingen kann, die Adresse nochmals zu verlängern).
3. gelegentliche Verwaltungsschwierigkeiten (Overhead), wenn Ressourcen zur Laufzeit ausgewählt und freigegeben werden (dynamische Ressourcenverwaltung).

Auslegungsbeispiele der Ressourcenadressierung:

a) es gibt nur Ressourcen mit vergleichsweise wenigen Parametern: geteilter Adreßraum,
b) es gibt nur gleichartige Ressourcen: geteilter Adreßraum oder Aktivierung über Zugriffssteuerworte (vgl. die weiter unten folgenden Erläuterungen anhand von 90),
c) gemischte Ressourcenbelegung (darunter Ressourcen mit vergleichsweise vielen Parametern): flacher Adreßraum.

Je nach Systemkonfiguration, Technologie und Einsatzfall ergeben sich verschiedene Größenordnungen der Ressourcenadreßräume (Tabelle 4 enthält einige Beispiele):

1. Systeme mit transfiniter Anzahl an Ressourcen (die sich ggf. in riesigen Anzahlen anfordern lassen). Vorzugsweise Nutzung: als fiktive Maschinen zur Programmentwicklung und -optimierung. Es geht darum, den inhärenten Parallelismus soweit wie irgend möglich zu erkennen (d. h. über das gesamte Programm hinweg ohne Beschränkung durch womöglich fehlende Hardware) und herauszufinden, wie sich eine konkete Architektur (mit beschränkter Ressourcenzahl (ggf. auch mit beschränkten Zugriffsmöglichkeiten (SIMD, VLIW usw.)) zweckmäßig ausnutzen läßt.
2. Systeme mit – letzten Endes – finiter (und technisch realisierbarer) Hardware-Ausstattung (z. B. auf FPGA-Schaltkreisen). Die Anzahl der Register kann bestimmte Größenordnungen nicht überscheiten. Handelt es sich um feste Konfigurationen, kann man auch die Registeradressen von Anfang an festlegen (vgl. die Registeradressierung in herkömmlichen Schaltkreisen). In weitgehend programmierbaren Konfigurationen kann man den Ressourcen besondere Konfigurationsregister zuordnen, über die die jeweiligen Adressen eingestellt werden (vgl. die Adressierung der Bussysteme mit Plug-and-Play-Unterstützung).
3. Realisierung mit Software (Emulation). Die Anzahl der Ressourcen kann beträchtlich sein (Frage der Programmoptimierung).

Tabelle 4
Anmerkungen zu Tabelle 4:

1) die Anzahl Bits, die in Maschinencodes zur Adreßcodierung erforderlich ist. Ergibt sich aus 1d Ressourcenanzahl (Ressourcenadresse) + 1d Parameteranzahl (Parameteradresse).
2) einfache Arithmetik-Logik-Einheiten (vgl. 47) haben nicht mehr als 3 Operanden (A, B, Funktionscode) und zwei Ergebnisse (C, Flags). Wird die Funktion bei der Ressourcenauswahl (s-Operator) fest eingerichtet, sind nur zwei Operanden (A, B) zu adressieren. Man kommt dann mit einem Bit bei getrennter und 2 Bits bei gemeinsamer Adressierung aus. Ist der Funktionscode als Parameter vorgesehen, sind bei gemeinsamer Adressierung 3 Bits erforderlich, bei getrennter 2 Bits für die Operanden und 1 Bit für die Ergebnisse. Zur Adressierung einer leistungsfähigeren Arithmetik-Logik-Einheit (vgl. 48) genügen typischerweise 3 Bits. Bei entsprechender Auslegung (Funktionscode ist kein Parameter, Verzicht auf einige der in Tabelle 2 genannten Speicherzugriffsoperationen) kommt man bei getrennter Adressierung mit jeweils 2 Bits aus (Operanden A, B, C, D; Ergebnisse X, Z, Flags).
3) durch ein weiteres Adreßbit können bis zu 16 Parameter adressiert werden. Das genügt für viele spezielle Verarbeitungseinheiten und für Ressourcen, die – ihrer Wirkung nach-typischen Funktionen in C-Programmen entsprechen (die weitaus meisten dieser Funktionen haben weniger als 16 Parameter).

Neben den Ressourcen und ihren Parametern sind die zu verarbeitenden Variablen zu adressieren. Die Variablen befinden sich typischerweise in den Speichereinrichtungen der Plattform. Sie werden als Operanden in die Ressourcen transportiert bzw. mit Ergebnissen der Ressourcen belegt. Solche Transporte werden von der Plattform ausgeführt (p- und a-Operatoren), können aber auch von entsprechenden Ressourcen erledigt werden. Üblicherweise genügt es, die Variablenadressierung seitens der Plattform so auszulegen, daß die in den Laufzeitsystemen der gängigen höheren Programmiersprachen üblichen Zugriffsprinzipen unterstützt werden (Adreßrechenschema Basis + Displacement, wobei als Basisadreßregister wenigstens ein Frame bzw. Base Pointer (FP/BP), ein Stackpointer (SP) und ein weiteres Zeigerregister vorgesehen sind).
Die hardwareseitige Ressourcenadressierung wird im folgenden anhand der 87 bis 90 näher erläutert. Jeder Parameter entspricht typischerweise einem Register. Adreßangaben sind im Grunde Ordinalzahlen (Auswahl des 1., 2., 3. Registers usw.). Oftmals genügt es, den einzelnen Registern feste Adressen zuzuweisen. Die Schaltungstechnik auf Grundlage von Adreßdecodern ist seit langem bekannt. Einfache Adreßdecoder können u. a. als mit den jeweiligen Adreßleitungen direkt oder invertiert beschaltete UND-Gatter oder als mit der zu erkennenden Adresse beschaltete Vergleicher ausgebildet sein (vgl. die E-A-Schaltungen der Mikroprozessoren, Steckkarten für Bussysteme usw.). Eine Alternative dazu ist die zentrale Adreßdecodierung in der Plattform. Alle Adreßdecoder sind in der Plattform angeordnet; die Übernahmesteuereingänge der eingangsseitigen und die Aufschalterlaubniseingänge der ausgangsseitigen Speichermittel in den Ressourcen sind an an die Adreßdecoder der Plattform angeschlossen.
87 veranschaulicht die Parameteradressierung in einer Hardware-Ressource. Zu jedem Parameterregister gehören ein Adreßvergleicher 97 mit vorgeordneter Adreßeinstellung 98. Hierbei handelt es sich um eine Festwerteinstellung oder um Adreßregister, die durch Konfigurationszugriffe ladbar sind. Die Ausgänge der Adreßvergleicher 97 sind an Übernahmesteuereingänge der Operandenregister bzw. an Aufschalterlaubniseingänge der Ergebnisregister angeschlossen. Die Zieladresse des Parameters, der überschrieben werden soll, wird auf den Operandenadreßbus gelegt, die Quelladresse des zu lesenden Parameters auf den Ergebnisadreßbus. Erkennt einer der Adreßvergleicher 97, daß die anliegende Adresse der eingestellten Adresse 98 entspricht, so wird die betreffende Zugriffsfunktion ausgeführt (Laden eines Operandenregisters vom Operandenbus, Aufschalten eines Ergebnisses auf den Ergebnisbus).
88 zeig den Parametertransport zwischen zwei Ressourcen anhand eines l-Operators. Die Ressourcen sind gemäß 87 ausgebildet. Das Ergebnis der Ressource B wird zum ersten Operanden der Ressource A (l-Operator). Der Ablauf im einzelnen:

a) die Quelladresse (SOURCE) wird auf auf den Ergebnisadreßbus gelegt. Der betreffende Adreßvergleicher 97 in Ressource B wird aktiv. Infolgedessen wird das Ergebnisregister auf den Ergebnisbus aufgeschaltet.
b) die Zieladresse (DEST.) wird auf den Operandenadreßbus gelegt. Der betreffende Adreßvergleicher 97 in Ressource A wird aktiv. Infolgedessen wird die Operandenbusbelegung in das jeweilige Operandenregister übernommen.

Das Prinzip kann sinngemäß auf serielle Interfaces übertragen werden, die z. B. an Schaltverteiler angeschlossen sind. Die Wandlung herkömmlicher Busprotokolle in die bitserielle Hochgeschwindigkeitsübertragung gehört zum Stand der Technik (vgl. beispielsweise PCI Express).
89 veranschaulicht die Auslegung einer Ressource für die Parameteradressierung über einen geteilten Adreßraum. Die Anordnung aus Adreßvergleicher 97 und Adreßeinstellung 98 ist in der gesamten Ressource nur einmal vorhanden. Der Adreßvergleicher 97 ist mit der Ressourcenadresse beschaltet. Sein Ausgang ist an den Erlaubniseingang eines Adreßdecoders 99 angeschlossen, der eingangseitig mit der Parameteradresse beschaltet ist. Den Ausgängen des Decoders sind die Übernahmesteuer- und Aufschalterlaubniseingänge der Parameterregister nachgeordnet. Im Interesse der Überschaubarkeit ist hier eine Lösung mit gemeinsamen Adreß- und Steuerleitungen für Ein- und Ausgabe dargestellt (Parameteradreßbus, Steuersignalbus). Die Datenwege können zu einem bidirektionalen Datenbus zusammengefaßt werden (vgl. die typischen Bussysteme der Mikroprozessoren). In 89 ist die Decodierung einer gemeinsamen Parameteradresse dargestellt. Hierzu genügt ein einziger Adreßdecoder 99, dem sowohl die Operanden- als auch die Ergebnisregister nachgeschaltet sind. Zur Decodierung getrennter Parameteradressen sind zwei Adreßdecoder erforderlich, einer für die Operanden- und einer für die Ergebnisregister. Die Erlaubniseingänge dieser Adreßdecoder sind zusätzlich mit den jeweiligen Zugriffssteuersignalen zu beschalten.
90 zeigt eine alternative Auslegung. Hier werden die Ressourcen nicht über eine binäre Adresse, sondern über Zugriffssteuerworte aktiviert. Das kann sowohl die Operationsauslösung (y-Operator, Verkettung) als auch die Parameterübertragung betreffen. Ein Zugriffssteuerwort wirkt gleichzeitig auf mehrere Ressourcen. In einem solchen Steuerwort können die Wirkungen mehrerer erfindungsgemäßer Operatoren zusammengefaßt werden. Im Extremfall kann ein Steuerwort alle Transport- und Verarbeitungvorgänge auslösen, die in allen Ressourcen zum jeweiligen Zeitpunkt überhaupt ablaufen können. Im Beispiel von 90 hat das Zugriffssteuerwort eine Bitposition je Ressource und Vorgang. Die Belegung der einzelnen Bits:

1.Op:: Parameter vom Operandenbus in das erste Operandenregister der Ressource eintragen,
2.Op:: Parameter vom Operandenbus in das zweite Operandenregister der Ressource eintragen,
Y:: Operation auslösen,
Res:: Ergebnis auf Ergebnisbus aufschalten.

Diesen Bits ist ein allgemeines Steuerfeld Comm.Ctl vorgeordnet. Dort sind u. a. folgende Wirkungen codiert:

a) Datenwort für Speicher auf den Operandenbus legen,
b) Ergebnis speichern,
c) Ergebnis auf Operandenbus zurückführen,
d) Auswahl des nächsten Steuerwortes (u. a. durch Verzweigung oder Unterprogrammruf).

In 90 ist eine der einfachsten Systemstrukturen (ein Bussystem mit zwei Datenwegen) dargestellt. Zu einer Zeit können nur ein Operand und ein Ergebnis transportiert werden. Der Operand kann dabei gleichzeitig in beliebig viele Ressourcen eingetragen werden. Höherentwickelte Systeme können mehrere Busstrukturen oder geschaltete Punkt-zu-Punkt-Verbindungen haben. Die Steuerworte enthalten dann anstelle der Einzelbits entsprechende Adreßfelder.
Die Ressourcen unterscheiden sich weiterhin danach, ob sie zustandsfrei und zustandsbehaftet ausgelegt werden. Der Begriff „Zustand" ist hier im Sinne des allgemeinen Programmiermodells zu verstehen. Ein Programm befindet sich zu jedem beliebigen Zeitpunkt in einem bestimmten Verarbeitungszustand. Im Falle von Unterbrechungen, Taskumschaltungen usw. ist dieser Zustand zu retten. Erhält das Programm später erneut Laufzeit, ist der gerettete Zustand wieder einzustellen. Bei der Auslegung eines erfindungsgemäßen Systems gibt es zwei Alternativen:

1. Zustandsbehaftete Ressourcen. Deren Belegung gehört zum Verarbeitungszustand bzw. Programm-Kontext. Wird eine Ressource in den Verarbeitungszustand einbezogen, so hat das folgende Konsequenzen: a) die in der Ressource gespeicherten Angaben sind bei Unterbrechungen, Taskumschaltungen usw. zu retten und hinterher ggf. wieder einzustellen (erfordert entsprechende Zugriffswege usw. und erhöht die Latenzzeit der Kontextumschaltung), b) die Speichermittel (Register usw.) in den Ressourcen sind vollwertige Speicher im Sinne des Programmiermodells; es ist möglich, Variable, Zwischenergebnisse usw. allein in den Ressourcen zu halten, c) Ergebnisse können auf Eingänge der gleichen Ressource zurückgeführt werden (INOUT-Parameter; 91), d) die Verkettung ist unbeschränkt nutzbar, e) Unterbrechungen, Taskumschaltungen usw. können jederzeit stattfinden, d. h. ohne auf den internen Verarbeitungszustand der Ressourcen Rücksicht zu nehmen (alle länger dauernden Verarbeitungsvorgänge sind jederzeit unterbrechbar). Bei voller Ausnutzung der Verkettung gibt es praktisch keine lokalen Variablen mehr, die eigens in entsprechenden Speicherbereichen (z. B. Stack Frames) gehalten werden müßten. Ebenso entfallen die betreffenden Transportbefehle zum Zwischenspeichern und Zurückholen (a- und p-Operatoren).
2. Zustandsfreie Ressourcen. Diese Ressourcen werden nicht in den Verarbeitungszustand einbezogen. Eine Ressource heißt zustandsfrei, wenn sie ihre Parameter nicht über den jeweils aktuellen Verarbeitungsvorgang hinaus speichert, mit anderen Worten, wenn sie sich praktisch wie eine kombinatorische Schaltung verhält. Das hat folgende Konsequenzen: a) die in der Ressource gespeicherten Angaben werden bei Unterbrechungen, Taskumschaltungen usw. nicht gerettet (entsprechende Zugriffswege sind nicht erforderlich, die Latenzzeit der Kontextumschaltung ist vergleichsweise geringer), b) alle Variablen, Zwischenergebnisse usw. sind im Arbeitsspeicher zu halten, c) es gibt keine Parameter, die zugleich Eingänge und Ausgänge sind (INOUT). Kein Eingang ist zurücklesbar, kein Ausgang durch Eintragen eines Eingangswertes (eines Operanden) überschreibbar. d) die Verkettung ist nur beschränkt nutzbar (z. B. zum Holen von Operanden und zum Abspeichern von Ergebnissen), e) vor dem Auslösen eines y-Operators sind alle Eingänge stets neu zu belegen. Das betrifft auch jene Werte, die sich gar nicht geändert haben. f) Unterbrechungen, Taskumschaltungen können nur stattfinden, nachdem die Ergebnisse der in den Ressourcen ausgelösten Verarbeitungsvorgänge in den Arbeitsspeicher transportiert wurden. Auch alle durch Verkettung ausgelösten Abläufe müssen zu Ende gekommen sein. Kein Verarbeitungsvorgang ist in sich unterbrechbar.

91 veranschaulicht zwei Auslegungsvarianten zustandsbehafteter Ressourcen:

a) ein Ergebnis wird im nächsten Verarbeitungsgang als Operand verwendet (Rückführung),
b) dieser Parameter ist sowohl Operand als auch Ergebnis (Typ INOUT).

Die Wahl der Auslegung hängt typischerweise davon ab, ob es vor allem auf kurze Latenzzeiten oder auf hohe Verarbeitungsleistung ankommt. Das Problem tritt nur dann auf, wenn Ressourcen mehrfach genutzt werden sollen, z. B. zur Unterbrechungsbehandlung oder dazu, mehrere Tasks abschnittsweise gleichzeitig auzuführen (Zeitmultiplexprinzip, Time Slicing).
Zustandsbehaftete Ressourcen brauchen Zeit zum Retten und Wiedereinstellen (Save/Restore), die Verarbeitungsvorgänge sind aber jederzeit unterbrechbar, und während der Verarbeitung fallen weniger Speicherzugriffe an. Sind die Ressourcen zustandsfrei, entfällt das Retten und Wiedereinstellen, die Verarbeitungsvorgänge sind aber nicht unterbrechbar, und es sind insgesamt mehr Speicherzugriffe erforderlich.
Kommt es auf geringe Latenzzeiten an, so ist zu untersuchen, was länger dauert: das Retten und Wiedereinstellen oder das Zu-Ende-Bringen aller Verarbeitungsvorgänge einschließlich der zusätzlichen Speicherzugriffe zum Holen der Operanden und zum Abspeichern der Ergebnisse.
Geht es um maximale Verarbeitungsleistung, sind typischerweise zustandsbehaftete Ressourcen vorzuziehen, da es nur diese Auslegung ermöglicht, die Ressourcen uneingeschränkt zu verketten, Ergebnisse auf Eingänge zurückzuführen und die internen Speichermittel zur Datenspeicherung auszunutzen. Um die Latenzzeiten zu verringern, können den zustandsbehafteten Ressourcen zusätzliche Speichermittel zugeordnet werden (92).
92 zeigt eine einfache Verarbeitungsressource, die aus zwei Operanden ein Ergebnis bildet. Die Operanden- und Ergebnisspeicher sind aber keine einfachen Register, sondern adressierbare Speicheranordnungen, die beispielsweise als Register- oder RAM-Arrays ausgebildet sind. Die Speicheradressen werden von außen zugeführt, z. B. von der Plattform. Jeder Task (bzw. jeder Unterbrechungsebene) ist eine Speicherposition zugeordnet. Die Speicherpositionen, mit denen die Ressource arbeitet, werden über die laufende Nummer der Task bzw. Unterbrechungsebene ausgewählt. Eine Taskumschaltung bzw. Unterbrechung bedeutet lediglich ein Umschalten der laufenden Nummer. Derartige Speicheranordnungen können nicht allzu groß sein (Richtwert: 4 ... 16 Speicherpositionen), weil die Zugriffszeiten ansonsten zu lang werden (was dazu zwingt, die Taktfrequenz zu senken oder zusätzliche Pipeline-Stufen einzufügen). Ein Ausweg besteht darin, Speicherinhalte, mit denen zur Zeit nicht gearbeitet wird, über unabhängige Zugriffswege (in 92: Rettungsbus) in den Arbeitsspeicher zu überführen und bei Bedarf von dort aus wieder zurückzuschreiben (Save/Restore). Diese Abläufe können parallel zu den eigentlichen Verarbeitungsvorgängen stattfinden.
93 zeigt, wie das in 92 veranschaulichte Prinzip – die Operanden- und Ergebnisspeicher als von außen adressierbare Speicheranordnungen auszuführen – verwendet werden kann, um mit einem Verarbeitungswerk mehr als eine Ressource zu verkörpern (Aufwandsverringerung). Hierzu werden die Operanden- und Ergebnisspeicher über eine Ressourcenadreßangabe adressiert, die beispielsweise von der Plattform geliefert wird. Weitere Abwandlungen:

1. unabhängige Adreßwege für die Operanden- und Ergebnisspeicher. Hierdurch können l-Operatoren und Verkettungsabläufe beschleunigt werden.
2. Verbund der Adressierungs- und Nutzungsweisen gemäß den 92 und 93. Eine bestimmte Speicherausstattung kann somit wahlweise genutzt werden, um je nach den anwendungspraktischen Anforderungen Gelegenheiten zum Ausführen verschiedener Tasks und zum Bereitstellen mehrerer Verarbeitungsressourcen zu bieten.

94 veranschaulicht eine entsprechende Adreßaufteilung am Beispiel einer 5-Bit-Adresse:

a) die gesamte 5-Bit-Adresse. Hiermit können bis zu 32 Parameterpositionen unterstützt werden. Auch die über den Rettungsbus ankommende Rettungsadresse (vgl. 92) hat diese Länge, so daß alle Speicherpositionen in das Retten und Wiedereinstellen einbezogen werden können.
b) Adreßaufteilung zur Unterstützung von 4 Tasks bzw. Unterbrechungsebenen (2 Adreßbits) und von 8 Ressourcen je Task bzw. Unterbrechungsebene (3 Adreßbits),
c) Belegung eines Steuerregisters, das die Adreßaufteilung steuert. Jede Adreßbitposition wird einzeln geschaltet: 0 = Bit der Ressourcenadresse, 1 = Bit der Task-Nummer.

95 zeigt eine entsprechende Umschalthardware. Ressourcenadresse und Task-Nummer sind bitweise auf Auswahlschaltungen geführt, deren Auswahleingänge dem Steuerregister (94c) nachgeschaltet sind. Diesen Auswahlschaltungen ist eine weitere Auswahlschaltung nachgeordnet, die andererseits mit der Rettungsadresse beschaltet ist.
Es gehört zu den Grundgedanken des erfindungsgemäßen Verfahrens, den Ressoucenvorrat als unbeschränkt anzunehmen. Da die Anzahl der Ressourcen in der Praxis aber stets begrenzt ist, ergibt sich gelegentlich die Notwendigkeit, Abläufe, die einen nahezu unbeschränkten Ressourcenvorrat vorausetzen, mit einer begrenzten Anzahl an Ressourcen auszuführen. Das soll nachstehend genauer betrachtet werden. Es gibt im Grunde drei Arten von Beschränkungen:

1. des Adressierungsvermögens,
2. der Speicherkapazität,
3. der Anzahl an Verarbeitungseinrichtungen.

Das Adressierungsvermögen (bzw. die Länge der entsprechenden Adreßangaben) begrenzt grundsätzlich den Umfang des Ressourcenvorrates (der Ressourcenvorrat ist nicht infinit, sondern transfinit). Die aus einem solchen Vorrat entnommenen Ressourcen sollen im folgenden als virtuelle Resourcen bezeichnet werden.
Die tatsächlich nutzbare Speicherkapazität kann auf bekannte Weise (virtuelle Speicherorganisation) auf die Größenordnung des Adressierungsvermögens erweitert werden.
Die Anzahl der tatächlich nutzbaren Verarbeitungseinrichtungen (= der realen Verarbeitungsressourcen) wird stets vergleichsweise gering bleiben (Größenordnung z. B. 2² ... 2¹²; verglichen mit typischen Adreßräumen von 2³² ... 2⁶⁴).
Die Informationswandlungen werden mit den tatsächlich vorhandenen (realen) Ressourcen nacheinander ausgeführt (Serialisierung). Hierzu können herkömmliche Maschinenbefehle, Mikrobefehle o. dergl. verwendet werden (Emulation). Das entspricht der Arbeitsweise des üblichen Universalrechners. In einer weiteren Variante führen die realen Ressourcen nach und nach die Informationswandlungen mehrerer gleichartiger virtueller Resourcen aus (Virtualisierung). Für alle ausgewählten virtuellen Ressourcen werden Arbeitsbereiche im Speicher eingerichtet. Diese können zudem in eine virtuelle Speicherorganisation einbezogen werden, wie sie von modernen Betriebssystemen unterstützt wird. Ist eine Verarbeitungsfunktion auszuführen, so werden die Speicherbelegungen der Operanden in eine entsprechende Hardware-Ressource transportiert. Die Ergebnisse werden ggf. in den Speicher zurückgeschafft. Es gibt verschiedene Möglichkeiten, dieses Prinzip zu implementieren:

a) die Transportabläufe werden ausprogrammiert. Der Compiler fügt ggf. entsprechende Transportbefehle ein (Umsetzung zur Compilierzeit).
b) die Transportabläufe werden in die Ablaufsteuerung der jeweiligen Operatoren eingefügt. Hierzu können die Ablaufsteuerschaltungen beispielsweise als Mikroprogrammsteuerwerk ausgeführt sein (die Steuerung komplizierter Transport- und Verknüpfungsvorgänge mit Mikroprogrammen ist an sich bekannt und muß nicht näher beschrieben werden).
c) Verarbeitungsressourcen werden in Cache-Anordnungen eingebaut (vgl. 63), so daß die Transporte von der an sich vorhandenen Cache-Hardware ausgeführt werden. Hierdurch ist zugleich gewährleistet, daß unnötige Transporte entfallen (befindet sich der Speicherbereich der betreffenden virtuellen Ressource bereits im Cache, so ergibt sich ein Treffer (Cache Hit), und die Verarbeitungsressource kann sofort aktiv werden (vgl. die Signale ADRS MATCH in 63)).
d) Verarbeitungsressourcen werden mit adressierbaren Speicheranordnungen ähnlich den 92 und 93 ausgerüstetet. Eine solche Verarbeitungsressource entspricht beispielsweise 2 ... 8 virtuellen Ressourcen, wobei zu einer Zeit eine der virtuellen Ressourcen jeweils aktiv ist. Das Eintragen von Operanden und das Abtransportieren von Ergebnissen kann parallel zu den in der jeweils aktiven Ressource ablaufenden Verarbeitungsvorgängen stattfinden (vgl. den Rettungsbus in 92).
e) die Verarbeitungsressourcen erhalten eigene Assoziativhardware.

96 veranschaulicht eine gegenüber 89 entsprechend weitergebildete Ressource. Adreßvergleicher 97 und Adreßeinstellung 98 wirken so, wie anhand von 89 beschrieben. Sie werden zum Decodieren der realen (physischen) Ressourcenadresse verwendet. Hinzu kommen ein Adreßvergleicher 97a und ein Adreßregister 98a für die Adresse der jeweils zugeordneten virtuellen Ressource (logische Adresse). Die logische Ressourcenadresse wird über zusätzliche Busleitungen zugeführt. Dem Adreßdecoder 99 ist eine Adreßauswahlschaltung 99a vorgeordnet. Beide Adreßvergleicher 97, 97a sind in disjunktiver Verknüpfung an den Adreßdecoder 99 angeschlossen. Des weiteren ist das Augangssignal des Adreßvergleichers 97a auf eine Trefferanzeigeleitung ADRS HIT geschaltet. Es gibt zwei Zugriffsweisen:

1. physische Zugriffe über Adreßdecoder 97. Die Adresse liegt fest (sie ist entweder unveränderlich oder sie wird nach dem Einschalten im Rahmen von Konfigurationsabläufen eingestellt). Die Adreßlänge ist nicht allzu groß (z. B. 6 Bits, wenn ingesamt 64 Ressourcen vorgesehen sind). Die Adreßauswahlschaltung 99a steuert die physische Parameteradresse zum Adreßdecoder 99 durch.
2. logische Zugriffe mit einer virtuellen Ressourcenadresse über Adreßdecoder 97a. Solche Adreßangaben können lang sein (z. B. 32 ... 64 Bits). Die Adreßauswahlschaltung 99a steuert die logische Parameteradresse zum Adreßdecoder 99 durch. Die jeweilige logische Adresse muß zuvor – mit physischen Zugriffen – in das Adreßregister 98a geladen werden. Hierzu wird das Adreßregister 98a wie ein weiteres Operandenregister angeschlossen. Wird beim Zugriff mit einer bestimmten logischen Adresse der Adreßvergleicher 97a aktiv, so erregt er die Trefferanzeigeleitung ADRS HIT, und die Anordnung wirkt als die betreffende virtuelle Ressource. Bleibt bei einem Zugriff mit einer virtuellen Ressourcenadresse ADRS HIT inaktiv, so muß der jeweiligen virtuellen Ressource eine der Hardwareressourcen zugewiesen werden. Die Vorgehensweise zum Aufsuchen einer geeigneten Hardwareressource sowie zum Aus- und Einlagern (Swapping) der Operanden und Ergebnisse ist an sich bekannt (vgl. die üblichen Caches und virtuellen Speicher).

Die jeweilige Zugriffsweise kann z. B. über verschiedene Befehls- bzw. Operatorformate gewählt werden. Im Extremfall gibt es alle Operatoren in doppelter Ausführung (logisch und physisch). In einer alternativen Auslegung kann die Zugriffsweise vom Arbeitszustand abhängig gemacht werden. Systeme mit mehreren Zuständen sind an sich bekannt. Typisch sind wenigstens zwei Zustände: Anwenderzustand (User Mode) und Betriebssystemzustand (Supervisor Mode). Im Anwenderzustand werden logische, im Betriebssystemzustand physische Zugriffe ausgeführt.
Im folgenden sollen anhand der 97 bis 101 Fragen der sog. Instrumentierung betrachtet werden. In der Informationstechnik versteht man unter Instrumentierung, Systeme mit zusätzlichen Vorkehrungen zur Systemverwaltung, zur Leistungsmessung, zum Fehlersuchen (Debugging) usw. zu bestücken. Um solche Funktionen in erfindungsgemäßen Systemen bereitzustellen, gibt es folgende Möglichkeiten:

1. die Ressourcen werden mit zusätzlichen Einrichtungen erweitert (97 bis 99),
2. es werden spezielle Ressourcen für diese Zwecke vorgesehen (100),
3. entsprechende Anordnungen werden durch Verkettung passender Ressourcen ad hoc erzeugt (101).

97 zeigt anhand eines Beispiels, wie ein einfacher Parameter (z. B. eine Binärzahl) durch Zusatzangaben ergänzt werden kann: 100 – Anfangswert zwecks Initialisierung; 101, 102 – Grenzen des Wertebereichs; 103 – der aktuelle Wert; 104 – Vergleichswert; 105 – Steuer- und Adreßangaben zur Auslösung von Programmausnahmen und zum Verhalten bei erfüllter Stopbedingung; 106 – Nutzungszähler; 107 – diverse Zustandsbits (u. a. zur Verkettungssteuerung); 108, 109 – Verkettungszeiger (vgl. 56). Jede der Angaben 100 bis 109 entspricht einem Register bzw. einer Speicherposition (im Ressourcenemulationsbereich).
Die Laufzeitsysteme vieler Programmiersprachen unterstützen nur den aktuellen Wert 103. Die Angaben 100 bis 102 dienen dazu, die Implementierung einschlägiger Programmiersprachen zu unterstützen (Beispiel: Ada). Der Vergleichswert 104 ist zu Debugging-Zwecken vorgesehen. Beispiel: Anhalten der Verarbeitung und Anzeige des Verarbeitungszustandes (Vergleichsstop), wenn der Parameter einen bestimmten aktuellen Wert angenommen hat. Der Nutzungszähler 106 kann z. B. verwendet werden, um festzustellen, wie oft der Parameter in Verarbeitungsvorgängen verwendet wurde oder welche Zeit zwischen zwei Neuberechnungen vergangen ist.
98 veranschaulicht eine Ressource mit eingebauten Debugging-Vorkehrungen. Ein einfacher Iterator (vgl. 37) ist um eine Vergleichseinrichtung erweitert, die die erzeugte Speicheradresse mit einem eingestellten Wert vergleicht und bei Gleichheit eine Stopbedingung signalisiert (Vergleichsstop). Sinngemäß können die Ressourcen mit Schaltmitteln zur Überwachung von Wertebereichen, mit Meßzählern usw. ausgerüstet werden (vgl. auch 70).
Die Stopadressen, Bereichsangaben, Zählwerte usw. können ebenso eingestellt und abtransportiert werden wie die üblichen Operanden und Ergebnisse; sie werden einfach als zusätzliche Parameter angesehen. Das erfordert aber eine entsprechende Erweiterung des Parameteradreßraums und somit mehr Adreßbits im Maschinencode.
Alternativ dazu können besondere Signalwege für die Instrumentierungsangaben vorgesehen werden. 99 zeigt eine etwas komplexere Verarbeitungsressource (vgl. die 13 und 48), die mit Instrumentierungsvorkehrungen ausgerüstet und zusätzlich an einen Instrumentierungsbus angeschlossen ist. Da die Transporte der Instrumentierungsangaben nicht leistungskritisch sind (solche Angaben werden nur von Zeit zu Zeit eingestellt oder abgerufen), genügt eine entsprechend einfache Auslegung (z. B. als serielles Bussystem). Zusätzlich zu den bereits erläuterten Debugging- und Leistungsmeßvorkehrungen sind in der Ressource gemäß 99 folgende Funktionen vorgesehen:

a) Entschlüsselung der ankommenden Operanden und Verschlüsselung der abgehenden Ergebnisse. Ver- und Entschlüsselungseinrichtungen sind an sich bekannt. Hier sind sie in die Ressource eingebaut. Das hat den Vorteil, daß auf externen Bussystemen (die z. B. auf Leiterplatten verlaufen) nur verschlüsselte Daten bewegt werden.
b) Eigentümerkennzeichnung. Im einfachsten Fall handelt es sich um abfragbare Festwerte. Höherentwickelte Ressourcen können mit Autorisierungsvorkehrungen ausgerüstet sein, z. B. mit einem eingebauten Paßwortschutz; sie sind nur dann nutzbar, wenn zuvor entsprechend korrekte Autorisierungsangaben eingetragen wurden. Der Vorteil besteht darin, daß dieser Schutz untrennbar mit der Verarbeitungshardware verbunden ist, so daß z. B. ein Kopieren der genutzten Software gar keinen Zweck hat, weil gleichartige Ressourcen in anderen Maschinen zu ihrer Nutzung andere Autorisierungsangaben erwarten.

Bekannte Losungen, sog. vertrauenswürdige (trusted) Computerplattformen bereitzustellen, beruhen u. a. darauf, aus den Eigentümlichkeiten der Hardware eine Art Signatur abzuleiten. Solche Verfahren lösen das Problem nicht von Grund auf. Sie sind z. B. darauf angewiesen, daß die betreffende Signatur über das Internet verifiziert wird. Das ist unbequem, widerspricht den Grundsätzen des Datenschutzes und behindert die freizügige Nutzung des jeweiligen Computers. Der Einbau direktwirkender Schutzvorkehrungen in Hardware-Ressourcen, die nach dem erfindungsgemäßen Verfahren eingesetzt werden, hat den Vorteil, daß die freie Nutzung des Computers nicht behindert wird und daß eine Ausspähen von Hardware- und Konfigurationsdaten nicht erforderlich ist, da die Schutzwirkungen auf direkte Weise erbracht werden. Freie Programme fordern keine derartigen Ressourcen (z. B. gemäß 99) an. Programme, die Schutzinteressen unterliegen, laufen nicht auf Maschinen, die nicht mit entsprechenden Ressourcen ausgerüstet sind. Die Verschlüsselungs- und Kennzeichnungsfunktionen werden von der Hardware bereitgestellt, und zwar im Innern der Schaltkreise. Die Einzelheiten der Abläufe lassen sich somit nicht meßtechnisch verfolgen. Eine softwareseitige Nachbildung wäre sinnlos (viel zu lange Rechenzeiten).
100 veranschaulicht, wie eine Verarbeitungsressource mit einer speziellen Debuggingressource verkettet wird. Zusätzlich zu den Verarbeitungsressourcen werden ergänzende Instrumentierungs-Ressourcen bereitgestellt (zum Debugging, zur Leistungsmessung usw.). Diese werden bei Bedarf aufgerufen (s-Operatoren) und mit den Verarbeitungsressourcen verkettet (das eigentliche Anwendungsprogramm ändert sich hierdurch nicht). Im Beispiel ist eine einfache Verarbeitungsressource (ein Addierwerk) mit einer Debugging-Ressource verkettet, die den Wertevergleich unterstützt. Ist das Ergebnis der Verarbeitungsressource gleich dem eingestellten Vergleichswert, so wird eine Stopbedingung ausgelöst. Die Debugging-Ressource ist so ausgebildet, daß sie die zu vergleichende Angabe (hier: das Ergebnis der Verarbeitungsressource) zu den eigentlichen Zielressourcen weiterverketten kann. Ist die Stopbedingung eingetreten, so wird die Weiterverkettung nicht wirksam (be dingte Verkettung). Somit wird der Verarbeitungsablauf angehalten, und es ist auf an sich bekannte Weise (durch Abholen der Registerinhalte) möglich, den aktuellen Verarbeitungszustand auszuwerten. Soll die Verarbeitung fortgesetzt werden, erhält die Verkettungssteuerung in der Debugging-Ressource ein entsprechendes Signal über den Instrumentierungsbus.
101 zeigt, wie übliche Verarbeitungsressourcen zu Instrumentierungszwecken ausgenutzt werden können. Auf diese Weise ist es möglich, Konfigurationen zum Fehlersuchen (Debugging), zur Leistungsmessung usw. bedarfsweise zusammenzuschalten. Im Beispiel wird ein Addierwerk (Verarbeitungsressource) mit einem Subtrahierwerk (Debugging-Ressource) verkettet. Das Subtrahierwerk vergleicht das Ergebnis des Addierwerks mit einem eingestellten Prüfwert. Zudem leitet es das ankommende Ergebnis an andere Ressourcen weiter. Die Stopbedingung wird hier durch eine Verkettung zur Plattform signalisiert (sie kann dort z. B. eine Unterbrechung auslösen). Das gewährleistet aber nicht immer ein exaktes Anhalten zum Stopzeitpunkt. Höherentwickelte universelle Ressourcen, die ihren Funktionen nach auch für Instrumentierungszwecke in Betracht kommen, können mit bedingter Operandenverkettung ausgerüstet werden, so daß sie z. B. ein Ergebnis bei Auftreten einer Stopbedingung nicht weiterleiten und somit den Verarbeitungsablauf zwecks Beobachtung zeitweise anhalten.
Nachfolgend sollen beispielhafte Gestaltungen von Byte- und Maschinencodes erläutert werden. Zunächst wird anhand der 102 bis 105 die Auslegung von maschinenunabhängigen Bytecodes betrachtet. Solche Bytecodes sind hier als binär codierte Programmdarstellungen mit unbeschränktem Adressierungsvermögen ausgelegt. (Bekannte Bytecodes haben typischerweise ein beschränktes Adressierungsvermögen. Als Beispiel sei auf den Bytecode der Java Virtual Machine (JVM) verwiesen.) Die Auslegung von Bytecodes gehört zum allgemeinen Fachwissen der Informatik. Deshalb kann sich die folgende Darstellung auf ein typisches Ausführungsbeispiel beschränken.
Programme bestehen aus Folgen von Bytes. Es gibt Steuerbytes (102) und numerische Angaben. Steuerbytes für numerische Angaben enthalten eine Längenangabe im Bereich von 1 bis 7. Die Längenangabe kennzeichnet, wie lang die nachfolgende numerische Angabe ist. Die Typangabe kennzeichnet die Art der nachfolgenden numerischen Angabe (Tabelle 5). Codierte Längenwerte: 1 Byte, 2 Bytes, 3 Bytes, 4 Bytes, 6 Bytes, 8 Bytes, reserviert. In Steuerbytes für Operatoren ist die Längenangabe = 0. Die Typangabe kennzeichnet die Art des Operators (Tabelle 6). Mit Nullen belegte Steuerbytes (Inhalt = 00H) sind wirkungslos (NOP).
Tabelle 5
Tabelle 6
Gemäß den Tabellen 5 und 6 sind 11 Arten numerischer Angaben und 14 verschiedene Operatoren zu codieren. Das 5-Bit-Feld des hier beschriebenen Formats läßt somit noch eine Reserve von 21 bzw. 18 Codepositionen frei (es können noch 21 weitere Arten numerischer Angaben und 18 weitere Operatoren codiert werden).
Die Operatoren müssen durch numerische Angaben ergänzt werden. Es gibt zwei Möglichkeiten der Reihenfolge:

1. Postfixnotation (103). Erst kommen die numerischen Angaben, dann folgt der Operator. Das interpretierende System hält eine Art Zustandspuffer, der den aktuellen Wert einer jeden Angabe aufnimmt. Beim Fortschreiten von einem Operator zum nächsten sind nur jene Angaben neu einzutragen, die sich jeweils geändert haben.
2. Präfixnotation (104). Erst kommt der Operator, dann folgen die numerischen Angaben. Deren Anzahl muß der jeweiligen Syntax entsprechen. Das interpretierende System muß eine Akzeptorautomaten haben, der gültige Reihen erkennt. Wurde eine solche Reihe erkannt, so wird die jeweilige Wirkung ausgelöst.

103 veranschaulicht einen Bytecode in Postfixnotation. Gemäß den Steuerbytes werden die Zahlenangaben in die jeweiligen Positionen eines Zustandspuffers eingetragen (es handelt sich z. B. um einen fest zugeordneten Bereich im Arbeitsspeicher oder um eine Registeranordnung). Tritt ein Operator auf, so wird die betreffende Wirkung ausgelöst (110). Dabei werden die jeweils benötigten Angaben aus dem Zustandspuffer abgeholt (111). Im Beispiel hat der Zustandspuffer 11 Einträge, einen für jede Art der numerischen Angaben gemäß Tabelle 5. Werden beispielsweise bis zu 8 Bytes lange Parameter zugelassen, so muß jeder Eintrag die 8 Datenbytes aufnehmen können. In einer ersten Ausführung wird zusätzlich die jeweilige aktuelle Längenangabe (aus dem Steuerbyte) mitgespeichert, damit später (bei der Operationsausführung) die tatsächliche Länge des Parameters erkannt werden kann. In einer alternativen Ausführung sind alle Parameter im Zustandspuffer beispielsweise 8 Bytes lang. Kürzere Angaben werden rechtsbündig eingefügt. Ein Parameterwert von einem Byte Länge wird in die Bitpositionen 7 ... 0 eingetragen, einer von zwei Bytes Länge in die Bitpositionen 15 ... 0 usw. In einer weiteren Abwandlung ist der Zustandspuffer als Stack ausgebildet. Numerische Angaben werden auf den Stack gelegt, Operatoren entnehmen ihre Parameter vom Stack. Steuerbytes mit nachfolgenden numerischen Angaben stellen praktisch Push-Befehle dar, Steuerbytes die Operatoren codieren, Operationsbefehle (nach deren Ausführung die Operanden vom Stack entfernt werden).
104 veranschaulicht einen Bytecode in Präfixnotation. Der Akzeptorautomat analysiert den Bytestrom (112). Jeder Operator ist durch bestimmte zulässige Folgen von Zahlenangaben gekennzeichnet (Tabellen 7, 8). Die erkannten Zahlenangaben werden zwischengespeichert. Nach Erkennung einer vollständigen zulässigen Folge wird die entsprechende Wirkung ausgelöst (113). Dabei werden die vom Akzeptorautomaten zwischengespeicherten Angaben abgeholt (114). An eine solche Folge darf sich entweder eine weitere zulässige Folge oder ein Operator anschließen.
Die vorstehend beschriebenen Auslegungen des Bytecodes können sowohl mit Ordinalzahlals auch mit Adreßangaben arbeiten; es ist lediglich eine Frage der Interpretation. Tabelle 7 betrifft Ordinalzahlangaben oder einen geteilten Ressourcenadreßaum, Tabelle 8 einen flachen Ressourcenadreßraum.
Tabelle 7
Tabelle 8
Nach der Erläuterung der maschinenunabhängigen Bytecodes sollen im folgenden verschiedene Auslegungsmöglichkeiten von Maschinencodes anhand von insgesamt sieben Beispielen erläutert werden. Der Maschinencode kann als Bytecode (variable Länge) oder als fest formatierter Befehlscode ausgelegt sein. Die Gestaltung von Maschinenbefehlsformaten gehört zum allgemeinen Fachwissen der Rechnerachitektur. Deshalb genügt es, einige Beispiele kurz zu beschreiben. Diese Beispiele veranschaulichen:

a) Befehle verschiedener Länge (16, 32, 64 Bits sowie Bytecodes mit variabler Länge),
b) Befehlsformate mit möglichst großem Adressierungsvermögen (= langen Adreßangaben),
c) Befehlsformate, die möglichst viele gleichzeitig auslösbare Wirkungen unterstützen,
d) Formate mit kurzen und langen Befehlen,
e) Befehlsformate mit flachem und mit geteiltem Ressourcenadreßraum,
f) die Nutzung von Halteregistern zum Übergeben von Angaben, die nicht in das jeweilige Befehlsformat passen.

Wichtige Gesichtspunkte der Befehlsgestaltung sind u. a.:

1) möglichst lange Adreßangaben,
2) ausreichend lange Ressourcentypangaben im s-Operator (8 Bits sind typischerweise die unterste Grenze),
3) einfache Decodierung,
4) gute Ausnutzung der Befehlslänge,
5) Vorkehrungen zum Eintragen elementarer Direktwerte. Hierfür wird eine zusätzliche Variante des p-Operators vorgesehen (p_imm = p immediate).
6) genügend Reserven, um weitere Befehle codieren zu können.

Ist die Befehlsliste vorzugsweise zur softwareseitigen Emulation vorgesehen, so kommt es auf lange Adreßangaben an, während die gleichzeitige Auslösung mehrerer Funktionen (Parallelarbeit) praktisch bedeutungslos ist (sie kann vom Emulator ohnehin nicht unterstützt werden). Demgegenüber geht es in Befehlslisten für spezielle Hardware (Spezialprozessoren, Verarbeitungseinrichtungen in FPGAs) vor allem um die Parallelverarbeitung. Die Ressourcenadreßangaben müssen lediglich so lang sein, daß sie die tatsächlich vorhandene Hardware unterstützen können. Für universelle Hardware (Mikrocontroller, Hochleistungsprozessoren) ist typischerweise ein Kompromiß zwischen Adreßlänge und gleichzeitig auslösbaren Funktionen zu finden.
Alle im folgenden vorgestellten Beispiele enthalten ungenutzte Bitpositionen oder eigens reservierte Formate, die zur Erweiterung des jeweiligen Befehlssatzes genutzt werden können (z. B. für m-, h- und u-Operatoren, für s-Operatoren, mit denen man Ressourcen übers Internet anfordern kann, für Regiebefehle usw.). Zusätzliche Befehle können auch mehrere Befehlsworte belegen. Die Erweiterung eines Befehlssatzes durch Zusatzbefehle ist in der Rechnerarchitektur seit langem bekannt, so daß eine genauere Beschreibung nicht erforderlich ist.
Beispiel 1 betrifft Befehle variabler Länge, die aus aufeinanderfolgenden Bytes bestehen (Bytecode). Befehlsformate mit variabler Länge sind in vielen Rechnerarchitekturen üblich. Ein solcher Befehl beginnt mit einem Operationscodebyte, das sowohl die Befehlswirkung als auch die Anzahl der nachfolgenden Bytes bestimmt. Im Beispiel gemäß Tabelle 9 und 105 hat – im Gegensatz zu den vorstehend beschriebenen maschinenunabhängigen Bytecodes – jeder Befehl nur eine einzige Wirkung (beispielsweise müssen, um 5 gleichartige Ressourcen auszuwählen, 5 s-Operatoren gegeben werden).
Tabelle 9
Tabelle 9 gibt einen Überblick über die Befehlsformate für einen geteilten Ressourcenadreßraum. In Befehlen für einen flachen Ressourcenadreßraum entfallen die Parameterangaben. Zu den Befehlswirkungen vgl. Tabelle 6. 105 zeigt die Formate der Angaben, aus denen die Befehle bestehen:

a) 1 Byte. Für Operationscodes, Ressourcentypen, Ressourcenadressen, Parameteradressen und Direktwerte.
b) 2 Bytes. Für Ressourcentypen, Ressourcenadressen, Parameteradressen und Direktwerte.
c) Variablenadresse, 2 Bytes. W = Zugriffsbreite, B = Basisadreßregister (vgl. Tabelle 13). 4 verschiedene Zugriffsbreiten, 4 Basisadreßregister, 12 Bits Displacement.
d) 3 Bytes. Für Ressourcentypen, Ressourcenadressen, Parameteradressen und Direktwerte.
e) Variablenadresse, 3 Bytes. W = Zugriffsbreite, B = Basisadreßregister (vgl. Tabelle 13). 8 verschiedene Zugriffsbreiten, 4 Basisadreßregister, 19 Bits Displacement.
f) 4 Bytes. Für Ressourcentypen, Ressourcenadressen, Parameteradressen und Direktwerte.
g) Variablenadresse, 4 Bytes. W = Zugriffsbreite, B = Basisadreßregister (vgl. Tabelle 13). 16 verschiedene Zugriffsbreiten, 4 Basisadreßregister, 26 Bits Displacement.

Die Befehlsformate für eine bestimmte Maschine lassen sich wie aus einem Baukasten zusammenstellen. Tabelle 10 enthält die Länge der einzelnen Angaben (in Bytes) für mehrere typische Anwendungsfälle. Diese Befehlsformate haben genügend Reserven; das Adressierungsvermögen der einzelnen Angaben wird praktisch nie vollständig ausgenutzt. Es ist von Vorteil (Speicherplatzersparnis), mehrere p_imm-Operatoren mit verschieden langen Direktwerten vorzusehen.
Tabelle 10

Beispiel 2 betrifft ein 32-Bit-Befehlswort und Adreßangaben mittlerer Länge (Tabellen 11 bis 13). Jeder Befehl entspricht einem vollständigen Operator. Manche Befehle können zwei Wirkungen auslösen. Der Ressourcenadreßraum umfaßt maximal 4096 Parameter. Die 12 Adreßbits können auch geteilte Ressourcenadressen aufnehmen, z. B. für 1024 Ressourcen mit 4 Parametern oder 512 Ressourcen mit 8 Parametern. Anwendungsbeispiele: erfindungsgemäß ausgelegte Hochleistungsprozessoren, Spezialprozessoren, umfangreiche Verarbeitungseinrichtungen in FPGAs usw. Tabelle 11 gibt eine Übersicht über den Maschinencode, Tabelle 12 beschreibt die Befehlswirkungen. In Tabelle 13 ist angegeben, wie Zugriffsbreite W und Basisadresse B codiert werden.

1. Befehlslänge:	32 Bits
2. Ressourcenadresse:	12 Bits (flacher Adreßraum)
3. Ressourcentypangabe:	12 Bits
4. Direktwertlänge:	16 Bits
5. Variablenadresse (Displacement):	14 Bits. Max. 4 Basisadressen (B)
6. Festlegung der Zugriffsbreite:	im Befehl. Max. 4 Zugriffsbreiten (W)
7. Besonderheiten:
a) der y-Operator kann zwei Ressourcen gleichzeitig aktivieren,
b) der s-Operator kann zwei Ressourcen gleichzeitig auswählen.

Tabelle 11
Tabelle 12
Tabelle 13

Beispiel 3 betrifft ein 32-Bit-Befehlswort mit 28 Bits langen Adreßangaben (Tabellen 14 bis 17). Anwendung: vor allem für die softwareseitige Emulation (virtuelle Maschinen) in oberen Leistungsbereichen. Es ist nicht möglich, zwei Angaben in einem 32-Bit-Wort unterzubringen. Deshalb werden in der Plattform vier Halteregister vorgesehen, die mit u-Operatoren geladen werden können (Tabelle 14). Manche Operatoren erfordern deshalb zwei Befehle. Der Ressourcenadreßraum umfaßt maximal 256M Parameter. Die 28 Adreßbits können auch geteilte Ressourcenadressen aufnehmen, z. B. für 16M Ressourcen mit 16 Parametern oder für 1M Ressourcen mit 256 Parametern. Tabelle 14 zeigt die Belegung der Halteregister, Tabelle 15 gibt eine Übersicht über den Maschinencode, Tabelle 16 beschreibt die Befehlswirkungen. In Tabelle 17 ist angegeben, wie Zugriffsbreite W und Basisadresse B codiert werden.

1. Befehlslänge:	32 Bits
2. Ressourcenadresse:	28 Bits (flacher Adreßraum)
3. Ressourcentypangabe:	26 Bits
4. Direktwertlänge:	26 Bits
5. Variablenadresse (Displacement):	24 Bits. Max. 4 Basisadressen (B)
6. Festlegung der Zugriffsbreite:	im Befehl. Max. 8 Zugriffsbreiten (W)
7. Zwischenpufferung:	4 Halteregister

Tabelle 14
Die Anordnung von Halteregistern ermöglicht – im Gegensatz zur naheliegenden Verdoppelung der Befehlslänge – oftmals eine Mehrfachnutzung der eingetragenen Angaben:

a) Transport eines Direktwerts zu mehreren Ressourcen (p_imm),
b) Transport einer Variablen zu mehreren Ressourcen (p),
c) Zuweisung eines Ergebnisses zu mehreren Variablen (a),
d) Transport eines Ergebnisses zu mehreren Operanden (l, c, d).

*): Codes 00, 01, 10

Tabelle 16
Tabelle 17

Beispiel 4 ist eine Abwandlung des Beispiels 2 mit kurzen Befehlen (16 Bits) und zwei Ressourcenangaben im Befehl (Tabellen 18, 19). Die einzelne Ressourcenadresse ist auf 6 Bits beschränkt. Hiermit können z. B. 16 Ressourcen mit jeweils maximal 4 Parametern oder 8 Ressourcen mit jeweils 8 Parametern unterstützt werden. Anwendungsbeispiele: erfindungsgemäß ausgelegte Mikrocontroller, kleinere Spezialprozessoren, Verarbeitungseinrichtungen in FPGAs usw. Bei Beschränkung auf 16 Bits werden die Displacementangaben der Variablenadressen und die Direktwerte sehr kurz. Deshalb gibt es von den p-, p_imm- und a-Operatoren jeweils eine Langversion, die das nachfolgende 16-Bit-Wort einschließt. Tabelle 18 gibt eine Übersicht über den Maschinencode (zu den Angaben W und B vgl. Tabelle 13), Tabelle 19 beschreibt die Befehlswirkungen.

1. Befehlslänge:	16 bzw. 32 Bits
2. Ressourcenadresse:	6 Bits (flacher Adreßraum)
3. Ressourcentypangabe:	12 Bits
4. Direktwertlänge:	6 oder 20 Bits
5. Variablenadresse (Displacement):	4 oder 18 Bits. Max. 4 Basisadressen (B)
6. Festlegung der Zugriffsbreite:	16-Bit-Befehle: in den Ressourcen angegeben (z. B. Verarbeitungsbreitenregister) oder fester Standardwert (z. B. 16 oder 32 Bits). 32-Bit-Befehle: im Befehl. Max. 4 Zugriffsbreiten (W)
7. Besonderheit:	der y-Operator kann zwei Ressourcen gleichzeitig aktivieren.

Tabelle 18
Tabelle 19

Beispiel 5 ist eine Abwandlung des Beispiels 3 mit kurzen Befehlen (16 Bits) und entsprechend kürzeren, aber durchaus brauchbaren Adreßangaben (Tabelle 20). Mit einer Ressourcenadresse von 12 Bits können z. B. 512 Ressourcen mit jeweils maximal 8 Parametern unterstützt werden. Es ist nicht möglich, zwei Adreßangaben in einem Befehl unterzubringen. Deshalb werden in der Plattform vier Halteregister vorgesehen, die mit u-Operatoren geladen werden können (vgl. Tabelle 14). Manche Operatoren erfordern deshalb zwei Befehle. Anwendungsbeispiele: softwareseitige Emulation (virtuelle Maschinen), vorzugsweise im Bereich der Embedded Systems, auf erfindungsgemäßer Grundlage beruhende Prozessoren usw. Tabelle 20 veranschaulicht den Maschinencode. Siehe weiterhin die Tabellen 13 bis 17.

1. Befehlslänge:	16 Bits
2. Ressourcenadresse:	12 Bits (flacher Adreßraum)
3. Ressourcentypangabe:	10 Bits
4. Direktwertlänge:	11 ... 13 Bits
5. Variablenadresse (Displacement):	9 Bits. Max. 4 Basisadressen (B)
6. Festlegung der Zugriffsbreite:	im Operator. Max. 4 Zugriffsbreiten (W)
7. Zwischenpufferung:	4 Halteregister mit 12 Bits

Tabelle 20

*): Codes 00, 01, 10

Beispiel 6 betrifft kurze Befehle, in denen möglichst viele parallel ausführbare Funktionen codiert sind (Tabellen 21 bis 23). Es werden bis zu 64 Ressourcen mit jeweils maximal 8 Parametern unterstützt (geteilter Adreßraum). Die Angaben für die einzelnen Operatoren werden abschnittsweise zugeführt. Um die endgültigen Angaben bereitzustellen, werden in der Plattform drei Halteregister angeordnet. Zum Laden der Halteregister sind zusätzliche Operatoren u_rs1, u_rs2, u_ra vorgesehen. Der y-Operator kann bis zu acht Ressourcen gleichzeitig aktivieren (über Bitmaske). Anwendungsbeispiele: erfindungsgemäß ausgelegte Mikrocontroller, universelle Prozessoren, Spezialprozessoren, Verarbeitungseinrichtungen in FPGAs usw. Dieses Befehlsformat unterstützt vor allem die Parallelarbeit zwischen den Ressourcen (gleichzeitige Operationen, Parametertransporte usw.). Tabelle 21 zeigt die Belegung der Halteregister, Tabelle 22 gibt eine Übersicht über den Maschinencode (zur Basisregisterangabe B vgl. Tabelle 13), Tabelle 23 beschreibt die Befehlswirkungen.

1. Befehlslänge:	16 Bits
2. Ressourcenadresse:	6 Bits (geteilter Adreßraum)
3. Parameteradresse:	3 Bits
4. Ressourcentypangabe:	10 Bits
5. Direktwertlänge:	9 Bits
6. Variablenadresse (Displacement):	9 Bits. Max. 4 Basisadressen (B)
7. Festlegung der Zugriffsbreite:	in den Ressourcen
8. gleichzeitig aulösbar sind:
a) 2 Parametertransporte zwischen den Ressourcen oder
b) 2 Verkettungssteuerfunktionen oder
c) die Aktivierung von maximal 8 Ressourcen oder
d) das Eintragen von 2 Ressourcenadressen in ein Halteregister.

Tabelle 21
Tabelle 22
Tabelle 23

Beispiel 7 betrifft eine Befehlsgestaltung, die es ermöglicht, sehr viele parallel ausführbare Funktionen zu codieren (Tabellen 24 bis 30). Hierzu sind längere Befehle erforderlich (64 Bits). Wie in Beispiel 6 werden bis zu 64 Ressourcen mit jeweils maximal 8 Parametern unterstützt (geteilter Adreßraum). Die Angaben für die einzelnen Operatoren werden abschnittsweise zugeführt. Um die endgültigen Angaben bereitzustellen, werden in der Plattform drei Halteregister angeordnet. Zum Laden der Halteregister sind zusätzliche Operatoren u_rs1, u_rs2, u_ra vorgesehen. Der y-Operator kann bis zu 60 Ressourcen gleichzeitig aktivieren (über Bitmaske). Anwendungsbeispiele: Spezialprozessoren, Verarbeitungseinrichtungen in FPGAs usw. Tabelle 24 zeigt die Belegung der Halteregister, Tabelle 25 veranschaulicht das grundsätzliche Befehlsformat. Tabelle 26 enthält Einzelheiten zur Parameterangabe in den Operatoren p, p_imm und a (zur Basisadreßangabe B vgl. Tabelle 13). Die Operationscodes sind aus Tabelle 27 ersichtlich. Tabelle 28 zeigt den Aufbau der Befehlsformate, Tabelle 29 gibt einen Überblick über deren Inhalt. Tabelle 30 beschreibt die Befehlswirkungen.

1. Befehlslänge:	64 Bits
2. Ressourcenadresse:	6 Bits (geteilter Adreßraum)
3. Parameteradresse:	3 Bits
4. Ressourcentypangabe:	10 Bits
5. Direktwertlänge:	12 Bits
6. Variablenadresse (Displacement):	10 Bits. Max. 4 Basisadressen (B)
7. Festlegung der Zugriffsbreite:	in den Ressourcen
8. gleichzeitig auslösbar sind:
a) 10 Parametertransporte zwischen den Ressourcen oder
b) 10 Verkettungsteuerfunktionen oder
c) 4 Parametertransporte zwischen Ressourcen und Plattform oder
d) die Aktivierung von maximal 60 Ressourcen oder
e) das Eintragen von 10 Ressourcenadressen in ein Halteregister oder
f) die Zuweisung von 6 Ressourcen oder
g) die Freigabe von 10 Resourcen.

Tabelle 24
Tabelle 25
Tabelle 26
Tabelle 27
Tabelle 28
Tabelle 29
Tabelle 30
Es folgen einige Erläuterungen zur Durchführung des erfindungsgemäßen Verfahrens in herkömmlichen Rechenanlagen. Hierzu gibt es zwei grundsätzliche Möglichkeiten:

1. Emulation. Die Operatoren bzw. Anweisungen werden von entsprechender Software aus dem Speicher geholt, die jeweiligen Wirkungen werden programmseitig nachgebildet.
2. Compilierung. Ein als Maschinencode vorliegendes Programm (Quellprogramm) wird in Folgen herkömmlicher Maschinenbefehle umgesetzt und ausgeführt.

Bei der herkömmlichen Programmentwicklung wird die Programmierabsicht typischerweise in mehreren Stufen umgesetzt: Quelltext in höherer Programmiersprache => Maschinenprogramm einer (fiktiven) Stackmaschine (auf Zielmaschine durch Emulation lauffähig) => optimiertes Maschinenprogramm für Zielmaschine. Fiktive Stackmaschinen sind in Zusammenhang mit den Programmiersprachen Pascal (P-Code), Forth und Java (Java Virtual Machine JVM) allgemein bekannt geworden. Solche Stackmaschinen eignen sich gut zum Auflösen beliebig geschachtelter Ausdrücke, sind aber ihrer Wirkungsweise nach inhärent sequentiell.
Unter Nutzung des erfindungsgemäßen Verfahrens wird als Zwischenstufe ein Maschinenprogramm für eine fiktive Maschine erzeugt. die auf den bisher beschriebenen Grundlagen beruht (keine Stackmaschine, sondern eine Ressourcenkonfiguration). Es ergeben sich folgende Stufen: Quelltext in höherer Programmiersprache => Maschinenprogamm einer (fiktiven) Ressourcenkonfiguration (auf Zielmaschine durch Emulation lauffähig) => optimiertes Maschinenprogramm für Zielmaschine.
Der Vorteil besteht darin, daß es möglich wird, den inhärenten Parallelismus des Programms nahezu vollständig zur Compilierzeit zu erkennen. Hierzu werden für jeden Programmschritt jeweils neue Ressourcen angefordert. Diese werden soweit möglich miteinander verkettet. Somit entsteht zunächst eine fiktive Ressourcenkonfiguation in womöglich gigantischer Größenordnung (hunderttausende Rechenwerke usw.). In anschließenden Durchmusterungsläufen wird diese Konfiguration dann nach und nach auf einen praktikablen Umfang reduziert. Die Ressourcen werden – zusammen mit den Programmen und Daten – im Speicher untergebracht (vgl. 5). Eine Ressource besteht aus

a) Speicherplätzen, die den Registern der Hardwarelösung entsprechen,
b) zusätzlichen Speicherplätzen für Zwischenwerte usw. (Arbeitsbereiche),
c) einem Programm, das die Funktionsweise der Ressource nachbildet.

Prinzip:

1. mit s-Operatoren werden alle Funktions-Ressourcen aufgebaut,
2. soll eine Funktion ausgeführt werden, wird die betreffende Ressource zunächst mit Parametern versorgt (p-Operatoren); dann wird die Programmausführung gestartet (y-Operator).
3. schließlich werden die Ergebnisse zugewiesen (a-Operatoren, l-Operatoren oder Verkettung).

Alle Transporte sind Transporte auf feste Adressen; es entfällt das Auf- und Abbauen der Stack Frames. Die Bereiche können vielmehr während der gesamten Laufzeit bestehen bleiben. Somit werden praktisch alle lokalen Variablen zu globalen. Daß das Auf- und Abbauen der Stack Frames entfällt, ist vor allem dann von Vorteil, wenn Funktionen im Innern von Programmschleifen gerufen werden.
Typischerweise genügt jeweils ein einziges Programm, um alle gleichartigen Ressourcen zu emulieren. Ausnahme: die Plattform unterstützt die erforderliche Adreßrechnung nur unzulänglich (wie dies bei manchen Mikrocontrollern der Fall ist). Dann sind mehrere Kopien des jeweiligen Programms erforderlich, die mit unterschiedlichen Adressen arbeiten (im Extremfall hat jede Ressource eine eigene Kopie).
Es folgt ein Beispiel einer Funktion, die auf diese Weise implementiert wird:
int EXAMPLE (int A, int B, double C);
Jetzt wird die Funktion aufgerufen:
OMEGA = EXAMPLE (ALPHA, BETA, GAMMA);
Die Ressource EXAMPLE wird als Speicherbereich definiert. Bei jedem Funktionsaufruf wird ein solcher Bereich erzeugt. Jedem Funktionsaufruf im Quellprogramm entspricht ein s-Operator. Die gesamte Aufrufkette (Funktion A ruft Funktion B, diese ruft Funktion C usw.) wird zunächst – mit s-Operatoren – gleichsam vorgefertigt. Das Ausführen einer solchen Funktion wird mit einem y-Operator gestartet. 106 zeigt eine beispielhafte Speicherbelegung für diese Funktion.
107 veranschaulicht die Parameteradressierung im Speicher. 107a betrifft einen flachen, 107b einen geteilten Parameteradreßraum. Jeder Parameter entspricht typischerweise einer Speicherposition. Es liegt nahe, die Speicherpositionen der Ressourcen aufeinanderfolgend anzuordnen, so daß sich die fortlaufende Adressierung in einem flachen Adreßraum gleichsam von selbst ergibt (107a). Ein geteilter Adreßraum erfordert mehr Aufwand zur Adreßrechnung (107b). Eine über das Schema Basis + Displacement hinausgehende Adreßrechnung wird aber von den gängigen Prozessoren gar nicht oder nur nachlässig unterstützt (Ablaufverlangsamung).
Es ist grundsätzlich möglich, von Ressourcen belegte Speicherbereiche in eine virtuelle Speicherorganisation einzubeziehen. Ressourcen, mit denen zur Zeit nicht gearbeitet wird, können auf den Massenspeicher ausgelagert werden. Auf diese Weise steht für die Emulation der Ressourcen ein Speicheradreßraum in der Größenordnung des gesamten architekturseitigen Adressierungsvermögens zur Verfügung. Betriebssysteme, die das erfindungsgemäße Verfahren unterstützen, können eigens virtuelle Adreßräume für die Ressourcenemulation bereitstellen (hierzu ist es lediglich erforderlich, je Adreßraum einen eigenen Satz Adreßumsetzungstabellen (Page Tables) zu verwalten).
Des weiteren ist es möglich, komplette Ressourcenbelegungen als Dateien zu speichern und zwecks Ausführung wieder zu laden. Die Ressourcenstruktur muß so nur einmal aufgebaut werden (mit s- und c-Operatoren). Für jede weiteren Nutzung genügt ein einfacher Ladevorgang. Solche vorgefertigten Strukturen können vom Programmentwickler erzeugt und im Rahmen der betreffenden Software komplett ausgeliefert werden, so daß beim Anwender die entsprechenden s- und c-Operatoren gar nicht ausgeführt werden müssen.
Zudem ist es möglich, die Ausführung der einzelnen Funktionen unterschiedlichen Prozessoren zu übertragen. Die Speicherbereiche besonders leistungskritischer Funktionen können in Registerspeichern (Universalregistersätzen) untergebracht werden. Auf diese Weise können auch sehr große Registerspeicher wirkungsvoll ausgenutzt werden (z. B. mit 256 und mehr Universalregistern). Des weiteren ist es möglich, den Universalregistern Verarbeitungsressourcen bereichsweise direkt zuzuordnen (vgl. die 65 bis 69). Derartige Anordnungen können – infolge der unmittelbaren (also kurzen) Verbindungen zwischen Registern und Verarbeitungsschaltungen – mit höheren Taktfrequenzen betrieben oder als Pipelinestrukturen mit geringerer Tiefe ausgeführt werden.
Die Nutzung von Universalregistersätzen ist ein seit langem bekanntes Problem der maschinennahen Programmierung und der Programmgenerierung (in Compilern). Hierzu hat man Algorithmen entwickelt, die herausfinden, welche Variablen am häufigsten benötigt werden und deshalb vorrangig in Registern unterzubringen sind (Register Allocation). Manche Programmiersprachen unterstützen die explizite Deklaration von Registervariablen (so daß der Anwendungsprogrammierer die Zuweisung beeinflussen kann). Sehr große Registersätze (es gibt Prozessoren mit beispielsweise 128 oder 192 Universakegistern) werden herkömmlicherweise über eine Bereichsadressierung zugänglich gemacht. Der einzelne Maschinenbefehl sieht jeweils nur einen Ausschnitt aus dem gesamten Registeradreßraum. In diesem Bereich wird der jeweils aktuelle Stack Frame untergebracht. Werden Unterprogramme (Funktionen) aufgerufen oder verlassen, so werden diese Bereiche entsprechend umgeschaltet. Dieses Prinzip ersetzt zwar das Transportieren von Parametern durch das – deutlich schnellere-Umschalten des zugänglichen Adreßbereichs, die Umschaltvorgänge kosten aber ihrerseits Zeit, und die Adressierung erfordert zusätzliche Schaltmittel, die durchlaufen werden müssen. Hierdurch ergibt sich ein längerer Taktzyklus oder die Notwendigkeit, zusätzliche Pipeline-Stufen einzuführen. Zudem hat man den Auf- und Abbau der Stack Frames zwar beschleunigt, aber nicht gänzlich abgeschafft. Nach wie vor müssen die lokalen Variablen beim Aufrufen der Funktion neu initialisiert werden und gehen beim Verlassen der Funktion verloren.
Folgende Merkmale moderner Hochleistungsprozessoren können zur Geschwindigkeitssteigerung ausgenutzt werden:

a) mehrere Verarbeitungswerke (Superskalarprinzip),
b) große Universalregistersätze,
c) Multiprozessorsysteme (mehr als ein Prozessor auf einem Schaltkreis, mehrere Prozessorschaltkreise im Verbund),
d) Parallelausführung mehrerer gleichartiger Operationen (SMID = Single Instruction, Multiple Data),
e) Parallelausführung mehrerer verschiedenartiger Operationen, gesteuert von entsprechend langen Befehlen (VLIW = Very Long Instruction Word).

Die Maßnahmen zur Geschwindigkeitssteigerung laufen im Grunde darauf hinaus, daß in Maschinenprogrammen, die dem erfindungsgemäßen Verfahren entsprechen, nach unabhängigen Verarbeitungsabläufen gesucht wird.
Zwei Ressourcen R1, R2 sind dann voneinander unabhängig, wenn im Programm folgendes nicht vorkommt:

1. Verkettungen zwischen R1 und R2 (in beiden Richtungen),
2. l-Operatoren, die R1 und R2 betreffen (für beide Richtungen),
3. Weiterverarbeitung gespeicherter Ergebnisse der jeweils anderen Ressource (p-Operatoren für R2 beziehen sich auf Variable, die zuvor mit a-Operatoren von R1 zum Speicher transportiert wurden und umgekehrt).

Die Unabhängigkeit ist im allgemeinen eine dynamische, vom Gang der Verarbeitung abhängige Eigenschaft (beispielsweise können zwei Ressourcen eine Zeit lang unabhängig voneinander sein und später verkettet werden).
Die zur Leistungssteigerung vorgesehenen Architekturerkmale moderner Hochleistungssysteme können auf Grundlage des erfindungsgemäßen Verfahrens folgendermaßen ausgenutzt werden:

1. Ausnutzung des Superskalarprinzips: Ressourcen, die im jeweiligen Zeitabschnitt unabhängig voneinander sind, werden gleichzeitig aktiviert (y-Operator).
2. Ausnutzung von Multiprozessor-Konfigurationen: Unabhängige Ressourcen werden verschiedenen Prozessoren zugeordnet.
3. Ausnutzung von SIMD-Vorkehrungen: Ein einziger Maschinenbefehl veranlaßt die Ausführung mehrerer gleichartiger Operationen (vgl. die MMX- und SSE-Befehle in den Prozessoren der üblichen PCs). Solche Befehlswirkungen werden herkömmlicherweise zur Verarbeitung spezieller Datenstrukturen verwendet (z. B. für Video- und Audiodaten). Um derartige Vorkehrungen auch für allgemeine Programme auzunutzen, wird im Programm nach unabhängigen gleichartigen Ressourcen gesucht, deren Wirkungsweise mit SIMD-Befehlen nachgebildet werden kann (gleiche Operation, gleiche Verarbeitungsbreite). Derartige Operationen werden gleichsam aufgesammelt und – wenn genügend anhängig sind – gemeinsam aktiviert (y-Operator löst SMID-Befehle aus).
4. Ausnutzung von VLIW-Vorkehrungen: Im Programm wird nach unabhängigen Ressourcen gesucht, deren Wirkungsweise mit VLIW-Befehlen nachgebildet werden kann. Derartige Operationen werden gleichsam aufgesammelt und – wenn genügend anhängig sind – gemeinsam aktiviert (y-Operator löst VLIW-Befehle aus).

Systeme zur Durchführung des erfindungsgemäßen Verfahrens können mit herkömmlichen Prozessoren aufgebaut werden. Man kann z. B. einen Prozessor als Plattform einsetzen und durch weitere Prozessoren ergänzen, die als Verarbeitungsressourcen genutzt werden. Die Prozessoren werden üblicherweise über ein Bussystem oder über Punkt-zu-Punkt-Interfaces und Koppeleinrichtungen (Schaltverteiler, Hubs) miteinander verbunden (108, 109). Sie können auf einen gemeinsamen Speicheradreßraum zugreifen.
Die Plattform baut die Ressourcen-Arbeitsbereiche im Speicheradreßraum auf und veranlaßt die Prozessoren, die entsprechenden Funktionen auszuführen. Das kann z. B. durch Unterbrechungsauslösung bewirkt werden. Diese Lösung funktioniert mit herkömmlicher Hardware, hat aber den Nachteil vergleichsweise langer Latenzzeiten. Hierzu tragen vor allem bei:

a) die Interruptauslösung (mit der erforderlichen Kontextumschaltung),
b) das Füllen der Caches (nach dem Schreiben in den Speicheradreßraum müssen die Caches der Prozessoren zunächst neu gefüllt werden).

Eine Abhilfe besteht darin, die Caches der Prozessoren für Schreibzugriffe von außen zugänglich zu machen. Das erfordert entsprechende Änderungen an den Prozessorschnittstellen. Es muß möglich sein, die Prozessoren als Targets anzusprechen, wobei die Zugriffsadressen die internen Caches und Pufferspeicher betreffen. Hierfür ist nur die Busanschlußsteuerung abzuwandeln (die anderen Schaltungen im Prozessor bleiben, wie sie sind).
Noch höhere Verarbeitungsleistungen lassen sich erreichen, wenn der Prozessor auch im Innern nach erfindungsgemäßen Grundsätzen ausgelegt wird und die Operatoren nicht nur mit herkömmlichen Maschinenbefehlen emuliert, sondern direkt ausführt. Hierzu können vorhandene Prozessorstrukturen ausgenutzt werden. Befehlsdecodierung und Mikroprogrammsteuerung sind zu ändern, Verarbeitungswerke, Anschlußsteuerungen, Caches, Puffer usw. können im wesentlichen erhalten bleiben.
108 veranschaulicht ein dem Stand der Technik entsprechendes Hochleistungssystem mit mehreren Prozessoren, die über ein Bussystem miteinander verbunden sind, 109 zeigt die Verbindung über Schaltverteiler. Die 110 und 111 geben anhand von Blockschaltbildern einen Überblick über Aufbau und Wirkungsweise moderner Hochleistungsprozessoren, die als Superskalarmaschinen ausgebildet sind. Solche Prozessoren arbeiten arbeiten typischerweise folgendermaßen:

1. mehrere herkömmliche Maschinenbefehle werden gleichzeitig gelesen und decodiert,
2. sie werden in Mikrobefehle umgesetzt,
3. die Mikrobefehle werden in einem assoziativen Steuerspeicher (Reordering Buffer) gepuffert und von einem Verteiler zu den Operationswerken geführt,
4. ein Mikrobefehl wird dann ausgeführt, wenn ein passendes Operationswerk frei ist,
5. die Operationen laufen ab, ohne die ursprüngliche Verarbeitungsreihenfolge zu berücksichtigen,
6. werden Konflikte erkannt, so werden die betreffenden Befehle so oft wiederholt, bis die Konflikte verschwunden sind,
7. die Befehlserledigung (Instruction Retirement) stellt die Ergebnisse der konfliktfrei zu Ende gebrachten Befehle so bereit, daß die Ergebnisse der Befehlsausführung dem Programmierer gegenüber so erscheinen, wie sie sich gemäß der ursprünglichen Verarbeitungsreihenfolge (= Programmierabsicht) ergeben hätten.

Bei dieser Form der Parallelarbeit handelt es sich also gleichsam um eine Art Probieren. Dabei ist der Bereich, in dem versucht wird, parallele Abläufe auszuführen, auf die Anzahl der Befehle beschränkt, die gleichzeitig geholt und decodiert werden können. Der Steuerungsaufwand ist vergleichsweise hoch.
In 111 bedeuten: 1 – Busanschlußsteuerung; 2 – Befehlsleseeinheit; 3, 4 – Befehlsdecodierung für einfache Befehle; 5 – Befehlsdecodierung für komplexe Befehle; 6 – Registerzuordnungseinheit; 7 – Befehlserledigung; 8 – Mikrobefehls-Assoziativpuffer (Reordering Buffer); 9 – Mikrobefehlsabruf 10, 11 – Gleitkommaverarbeitungswerke; 12, 13 – Verarbeitungswerke für ganze Binärzahlen; 14 – Speicherzugriffssteuerung; 15 – architekturseitiger Registersatz; 16 – herkömmliche Mikroprogrammsteuerung (steuert alles, was für die Parallelausführung zu kompliziert ist); 17 – Sprungzielpuffer; 18 – architekturseitiger Befehlszähler; 19 – Speicherzugriffspuffer.
Auf Grundlage solcher Prozessoren können Systeme zur Durchführung des erfindungsgemäßen Verfahrens aufgebaut werden. Dabei können die komplizierten Steuereinrichtungen (Positionen 3 ... 9 in 111) entfallen. Es verbleiben die Verarbeitungswerke, die Caches und Puffer sowie die Busschnittstellen. Der Befehlsdecoder ist wesentlich einfacher. Der Universalregistersatz kann gegenüber herkömmlichen Prozessoren beträchtlich erweitert werden (z. B. auf 64 bis 256 Register). Die Verarbeitungswerke können mit dem Universalregistersatz direkt gekoppelt werden. Da die komplizierten Steuerschaltungen entfallen, können ggf. die Verarbeitungsfunktionen erweitert oder zusätzliche Verarbeitungswerke vorgesehen werden.
112 veranschaulicht die Umwandlung eines herkömmlichen Superskalarprozessors in eine Hardware zur direkten Durchführung des erfindungsgemäßen Verfahrens. Die Bezugszeichen entsprechen 111.
Es ist ersichtlich, daß man auf Grundlage des erfindungsgemäßen Verfahrens die künftigen Möglichkeiten der Schaltungsintegration (z. B. einige hundert Millionen Transistoren auf einem Schaltkreis) in weitem Umfang ausnutzen kann. Herkömmliche Hochleistungsprozessoren (z. B. ähnlich 111) haben rund 10 ... 50 Millionen Transistoren. Auf einem Schaltkreis mit 200 Millionen Transistoren ließen sich z. B. vier Prozessoren zu jeweils ca. 50 Millionen Transistoren unterbringen. Das Leistungsvermögen dieser Anordnung kann aber nur dann in der Anwendungspraxis wirksam werden, wenn wenigstens vier Programme gleichzeitig auszuführen sind; das einzelnen Programm kann in sich nicht beschleunigt werden. Zerlegt man einen Prozessor der hier in Rede stehenden Art in seine Funktionseinheiten, so entsprechen die Verarbeitungseinrichtungen 4 ... 8 universellen Rechenwerken. Wenn Caches, Steuerschaltungen usw. – ihrem Umfang nach – beibehalten werden (gleicher Aufwand, nur abgewandelte Struktur), so könnte ein Schaltkreis mit 200 Millionen Transistoren 32 universelle Rechenwerke enthalten, die gemäß dem erfindungsgemäßen Verfahren als Ressourcen verwaltet werden und somit jedem einzelnen Programm zugute kommen können.
Es ist Sache des Programmierers, das erfindungsgemäße Verfahren zweckmäßig anzuwenden. Die Wahlmöglichkeiten liegen zwischen zwei Extremen:

1. herkömmliche Programmierweise: eine Ressource zu einer Zeit. In Analogie zu den herkömmlichen Maschinenbefehlen wird eine Ressource angefordert, mit Parametern versorgt, aktiviert und zum Schluß wieder freigegeben. Dann wird die nächste Ressource angefordert usw.
2. die Programmierabsicht wird insgesamt in eine – womöglich gigantische – fiktive Spezialhardware umgesetzt (für jede Informationswandlung wird eine eigene Ressource angefordert, die Ressourcen werden untereinander verkettet usw.).

Die zweite Alternative findet ihre praktischen Grenzen im Speicherbedarf und im Umfang der tatsächlich verfügbaren Hardware, so daß in der Praxis stets Kompromisse gefunden werden müssen.
Jede Ressource ist – zumindest gedanklich (fiktiv) – eine Hardware-Software-Schnittstelle auf dem Register-Transfer-Niveau, kann also formal als Hardware beschrieben werden (Boolesche Gleichungen, Automatentabellen usw.). Auf Grundlage des erfindungsgemäßen Verfahrens erstellte Programme werden nicht in Form einer Zeichen- oder Bitkette dokumen tiert, deren Wirkungsweise sich nur durch die Ausführung ergibt, sondern in Form von Strukturen, die auch im Ruhezustand (ohne etwas auszuführen) einer eingehenden Analyse zugänglich sind.
Aus den beschriebenen Grundsatzlösungen und Varianten können erfindungsgemäße Systeme gleichsam nach dem Baukastenprinzip konfiguriert werden. Die Auswahl ergibt sich – wie in der Rechnerarchitektur üblich – auf Grundlage von Kosten-Nutzen-Betrachtungen und Nutzungshäufigkeiten. Beispiel:

a) eine Auslegung X bringt Vorteile bei Anwendungen der Art A,
b) eine Auslegung Y bringt Vorteile bei Anwendungen der Art B.

Kommen Anwendungen der Art A häufiger vor als solche der Art B, wird man die Auslegung X wählen und umgekehrt.
Das erfindungsgemäße Verfahren kann ausgenutzt werden:

1. zu theoretischen Betrachtungen,
2. in der Programmierpraxis,
3. in der Programmdokumentation,
4. beim Wandeln (Konvertieren) von Programmen, die in verschiedenen Programmiersprachen formuliert sind,
5. beim Aufbau von Systemen auf Grundlage programmierbarer Logikschaltkreise,
6. zur Gestaltung von Prozessor- und Systemarchitekturen.

1. Theorie. Herkömmliche Programme liegen im Grunde lediglich als Texte (Zeichenketten) vor. Aus der Analyse des Programmtextes allein läßt sich das Verhalten des Programms nur ungenügend voraussagen; man muß das Programm laufen lassen, um seine Wirkungen zu erkennen. Hingegen ist es auf Grundlage des erfindungsgemäßen Verfahrens möglich, die Programmierabsicht in eine (fiktive) Schaltungsstruktur umzusetzen, deren Informationswandlungen bis auf die einzelnen Booleschen Gleichungen aufgelöst werden können. Hierdurch werden formale Korrektheitsbeweise vereinfacht bzw. überhaupt erst durchführbar (Anwendung der Graphentheorie, Automatentheorie, Schaltalgebra usw.). Die Tatsache, daß letzten Endes eine (fiktive) Schaltungsstruktur vorliegt, kann auch beim Testen von Programmen ausgenutzt werden; alle Verfahren – und Tricks – die sich beim Fehlersuchen in Hardware bewährt haben, werden nutzbar (das Zerlegen der Gesamt-„Schaltung" in Blöcke, die einzeln getestet werden, das Zusammenschalten von Testkonfigurationen mit Testdatenerzeugung und Testauswertung, das gezielte Einspeisen von Testmustern usw.). Ebenso wie man zum Fehlersuchen in der Hardware ggf. Signalgeneratoren, Logikanalysatoren usw. zu Hilfe nimmt, kann man in einem solchen System entsprechende Prüfhilfen bedarfsweise aus den vorhandenen Ressourcen zusammenstellen.
2. Programmierpraxis. Beide Nutzungsweisen (Emulation und Compilierung) haben in bestimmten Anwendungsgebieten besondere Vorteile:

a) Emulation. Nutzung vorzugsweise in Embedded Systems. Entsprechende Programme werden sowohl mit üblichen Programmiersprachen als auch mit Entwurfswerkzeugen erstellt, die eine graphische Erfassung der Entwurfsabsicht unterstützen, z. B. auf Grundlage von Blockschaltbildern, Flußdiagrammen und State Machines. Solche Entwurfssysteme erzeugen typischerweise einen Zwischencode in einer gängigen Programmiersprache (C, C++ usw.), der anschließend mittels eines gängigen Compilers in ein Programm für die betreffende Zielmaschine gewandelt wird. Die Ausdrucksmittel der üblichen universellen Programmiersprachen sind aber für die hier in Rede stehenden Anwendungsprobleme nicht besonders geeignet. Gemäß dem erfindungsgemäßen Verfahren erzeugte Programme beschreiben im Grunde Schaltungsstrukturen, also Hardware. Deshalb können solche Programme auf naheliegende Weise aus Blockschaltbildern, Zustandsdiagrammen usw. abgeleitet werden. An die Stelle eines Zwischencodes (z. B. in C) tritt ein Code, der eine passend gewählte Ressourcenanordnung auswählt, verkettet und steuert, wobei der Ressourcenvorrat auf das jeweilige Anwendungsgebiet hin optimiert ist (z. B. auf das Arbeiten mit Booleschen Gleichungen und Automatentabellen).
b) Compilierung (Erzeugung „echter" Maschinenprogramme für die jeweilige Zielarchitektur). Nutzung vorzugsweise für komplexe Anwendungen, von denen eine hohe Verarbeitungsleistung erwartet wird. Ein typischer Entwicklungsgang: Formulieren der Programmierabsicht (in einer beliebigen Programmiersprache) => Wandlung in den Code einer fiktiven Maschine nach erfindungsgemäßen Prinzipen => Umsetzung in den Maschinencode der Zielarchitektur => Programmausführung. Es ist üblich, den Quellcode zunächst in einen fiktiven Maschinencode umzusetzen. Solche fiktiven Maschinen sind zumeist als Stackmaschinen ausgelegt. Stackmaschinen arbeiten aber inhärent sequentiell (ein Vorgang zu einer Zeit). Demgegenüber haben erfindungsgemäß ausgelegte virtuelle Maschinen vor allem folgende Vorteile: 1) der inhärente Parallelismus im Programmablauf kann besser erkannt werden, 2) es ist möglich, Gelegenheiten zur Ausnutzung von SIMD-Vorkehrungen und VLIW-Befehlen in allgemeinen Programmabläufen zu erkennen, 3) Verringerung des Anteils der Organisationsabläufe (Overhead), z. B. beim Aufrufen von Funktionen und beim Transportieren von Parametern.

3. Einsatz in Anwendungsbereichen mit hohen Anforderungen an die Funktionssicherheit. Der Prozessor (oder Mikrocontroller) interpretiert eine (fiktive) Schaltungsstruktur, die – anders als ein Programmtext – auch im statischen Zustand der Kontrolle und Verifizierung zugänglich ist. Somit können Mikroprozessoren, Mikrocontroller usw. auch dort angewendet werden, wo man bisher – aus Sicherheitsgründen – den Einsatz programmierbarer Einrichtungen ausgeschlossen hat. Der bisherige Zustand: es wird eine Schaltungslösung ausgearbeitet, auf Einhaltung der jeweiligen Vorschriften hin überprüft und schließlich als Hardware gebaut. Die Alternative: die Schaltung wird mit den Ausdrucksmitteln des erfindungsgemäßen Verfahrens beschrieben (Operatoren usw.), die Beschreibung wird vom Prozessor oder Controller emuliert. Ein richtig geschriebener Emulator kann nie abstürzen, ganz gleich, welche Fehler im zu interpretierenden System vorhanden sind. Somit hat die auf dem erfindungsgemäßen Verfahren beruhende Software die gleiche Funktionssicherheit wie eine „echte" Hardware-Implementierung.
4. Programmdokumentation. Ein auf dem erfindungsgemäßen Verfahren beruhendes Programm kann die Programmierabsicht in allen wesentlichen Einzelheiten beschreiben; wenn es sein muß, bis hin zur einzelnen Booleschen Gleichung. Deshalb ist zu erwarten, daß sich solche Programme ohne weiteres in Maschinencode für künftige Systeme umsetzen lassen (Zukunftssicherheit).
5. Programmkonvertierung; Metasprache. Sämtliche Programme, gleich in welcher Sprache formuliert, sind letzten Endes Steueranweisungen für Informationswandlungen, Transporte und Zustandsübergänge in Register-Transfer-Strukturen. Ein hinreichend (in bezug auf Datentypen, Operationen usw.) ausgestatteter Ressourcenvorrat eignet sich somit – im Verbund mit den erfindungsgemäßen Operatoren – als universelles Compiler-Ziel bzw. (aus Sicht der Theorie) als universelle Metasprache, in der alle Ausdrücke der verschiedenen Programmiersprachen wiedergegeben werden können. Tabelle 31 veranschaulicht ein Beispiel. Es sind drei Formulierungen dargestellt, die alle das gleiche bewirken. Entsprechende Compiler können den erfindungsgemäßen Code aus Texten in C, Basic usw. erzeugen. Ein typischer Entwicklungsgang: Programm in Programmiersprache A => Byte- oder Maschinencode => Programm in Progammiersprache B (Substituieren der Aktivierung der Ressourcen durch Sprachkonstrukte mit jeweils gleichartigen Wirkungen).
Tabelle 31
5. Systeme auf Grundlage programmierbarer Logikschaltkreise. Das erfindungsgemäße Verfahren ermöglicht es, komplexe Entwürfe unabhängig von ihrer Realisierung zu beschreiben und die Implementierung – mit harten oder weichen Schaltungen – je nach Zweckmäßigkeit festzulegen. Hierbei können auch Hard- und Software gegeneinander ausgetauscht werden.
Eine auf erfindungsgemäßer Grundlage ausgestaltete Befehlsliste ist eine einheitliche Maschinensprache, die sowohl Hardware als auch Software beschreiben kann.
Die üblichen programmierbaren Schaltkreise enthalten im Grunde nur zwei Arten von Schaltmitteln:

1. universelle Funktionsblöcke, Makrozellen usw., die jeweils nur vergleichsweise einfache kombinatorische Verknüpfungen ausführen und nur wenige Bits in Flipflops speichern können (Richtwert: 1 ... 4 Flipflops je Zelle). Man kann hier bildhaft von einer „feinen Körnigkeit" der Schaltmittel sprechen.
2. harte IP Cores, z. B. komplette Prozessoren. Das entspricht einer „groben Körnigkeit".

Weiche IP Cores belegen viel Siliziumfläche. Vergleicht man die harte (bis auf den Transistor optimierte) und die weiche Implementierung der gleichen Funktion, so braucht die weiche Ausführung typischerweise mehr als zehnmal soviele Transistoren als die harte. Auch die Geschwindigkeit ist entsprechend geringer (Verhältnis der Taktfrequenzen typischerweise 4:1 bis über 10:1).
Harte Implementierungen sind hingegen teuer (Entwicklungsaufwand) und nicht so flexibel. Man kann sie nicht ohne weiteres mit beliebigen Schaltungen eigener Wahl verbinden, sondern muß die vorgegebenen Schnittstellen (z. B. Bussysteme) ausnutzen. Das erfordert typischerweise zusätzlichen Adaptierungsaufwand.
Gemäß den erfindungsgemäßen Prinzipien kann man programmierbare Schaltkreise gestalten, die eine mittlere Körnigkeit aufweisen – der „dicke" harte Prozessor wird gleichsam in seine Bestandteile aufgelöst, die als einzelne Bausteine bereitgestellt werden. Auch kann man die Verbindungsstrukturen in Hinsicht auf die typischen Informationstransporte optimieren. Aus den bereitgestellten Ressourcen (Rechenschaltungen, Adressierungsschaltungen usw.) kann man je nach Bedarf Universalrechner oder Spezialschaltungen aufbauen und die Konfiguration während der laufenden Arbeit ändern.
6. Prozessor- und Systemarchitekturen. Kennzeichnend ist die Auflösung der Prozessorstrukturen in die einzelnen Funktionseinheiten und der fließende Übergang zwischen Hard- und Software. Bei entsprechender Ausgestaltung (Standardisierung) kann man die festen-proprietären- Prozessorarchitekturen, Betriebssysteme und Anwendungsprogramme durch Ressourcen an sich beliebiger Herkunft ersetzen (aufgelöste Systemarchitektur). Sowohl System- als auch Anwendungsfunktionen werden von Ressourcen erbracht, die beliebiger Herkunft sein und wahlweise als Hardware oder als Software ausgeführt werden können. Wesentlich hierfür ist, daß die Operatoren bzw. Befehle nur das Aufrufen, Aktivieren usw. der Ressourcen beschreiben, während die eigentlichen funktionellen Wirkungen im Innern der jeweiligen Ressource erbracht werden. Damit dies in der Praxis wirksam werden kann, ist es erforderlich, Ressourcenbeschreibungen und universelle Befehlscodes (z. B. Bytecodes) umfassend zu standardisieren.
Bisherige Ansätze zur Verwirklichung solcher Vorstellungen beruhen auf höheren formalen Sprachen oder auf virtuellen Maschinen, die sich vergleichsweise einfach emulieren lassen. Verwendet man höhere formale Sprachen, so erfordert der Übergang von einer Plattform auf eine andere oder der Wechsel zwischen Hard- und Software stets eine Neucompilierung. Hierfür ist jeweils ein passender Compiler erforderlich.
Da die internen Schnittstellen (z. B. der Parameterübergabe) nicht einheitlich standardisiert sind, gibt es immer wieder Kompatibilitätsprobleme. Verwendet man eine virtuelle Maschine, so lassen sich solche Schwierigkeiten weitgehend vermeiden. Herkömmliche virtuelle Maschinen sind aber vor allem unter dem Gesichtspunkt einer effektiven Compilierung von Software entwickelt worden (Beispiele: P-Code (Pascal), Forth-Maschinen, JVM (Java Virtual Machine)). Sie eignen sich deshalb kaum als universelle Schnittstellen zu komplexer Hochleistungshardware (Parallelverarbeitung, anwendungsspezifische Verarbeitungswerke usw.). Bei Nutzung des erfindungsgemäßen Verfahrens kann hingegen der inhärente Parallelismus unmittelbar aus der Programmierabsicht heraus erkannt werden. Somit ist es möglich, ggf. auch hunderte Rechenwerke gleichzeitig einzusetzen. Speicher und Verarbeitungslogik können direkt miteinander verbunden werden. Im Extremfall ist die einzelne (Hardware-) Ressource eine Speicheranordnung mit Rechenwerk (Ressourcenzelle).

Claims

Verfahren zur programmgesteuerten Informationsverarbeitung, wobei die zur Ausführung der Informationsverarbeitungsvorgänge vorgesehenen Einrichtungen einen Ressourcenvorrat bilden, aus dem Ressourcen zur Nutzung ausgewählt und in den diese Ressourcen nach ihrer Nutzung wieder zurückgegeben werden.
Verfahren nach Anspruch 1, gekennzeichnet durch folgende Verfahrensschritte: 1. Auswahl der zur Ausführung der Informationsverarbeitungsvorgänge geeigneten Ressourcen aus dem Ressourcenvorrat, 2. Einrichten von Verbindungen zwischen den Ressourcen, 3. Versorgen der Ressourcen mit Parametern, 4. Auslösen der Informationsverarbeitungsvorgänge in den Ressourcen, 5. Transportieren von Daten zwischen den Ressourcen, 6. Zuweisung der Ergebnisse, 7. Trennen nicht mehr benötigter Verbindungen zwischen den Ressourcen, 8. Zurückgeben nicht mehr benötigter Ressourcen an den Ressourcenvorrat.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß die Auswahl der zur Ausführung der Informationsverarbeitungsvorgänge geeigneten Ressourcen aus dem Ressourcenvorrat durch gespeicherte Anweisungsangaben (s-Operatoren) gesteuert wird, die Ressourcentypangaben enthalten.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß das Einrichten von Verbindungen zwischen den ausgewählten Ressourcen durch gespeicherte Anweisungsangaben (c-Operatoren) gesteuert wird, die auf die Ressourcen bezogene Auswahlangaben enthalten.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß das Versorgen der ausgewählten Ressourcen mit Parametern durch gespeicherte Anweisungsangaben (p-Operatoren) gesteuert wird, die auf die Speichereinrichtungen und auf die Ressourcen bezogene Auswahlangaben enthalten.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß das Auslösen der Informationsverarbeitungsvorgänge in den ausgewählten Ressourcen durch gespeicherte Anweisungsangaben (y-Operatoren) gesteuert wird, die auf die Ressourcen bezogene Auswahlangaben enthalten.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß das Transportieren von Daten zwischen den ausgewählten Ressourcen durch gespeicherte Anweisungsangaben (l-Operatoren) gesteuert wird, die auf die Ressourcen bezogene Auswahl- und Verbindungsangaben enthalten.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß die Zuweisung von Ergebnissen der ausgewählten Ressourcen durch gespeicherte Anweisungsangaben (a-Operatoren) gesteuert wird, die auf die Ressourcen und auf die Speichereinrichtungen bezogene Auswahlangaben enthalten.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß das Trennen nicht mehr benötigter Verbindungen zwischen den ausgewählten Ressourcen durch gespeicherte Anweisungsangaben (d-Operatoren) gesteuert wird, die auf die ausgewählten Ressourcen bezogene Auswahlangaben enthalten.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß das Zurückgeben nicht mehr benötigter Ressourcen an den Ressourcenvorrat durch gespeicherte Anweisungsangaben (r-Operatoren) gesteuert wird, die auf die ausgewählten Ressourcen bezogene Auswahlangaben enthalten.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß die Auswahl von zur Ausführung der Informationsverarbeitungsvorgänge geeigneten Ressourcen aus dem Ressourcenvorrat wenigstens teilweise durch gespeicherte Anweisungsangaben (s_a-Operatoren) gesteuert wird, die ergänzend zu den Ressourcentypangaben auf die Ressourcen bezogene Auswahlangaben enthalten, die den ausgewählten Ressourcen zugeordnet werden.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß das Versorgen ausgewählter Ressourcen mit Parametern teilweise durch gespeicherte Anweisungsangaben (p_imm-Operatoren) gesteuert wird, die Direktwertangaben und auf die Ressourcen bezogene Auswahlangaben enthalten.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß das Auslösen der Informationsverarbeitungsvorgänge teilweise durch gespeicherte Anweisungsangaben (y_f-Operatoren) gesteuert wird, die ergänzend zu denauf die Ressourcen bezogene Auswahlangaben Funktionsangaben enthalten.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß wenigstens ein Teil der zur Ausführung der Informationsverarbeitungsvorgänge verwendeten Ressourcen aus anderen Ressourcen durch rekursive Anwendung der Verfahrensschritte 1 bis 8 aufgebaut wird.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß die zur Lösung des jeweiligen Anwendungsproblems dienenden Anweisungsangaben wenigstens teilweise durch rekursive Anwendung der Verfahrensschritte 1 bis 8 erzeugt, transportiert oder verändert werden.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß die Ressourcen aus dem Ressourcenvorrat derart ausgewählt und daß die Verbindungen zwischen den ausgewählten Ressourcen so eingerichtet werden, daß die Ressourcenanordnung dem Datenflußschema des jeweiligen Anwendungsproblems entspricht.
Verfahren nach Anspruch 16, dadurch gekennzeichnet, daß die Ressourcen aus dem Ressourcenvorrat derart ausgewählt und daß die Verbindungen zwischen den ausgewählten Ressourcen so eingerichtet werden, daß die Ressourcenanordnung dem Datenflußschema einer invertierten Baumstruktur entspricht.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß für wenigstens einen Teil der ausgewählten Ressourcen die Ausführung der Verfahrensschritte 3, 4, 5, 6 so in Zeitabschnitte eingeordnet wird, daß in jedem dieser Zeitabschnitte zunächst alle jeweils in Betracht kommenden Verfahrensschritte 3, dann alle jeweils in Betracht kommenden Verfahrensschritte 4 und schließlich alle jeweils in Betracht kommenden Verfahrensschritte 5, 6 gemeinsam ausgeführt werden.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß beim Auswählen einer Ressource aus dem Ressourcenvorrat eine entsprechende Schaltungsanordnung reserviert, eingerichtet und zugeordnet wird.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß beim Auswählen einer Ressource aus dem Ressourcenvorrat entsprechender Speicherplatz reserviert, eingerichtet und zugeordnet wird.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß beim Auswählen einer Ressource aus dem Ressourcenvorrat eine entsprechende Schaltungsanordnung durch Programmierung erzeugt wird.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß die Auswahl- und Verbindungsangaben in den Anweisungsangaben Adreßangaben sind.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß die Auswahl- und Verbindungsangaben in den Anweisungsangaben bitweise wirkende Steuerangaben sind.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß Anweisungsangaben, die gleichzeitig ausführbar sind, zu Steuerworten zusammengefaßt werden.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß das Auslösen der Informationsverarbeitungsvorgänge wenigstens teilweise durch das Anliefern der zu verarbeitenden Parameter veranlaßt wird.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß Ressourcen, denen durch das Einrichten von Verbindungen (c-Operatoren) weitere Ressourcen nachgeordnet wurden, wenigsten Teile der Ergebnisse selbsttätig zu nachgeordneten Ressourcen übertragen.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß Ressourcen, denen durch das Einrichten von Verbindungen (c-Operatoren) weitere Ressourcen nachgeordnet wurden, wenigstens Teile der angelieferten Parameter selbsttätig zu nachgeordneten Ressourcen übertragen.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß wenigstens einige der Übertragungsvorgänge nur dann ausgeführt werden, wenn innerhalb der Ressource bestimmte Bedingungen aufgetreten sind.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß die auf die Ressourcen bezogenen Auswahlangaben Zeigerangaben sind, die auf Parameter in Ressourcen verweisen.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß jedem der zur Einrichtung von Verbindungen vorgesehenen Ergebnisse wenigstens eine Zeigerangabe zugeordnet ist.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß jedem der zur Einrichtung von Verbindungen vorgesehenen Operanden wenigstens eine Zeigerangabe zugeordnet ist.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß jedem der zur Einrichtung von Verbindungen vorgesehenen Operanden zwei Zeigerangaben zugeordnet sind, wobei die erste auf den jeweiligen Vorgänger und die zweite auf den jeweiligen Nachfolger in der betreffenden Verbindung verweist.
Verfahren nach Anspruch 32, dadurch gekennzeichnet, daß das Einrichten einer Verbindung mit einem weiteren Parameter (c-Operator) in folgenden Schritten ausgeführt wird: 1. Eintragen der Auswahlangabe des weiteren Parammeters in die zweite Zeigerangabe des bisher letzten in die betreffende Verbindung einbezogenen Parameters, 2. Eintragen einer Rückverweisangabe auf den bisher letzten in die betreffende Verbindung einbezogenen Parameter in die erste Zeigerangabe des weiteren Parameters.
Verfahren nach Anspruch 32, dadurch gekennzeichnet, daß das Trennen einer Verbindung mit einem ausgewählten Parameter (d-Operator) in folgenden Schritten ausgeführt wird: 1. Eintragen der zweiten Zeigerangabe in die zweite Zeigerangabe des Parameters, der durch die erste Zeigerangabe ausgewählt wird, 2. Eintragen der ersten Zeigerangabe in die erste Zeigerangabe des Parameters, der durch die zweite Zeigerangabe ausgewählt wird.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß wenigstens Teile der in die Ressourcen übertragenen Parameter Wertangaben sind.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß wenigstens Teile der in die Ressourcen übertragenen Parameter Auswahlangaben sind.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß Ressourcen nach dem Auslösen der Informationsverarbeitungsvorgänge wenigstens Teile der zu verarbeitenden Angaben selbsttätig aus den Speichereinrichtungen einlesen.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß Ressourcen nach dem Auslösen der Informationsverarbeitungsvorgänge wenigstens Teile der berechneten Ergebnisse selbsttätig in die Speichereinrichtungen zuückschreiben.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß Ressourcen nach dem Auslösen der Informationsverarbeitungsvorgänge selbsttätig Steuerangaben zur weiteren Steuerung der Verarbeitungsabläufe aus den Speichereinrichtungen lesen.
Verfahren nach Anspruch 26, dadurch gekennzeichnet, daß das Lesen von Steuerangaben durch in den Steuerangaben gespeicherte Funktionscodes beendet wird.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß ein Teil der aus dem Ressourcenvorrat ausgewählten Ressourcen dazu verwendet wird, um die von anderen ausgewählten Ressourcen benötigten Parameter heranzuschaffen.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß ein Teil der aus dem Ressourcenvorrat ausgewählten Ressourcen dazu verwendet wird, um die von anderen ausgewählten Ressourcen gebildeten Ergebnisse abzutransportieren.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß ein Teil der aus dem Ressourcenvorrat ausgewählten Ressourcen dazu verwendet wird, um andere ausgewählte Ressourcen zum Ausführen von Verfahrensschritten zu veranlassen.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß ein Teil der aus dem Ressourcenvorrat ausgewählten Ressourcen dazu verwendet wird, um in anderen ausgewählten Ressourcen anfallende Verwaltungsangaben zu erfassen.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß ein Teil der aus dem Ressourcenvorrat ausgewählten Ressourcen dazu verwendet wird, um in anderen ausgewählten Ressourcen zwecks Fehlersuche und Ablaufverfolgung einzugreifen.
Verfahren nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß Verzweigungen in der Abfolge der Verfahrensschritte in folgenden Schritten ausgeführt werden: 1. Einstellen der Verzweigungsangaben, 2. Übertragen der Bedingungen, die die Verzweigungsrichtung bestimmen, 3. Auslösen des Verzweigungsablaufs.
Vorrichtung zur Durchführung des Verfahrens nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß Plattformanordnungen (1), Speichermittel (2) und Verarbeitungsressourcen (3) vorgesehen und über Signalwege (4 ... 8) untereinander verbunden sind.
Vorrichtung nach Anspruch 47, dadurch gekennzeichnet, daß die Signalwege als Bussysteme (4 ... 7) ausgebildet sind.
Vorrichtung nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß die Signalwege als Punkt-zu-Punkt-Verbindungen (8) ausgebildet sind.
Vorrichtung nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß die Signalwege an Schaltverteiler (9) angeschlossen sind.
Vorrichtung nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß die einzelne Verarbeitungsressource als programmierbarer Universalrechner ausgebildet ist.
Vorrichtung nach Anspruch 51, dadurch gekennzeichnet, daß interne Caches und andere Pufferspeicher des programmierbaren Universalrechners für Zugriffe anderer Einrichtungen zugänglich sind.
Vorrichtung nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß die einzelne Verarbeitungsressource aus eingangsseitigen Speichermitteln, nachgeordneten Verarbeitungsschaltungen und wiederum nachgeordneten ausgangsseitigen Speichermitteln besteht.
Vorrichtung nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß die einzelne Verarbeitungsressource ergänzend zu den eingangsseitigen und ausgangsseitigen Speichermitteln weitere Speichermittel enthält, die zur Ausführung der Informationswandlungen erforderliche Angaben enthalten.
Vorrichtung nach Anspruch 54, dadurch gekennzeichnet, daß die zur Ausführung der Informationswandlungen erforderlichen Angaben Programmsteuerangaben sind.
Vorrichtung nach Anspruch 54, dadurch gekennzeichnet, daß die zur Ausführung der Informationswandlungen erforderlichen Angaben eine entsprechende Schaltungsanordnung beschreiben.
Vorrichtung nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß eingangsseitige Speichermittel als Operandenregister und ausgangsseitige Speichermittel als Ergebnisregister ausgebildet sind.
Vorrichtung nach Anspruch 53, dadurch gekennzeichnet, daß Teilen der eingangsseitigen Speichermittel Funktionssteuereingänge der Verarbeitungsschaltungen nachgeordnet sind.
Vorrichtung nach Anspruch 58, dadurch gekennzeichnet, daß die genannten Teile der eingangsseitigen Speichermittel als Funktionscoderegister (61) ausgebildet sind.
Vorrichtung nach Anspruch 53, dadurch gekennzeichnet, daß wenigstens Teile der ausgangsseitigen Speichermittel zum Auslösen von Verkettungsabläufen ausgebildet sind.
Vorrichtung nach Anspruch 53, dadurch gekennzeichnet, daß wenigstens Teile der eingangsseitigen Speichermittel für Schreibzugriffe ausgebildet sind, die von Verkettungsabläufen veranlaßt werden.
Vorrichtung nach Anspruch 53, dadurch gekennzeichnet, daß wenigstens Teilen der eingangsseitigen und ausgangsseitigen Speichermittel Adressierungs- und Datentransporteinrichtungen zugeordnet sind.
Vorrichtung nach Anspruch 62, dadurch gekennzeichnet, daß die Adressierungs- und Datentransporteinrichtungen so ausgebildet sind, daß den Operanden- und Ergebnisregistern Adreßregister (40, 41) zugeordnet sind, daß eine Ablaufsteuerschaltung für Speicherzugriffe (43) vorgesehen ist, daß den Adreßregistern (40, 41) Speicheradreßleitungen nachgeschaltet sind und daß die Operanden- und Ergebnisregister mit Speicherdatenleitungen verbunden sind.
Vorrichtung nach Anspruch 59, dadurch gekennzeichnet, daß dem Funktionscoderegister (61) ein Funktionscodeadreßregister (60) zugeordnet ist.
Vorrichtung nach Anspruch 64, dadurch gekennzeichnet, daß das Funktionscodeadreßregister (60) als Befehlszähler ausgebildet und eingangsseitig mit Teilen des Funktionscoderegisters (61) beschaltet ist.
Vorrichtung nach Anspruch 65, dadurch gekennzeichnet, daß das Funktionscodeadreßregister (60) eingangsseitig zusätzlich mit Ergebnissignalen der eigentlichen Verarbeitungsschaltungen beschaltet ist.
Vorrichtung nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß die Speichermittel um Kennzeichnungsbits erweitert sind, die die Zugriffsbreite angeben.
Vorrichtung nach Anspruch 67, dadurch gekennzeichnet, daß die Kennzeichnungsbits zu Verarbeitungsbreitenregistern zusammengefaßt sind.
Vorrichtung nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß die ein- und ausgangseitigen Speichermittel mit einer Systemanschlußsteuerung (10) verbunden sind, die ihrerseits an die Signalwege des Systems (4, 8) angeschlossen ist.
Vorrichtung nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß die Plattformeinrichtungen einen Befehlszähler (IC), ein Befehlsregister (IR), ein Verzweigungsadreßregister (BA), ein Verzweigungsbedingungsregister (BCTL) und ein Bedingungsbitregister (BC) enthalten.
Vorrichtung nach Anspruch 70, dadurch gekennzeichnet, daß dem Befehlszähler (IR) Zustandspuffer (SB) nachgeschaltet sind und zusammen mit dem Befehlszähler den Verarbeitungsressourcen vorgeordnet ind.
Vorrichtung nach Anspruch 71, dadurch gekennzeichnet, daß die Zustandspuffer (SB) als Halteregisteranordnung ausgebildet sind.
Vorrichtung nach Anspruch 71, dadurch gekennzeichnet, daß die Zustandspuffer (SB) als adressierbare Registerspeicheranordnung ausgebildet sind.
Vorrichtung nach Anspruch 71, dadurch gekennzeichnet, daß die Zustandspuffer (SB) als Stack-Anordnung ausgebildet sind.
Vorrichtung nach Anspruch 70, dadurch gekennzeichnet, daß dem Befehlsregister (IR) ein Sprungzielpuffer (BTB) vorgeordnet ist.
Vorrichtung nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß die Plattformeinrichtungen einen Befehlszähler (IC), ein Befehlsregister (IR), einen Verzweigungsadreßpuffer (11), einen Verzweigungszielpuffer (12), einen Verzweigungsbedingungspuffer (13) und ein Bedingungsbitregister (BC) enthalten, wobei die Puffer (11, 12, 13) jeweils mehr als eine Speicherposition haben.
Vorrichtung nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß die Plattformeinrichtungen Basiadreßregister (SP, FP, GP) mit nachgeordnetem Adreßaddierer enthalten, der andererseits mit Teilen des Befehlsregisters (IR) beschaltet ist und daß die Plattformeinrichtungen zur Unterstützung der Relativadressierung (Basis + Displacement) sowie des Eintretens in Unterprogramme und des Verlassen von Unterprogrammen (Enter, Leave) ausgebildet sind.
Vorrichtung nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß die Speichermittel (2) wenigstens teilweise für Zugriffe durch Adressierung eingerichtet sind.
Vorrichtung nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß die Speichermittel (2) wenigstens teilweise für assoziative Zugriffe eingerichtet sind.
Vorrichtung nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß wenigstens ein Teil der Speichermittel (2) zum Ressourcenvorrat gehört.
Vorrichtung nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß die Speichermittel (2) als Programmspeicher (25) und Datenspeicher (26) ausgebildet sind, daß die Adreßeingänge des Programmspeichers (25) an Aktivierungsressourcen (27) angeschlossen sind, daß den Datenausgängen des Programmspeichers (25) Interpreterressourcen (28) nachgeschaltet sind und daß der Datenspeicher (26) mit einer Verarbeitungsressourcensammlung (29) verbunden ist.
Vorrichtung nach Anspruch 81, dadurch gekennzeichnet, daß die Adreßwege (30, 33, 34a) des Programmspeichers (25) und des Datenspeichers (26) zu einem Adreßbus und die Datenwege (31, 34b) der Speicher (25, 26) zu einem Datenbus zusammengeschaltet sind und daß beide Speicher (25, 26) zu einem universellen Speicher zusammengefaßt sind.
Vorrichtung nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß die Signalwege (4 ... 8) Signalprotokolle zum Befehlslesen unterstützen, daß wenigstens Teile der Verarbeitungsressourcen (3) mit Befehlszugriffssteuerschaltungen ausgerüstet sind und daß die Speichermittel (2) wenigstens in Teilen so ausgebildet sind, daß bei Befehlzugriffen gelesene Speicherinhalte (38) zur jeweils ausgewählten Plattform transportiert werden.
Vorrichtung nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß die Adressierungseinrichtungen als Adreßregister ausgebildet sind.
Vorrichtung nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß die Adressierungseinrichtungen als Adreßzähler ausgebildet sind.
Vorrichtung nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß die Adressierungseinrichtungen als Adreßaddierer ausgebildet sind, denen jeweils ein Basisadreßregister und ein Displacementregister vorgeschaltet sind.
Vorrichtung nach Anspruch 86, dadurch gekennzeichnet, daß das Basisadreßegister (A) und das Displacementregister (B) an einen Adreßaddierer (52) angeschlossen sind, der ausgangsseitig mit den Speicheradreßleitungen verbunden ist und daß dem Basisadreßregister (B) und einem Abstandswertegister (D) ein Displacementaddierer (53) nachgeschaltet ist, dessen Ausgänge auf das Displacementregister (B) zurückgeführt sind.
Vorrichtung nach Anspruch 87, dadurch gekennzeichnet, daß in die Verbindung zwischen Adreßaddierer (48) und Displacementregister (B) ein Multiplizierer (50) eingefügt ist, dem ein Längenregister (C) vorgeordnet ist.
Vorrichtung nach einem der Ansprüche 87 oder 88, dadurch gekennzeichnet, daß zwischen dem Basisadreßregister (A) und dem Adreßaddierer (52) eine Auswahlschaltung angeordnet ist, auf deren zweite Eingänge die Ausgänge eines dem Adreßaddierer (52) nachgeordneten Speicheradreßregisters (X) zurückgeführt sind.
Vorrichtung nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß Teile der Verarbeitungsressourcen als Iteratorschaltungen ausgebildet sind, die ein Anfangswertregister (A), ein Schrittweitenregister (B), ein Endwertregister (C) und ein Schleifenwertregister (X) enthalten, daß dem Schleifenwertregister (X) über eine Auswahlschaltung das Anfangswertregister (A) und ein Addierer vorgeordnet ist, der mit dem Schrittweitenregister (B) und mit dem rückgeführten Schleifenwertregister (X) beschaltet ist, daß dem Schleifenwertregister (X) weiterhin ein Vergleicher nachgeordnet ist, dem anderseits das Endwertregister (C) vorgeschaltet ist und daß dem Ausgang des Vergleichers ein Endebedingungssignal nachgeordnet ist.
Vorrichtung nach den Ansprüchen 85 und 90, dadurch gekennzeichnet, daß die Adreßzähler als Iteratorschaltungen ausgebildet sind, wobei die Speicheradresse dem Schleifenwertregister (X) nachgeordnet ist.
Vorrichtung nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß Teile der Verarbeitungsressourcen als Speicherzugriffsressourcen ausgebildet sind, die einerseits mit einer Speicherschnittstelle und andererseits mit Übergabeschnittstellen für nachgeordnete Verarbeitungsressourcen ausgerüstet sind.
Vorrichtung nach Anspruch 92, dadurch gekennzeichnet, daß die Adreßanschlüsse der Speicherschnittstelle einer Iteratorschaltung (55) nachgeschaltet sind, daß die Datenleitungen der Speicherschnittstelle an einen Speicherdatenpuffer (56) angeschlossen sind, daß jede der Übergabeschnittstellen aus einem Datenpuffer (57) und einer Verkettungssteuerung (58) besteht, daß der Speicherdatenpuffer (56) mit den Datenpuffern (57) der Übergabschnittstellen verbunden ist und daß dem Restwertausgang der Iteratorschaltung (55) ein Restwertdecoder (59) nachgeschaltet ist, dessen Ausgänge einzeln an die Erlaubniseingänge der Verkettungssteuerungen (58) angeschlossen sind.
Vorrichtung nach Anspruch 93, dadurch gekennzeichnet, daß die Iteratorschaltung (55) ein Anfangswertregister (A), ein Schrittweitenregister (B), ein Endwertregister (C), ein Parallelisierungsgradregister (P) und ein Schleifenwertregister (X) enthält, daß dem Schleifenwertregister (X) über eine Auswahlschaltung das Anfangswertregister (A) und ein Addierer vorgeordnet sind, daß der Addierer mit dem Schrittweitenregister (B) und mit dem rückgeführten Schleifenwertregister (X) beschaltet ist, daß dem Schleifenwertregister (X) weiterhin eine Subtraktionsschaltung nachgeordnet ist, der anderseits das Endwertregister (C) vorgeschaltet ist, daß der Subtraktionsschaltung der Restwertausgang nachgeordnet ist und daß der Restwertausgang und das Parallelisierungsgradregister (P) an eine Vergleichsschaltung angeschlossen sind, deren Ausgang ein Endebedingungssignal nachgeordnet ist.
Vorrichtung nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß wenigstens Teile der Verarbeitungsressourcen als Arithmetik-Logik-Einheiten ausgebildet sind.
Vorrichtung nach Anspruch 95, dadurch gekennzeichnet, daß die Verarbeitungsschaltungen der Arithmetik-Logik-Einheit eingangsseitig mit vier Operandenregistern (A, B, C, D) sowie einem Funktionscoderegister (FC) und ausgangsseitig mit zwei Ergebnisregistern (X, Z) sowie einem Bedingungsregister (Flags) beschaltet sind.
Vorrichtung nach Anspruch 96, dadurch gekennzeichnet, daß eines der beiden Ergebnisregister (Z) als bidirektionales Datenregister für Speicherdaten ausgebildet ist.
Vorrichtung nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß wenigstens Teile der Speichermittel um zusätzliche Speichereinrichtungen erweitert sind, die mit einer Zugriffssteuerung verbunden sind.
Vorrichtung nach Anspruch 98, dadurch gekennzeichnet, daß die zusätzlichen Speichereinrichtungen als Zeigerregister ausgebildet sind, die an ausgangsseitige Adreßwege angeschlossen sind.
Vorrichtung nach Anspruch 99, dadurch gekennzeichnet, daß wenigstens Teile der eingangsseitigen Speichermittel an Vergleichsschaltungen angeschlossen sind, die der Zugriffsteuerung vorgeordnet sind
Vorrichtung nach Anspruch 99, dadurch gekennzeichnet, daß die zusätzlich zu den Zeigerregistern Zustandsregister vorgesehen sind, die an die Zugriffssteuerung angeschlossen sind.
Vorrichtung nach Anspruch 101, dadurch gekennzeichnet, daß die Zugriffssteuerung zur Ausführung von Zugriffen mit jenen Zeigerregisterinhalten ausgebildet ist, die im jeweiligen Zustandsregister als aktiv ausgewiesen sind.
Vorrichtung nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß Verarbeitungsressourcen an lokale Speichermittel angeschlossen sind und daß sowohl die Ressourcen als auch die lokalen Speichermittel über Anschlußsteuerungen mit dem Rest des Systems verbunden sind.
Vorrichtung nach Anspruch 103, dadurch gekennzeichnet, daß Anordnungen aus Verarbeitungsressourcen und Speichermitteln zu aktiven Speicheranordnungen zusammengefaßt sind, in denen alle Speichermittel in gleicher Weise an die Adreßwege angeschlossen sind.
Vorrichtung nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß Verarbeitungsressourcen in Speichereinrichtungen eingebaut sind.
Vorrichtung nach Anspruch 105, dadurch gekennzeichnet, daß die ein- und ausgangsseitigen Speichermittel der Verarbeitungsressourcen Speicherzellen der jeweiligen Speichereinrichtung sind.
Vorrichtung nach Anspruch 105, dadurch gekennzeichnet, daß die Verarbeitungsschaltungen der Verarbeitungsressourcen für wenigstens einen Teil jener Informationswandlungen ausgelegt sind, die in den betreffenden Speichereinrichtungen jeweils vorrangig auszuführen sind.
Vorrichtung nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß Verarbeitungsressourcen in Cache-Anordungen eingebaut und an die Datenteile der Cache-Blöcke angeschlossen sind.
Vorrichtung nach Anspruch 108, dadurch gekennzeichnet, daß die Ablaufsteuerschaltungen der eingebauten Verarbeitungsressourcen dem Assoziativteil des jeweiligen Cache-Blockes nachgeordnet sind.
Vorrichtung nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß Verarbeitungsressourcen mit Registern eines Registersatzes verbunden sind, wobei jeweils einige der Register als Operandenregister und Kommandoregister vorgeschaltet und andere als Ergebnisregister nachgeschaltet sind.
Vorrichtung nach Anspruch 110, dadurch gekennzeichnet, daß Ausgänge der Verarbeitungsressourcen auf einen Teil der eingangsseitigen Operandenregister zurückgeführt sind.
Vorrichtung nach einem der Ansprüche 110 oder 111, dadurch gekennzeichnet, daß die Verarbeitungsressourcen ausgangsseitig mit Operandenregistern jeweils nachfolgender Verarbeitungsressourcen verbunden sind.
Vorrichtung nach einem der Ansprüche 110 bis 112, dadurch gekennzeichnet, daß der Registersatz zusätzlich zu den Verbindungen mit den Verarbeitungsressourcen an weitere Zugriffswege angeschlossen ist, wobei die Operanden- und Kommandoregister für Schreibzugriffe und die Ergebnisregister für Lesezugriffe ausgebildet sind.
Vorrichtung nach Anspruch 113, dadurch gekennzeichnet, daß die weiteren Zugriffswege unabhängige Schreiberlaubnissignale für jene Register enthalten, die für Schreibzugriffe eingerichtet sind.
Vorrichtung nach nach einem der Ansprüche 105 oder 106, dadurch gekennzeichnet, daß nicht alle ein- und ausgangsseitigen Speichermittel der Verarbeitungsressourcen Speicherzellen der jeweiligen Speichereinrichtung sind und daß ein Teil dieser Speichermittel an weitere Verbindungseinrichtungen angeschlossen ist.
Vorrichtung nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß aus Verarbeitungsressourcen und Speichermitteln bestehende Ressourcenzellen auf dem Schaltkreis in Reihen angeordnet sind und daß zwischen den Reihen Bussysteme vorgesehen sind, wobei die Bussysteme jeweils mit den Ausgängen der darüberliegenden und mit den Eingängen der darunterliegenden Reihe beschaltet sind.
Vorrichtung nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß die aus Verarbeitungsressourcen und Speichermitteln bestehenden Ressourcenzellen als invertierte Baumstrukturen verschaltet sind.
Vorrichtung nach Anspruch 117, dadurch gekennzeichnet, daß die invertierten Baumstrukturen zwischen zwei Bussystemen angeordnet sind, wobei die Ein- und Ausgänge der aufeinanderfolgend angeordneten invertierten Baumstrukturen umschichtig an beide Bussysteme angeschlossen sind.
Vorrichtung nach einem der Ansprüche 117 oder 118, dadurch gekennzeichnet, daß die jeweils letzten Ressourcenzellen der invertierten Baumstrukturen mit Speicheranordnungen beschaltet sind, die als Stack Caches ausgebildet sind.
Vorrichtung nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß aus Verarbeitungsressourcen und Speichermitteln bestehende Ressourcenzellen (89) an Schaltverteiler (90) angeschlossen sind, die ihrerseits über programmierbare Signalwege (91) untereinander verbunden sind.
Vorrichtung nach einem der Ansprüche 116 bis 120, dadurch gekennzeichnet, daß die einzelne Ressourcenzelle (88) aus programmierbaren Logikzellen mit programmierbaren Verbindungen aufgebaut ist, daß die Eingänge der Ressourcenzelle (92) über programmierbare Signalwege (93) eingangsseitigen harten Ressourcenschnittstellen (94) nachgeschaltet sind und daß die Ausgänge der Ressourcenzelle (92) über weitere programmierbare Signalwege (95) an harte ausgangsseitige Ressourcenschnittstellen (96) angeschlossen sind.
Vorrichtung nach Anspruch 121, dadurch gekennzeichnet, daß sämtliche Register der harten Ressourcenschnittstellen (94, 96) mit Zugriffs- und Verkettungsvorkehrungen versehen sind.
Vorrichtung nach einem der Ansprüche 121 oder 122, dadurch gekennzeichnet, daß die Programmiersignalwege der programmierbaren Logikzellen und der programmierbaren Verbindungen wenigstens teilweise an fest verschaltete Ressourcenanordnungen angeschlossen sind.
Vorrichtung nach Anspruch 123, dadurch gekennzeichnet, daß die Programmiersignalwege der programmierbaren Logikzellen und der programmierbaren Verbindungen wenigstens teilweise an eine Plattformeinrichtung angeschlossen sind.
Vorrichtung nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß die Übernahmesteuereingänge der eingangsseitigen und die Aufschalterlaubniseingänge der ausgangsseitigen Speichermittel Adreßdecodern nachgeordnet sind.
Vorrichtung nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß die Übernahmesteuereingänge der eingangsseitigen und die Aufschalterlaubniseingänge der ausgangsseitigen Speichermittel Adreßvergleichern (97) mit jeweils vorgeschalteter Adreßeinstellung (98) nachgeordnet sind.
Vorrichtung nach Anspruch 126, dadurch gekennzeichnet, daß wenigstens einem Teil der Adreßvergleicher (97) mit jeweils vorgeschalteter Adreßeinstellung (98) jeweils ein zusätzlicher Adreßvergleicher (97a) mit vorgeschaltetem Adreßregister (98a) zugeordnet ist, wobei die jeweiligen Übernahmesteuereingänge der eingangsseitigen und die Aufschalterlaubniseingänge der ausgangsseitigen Speichermittel jeweils beiden Adreßvergleichern (97, 97a) in disjunktiver Verknüpfung nachgeordnet sind.
Vorrichtung nach Anspruch 127, dadurch gekennzeichnet, daß den Ausgängen der zuätzlichen Adreßvergleicher (97a) eine Trefferanzeigeleitung (ADRS HIT) nachgeschaltet ist.
Vorrichtung nach einem der Ansprüche 127 oder 128, dadurch gekennzeichnet, daß die den zusätzlichen Adreßvergleichern (97a) vorgeschalteten Adreßregister (98a) in der jeweiligen Ressource eingangsseitig wie weitere Operandenregister angeschlossen sind.
Vorrichtung nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß die Übernahmesteuereingänge der eingangsseitigen und die Aufschalterlaubniseingänge der ausgangsseitigen Speichermittel an Steuerleitungen angeschlossen sind, die der Plattform nachgeordnet sind.
Vorrichtung nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß die ein- und ausgangsseitigen Speichermittel als adressierbare Speicheranordnungen ausgebildet sind, die gemeinsam mit einer Auswahladressse beschaltet sind.
Vorrichtung nach Anspruch 131, dadurch gekennzeichnet, daß die Auswahladresse Teil einer Ressourcenadresse ist.
Vorrichtung nach Anspruch 131, dadurch gekennzeichnet, daß die Auswahladresse Teil einer von der Plattform gelieferten Tasknummer ist.
Vorrichtung nach Anspruch 131, dadurch gekennzeichnet, daß die Speichermittel zusätzlich an weitere unabhängige Zugriffsweg angeschlossen sind.
Vorrichtung nach den einem der Ansprüche 131 bis 134, dadurch gekennzeichnet, daß die Auswahladresse einer Auswahlschaltung nachgeordnet ist, die einerseits mit den Adreßsignalen der weiteren Zugriffswege und andererseits mit weiteren Auswahlschaltungen verbunden ist, denen die Teile der Ressourcenadresse und der Tasknummer vorgeordnet sind.
Vorrichtung nach einem der vorherigen Ansprüche, dadurch gekennzeichnet, daß die Verarbeitungsressourcen zusätzlich mit Vorkehrungen zur Systemverwaltung, zur Leistungsmessung und zum Fehlersuchen ausgerüstet sind.
Vorrichtung nach Anspruch 136, dadurch gekennzeichnet, daß die Vorkehrungen zur Systemverwaltung, zur Leistungsmessung und zum Fehlersuchen an zusätzliche Signalwege angeschlossen sind.
Vorrichtung nach Anspruch 136, dadurch gekennzeichnet, daß die zusätzlichen Vorkehrungen zur Systemverwaltung Ver- und Entschlüsselungseinrichtungen enthalten, die zwischen den Verbindungen mit den allgemeinen Signalwegen und den internen Signalwegen der Ressource angeordnet sind.
Vorrichtung nach Anspruch 136, dadurch gekennzeichnet, daß die zusätzlichen Vorkehrungen zur Systemverwaltung Einrichtungen zur Eigentümerkennzeichnung enthalten.
Vorrichtung nach Anspruch 139, dadurch gekennzeichnet, daß die Einrichtungen zur Eigentümerkennzeichnung Autorisierungsvorkehrungen enthalten und mit den internen Steuerschaltungen der Ressource verbunden sind.