Betrachtet man nur eine einzige, in Parameterzahl und Wirkungsweise einfache Ressource, so gibt es keinen grundsätzlichen Unterschied zu den herkömmlichen Rechnerarchitekturen (Abb. 2). Es ist lediglich die Frage, ob die Vorgänge (das Heranschaffen der Operanden usw.) implizit gesteuert werden (Befehlsablaufsteuerung) oder ob sie von einzeln codierten Ablaufsteuerangaben ausgelöst werden. In diesem Sinne hat die ReAl-Achitektur eine gewisse Ähnlichkeit mit der (vertikalen) Mikroprogrammsteuerung. Die Vorteile kommen dann zur Wirkung, wenn man (1) mit mehr als einer Ressource arbeitet und wenn man (2) das Prinzip auf den gesamten Programmablauf anwendet.

erkettung

Funktionseinheiten der Hardware können zu komplexeren Anordnungen zusammengeschaltet werden. Eine solche (spezielle) Hardware entspricht dem Datenflußschema der jeweiligen Informationswandlungen (Abb. 3). Sinngemäß soll es möglich sein, Ressourcen zu solchen Datenflußschemata zu verketten und die Verkettung wieder zu trennen.

Abb. 2 Zum Vergleich: ein elementarer Verarbeitungsablauf in einem herkömmlichen Universalrechner (hier: einer Dreiadreßmaschine).

Abb. 3 Verkettete Ressourcenanordung zum Berechnen von (A + B) * (C + D).

Die elementaren Operatoren:

1. Ressourcen auswählen = s-Operator (select)

2. mit Parametern versorgen = p-Operator (parameter)

3. Operation(en) ausführen (laufen lassen): y-Operator (yield) = umgekehrtes Lambda

4. Ergebnisse abholen = a-Operator (assign)

5. Transportieren von Parametern zwischen Ressourcen = l-Operator (link)

6. Netzlistenbeschreibung, Verkettung, Datenflußprinzip = c-Operator (connect)

7. Verkettungen trennen = d-Operator (disconnect)

8. Ressourcen wieder zurück- bzw. freigeben = r-Operator (release)

Weitere Operatoren:

1. Hinweise = h-Operator

2. metasprachliche Angaben = m-Operator

3. Verwaltungsfunktionen = u-Operator (Utility)

Parameter:

1. Eingänge (Operanden; IN-Typ)

2. Ausgänge (Ergebnisse; OUT-Typ)

3. Ein- und Ausgänge (INOUT-Typ)

Parameterübergabe

Grundsätzlich als Wert (by Value). Ist das nicht ohne weiteres möglich, sind zusätzliche Ressourcen vorzusehen, die die Werte heranschaffen und abtransportieren.

Notation von ReAl-Verarbeitungsabläufen

Notationsweisen im Überblick:

1. Umgangssprachliche Notation. Stil “Kochbuch” (“man nehme ein Addierwerk” usw.). Zu weitschweifig.

2. ReAl-Textcode (Zeichenketten). Formalisierte Notation. Die Ressourcen, Parameter usw. werden durchnumeriert (Ordinalzahlen). Alternativ dazu können symbolische Bezeichner angegeben werden.

3. ReAl-Bytecode. Eine kompakte, binär codierte Darstellung; aus dem Textcode abgeleitet.

4. ReAl-Maschinencode. Binär. Maschinenspezifisch.

Wir verwenden im folgenden den ReAl-Textcode.

Kommentare:

Mit -- eingeleitet (vgl. Programmiersprache ADA).

Kennzeichnung der Parameter im Textcode

Durch einfaches Durchnumerieren: zuerst die Eingänge, dann die Ein- und Ausgänge, dann die Ausgänge (Abb. 4).

Symbolische Bezeichner

Anstelle der Ordinalzahlen können symbolische Bezeichner (Eigennamen) angegeben werden.

Abb. 4 Ressourcen mit durchnumerierten Parametern.

Kurzüberblick über die hier verwendete Syntax des Textcodes:

Ressourcentyp := Ordinalzahl oder Eigenname

Ressource := Ordinalzahl oder Eigenname

Parameter := Ordinalzahl oder Eigenname

Zuweisung := => (Pfeil symbolisiert Übertragungsrichtung)

Zuordnung eines Eigennamens := Ordinalzahl : Eigenname

Parameter einer bestimmten Ressource: Ressource . Parameter

Leerzeichen können beliebig eingefügt oder weggelassen werden.

Zuordnung von Ordinalzahlen:

• Ressourcentypen: gemäß Reihenfolge in der Ressourcentyptabelle,

• Parameter: gemäß Reihenfolge in der Parameterliste des Ressourcentyps,

• Ressourcen: gemäß Reihenfolge der Ressourcentypangaben im s-Operator oder gemäß besonderen Zuweisungsangaben.

Hinweis zur Numerierung 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).

Zuordnung von Eigennamen:

• Ressourcentypen: vorgegeben (gemäß Ressourcentyptabelle oder Systemhandbuch). Kann bedarfsweise überladen werden (u-Operatoren resource name/rename (rn, rrn)):

u_rn (Ordinalzahl : Eigenname)

u_rrn (bisheriger Eigenname : neuer Eigenname)

• Parameter: vorgegeben (gemäß Ressourcentyptabelle oder Systemhandbuch). Kann bedarfsweise überladen werden (u-Operatoren parameter name/rename (pn/prn)).

u_pn (Ordinalzahl : Eigenname)

u_prn (bisheriger Eigenname : neuer Eigenname)

• Ressourcen: im s-Operator (Ressourcentyp : Eigenname).

Elementare Operatoren

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. Bezeichner.

In einer weiteren Auslegung können die s-Operatoren auch explizite Angaben der Bezeichner, Ordinalzahlen oder Adressen enthalten, die den angeforderten Ressourcen zugewiesen werden:

s (1. Ressourcentyp => 1. Ressourcennummer, 2. Ressourcentyp => 2. Ressourcennummer usw.).

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.

Operation(en) ausführen: y-Operator:

y (1. Ressource, 2. Ressource usw.)

Der y-Operator löst die Verarbeitung in den angegebene 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).

Ergebnisse abholen: 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.

Transportieren von Parametern (vom Ausgang zum Eingang): 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.

Verkettung herstellen (vom Ausgang zum Eingang): c-Operator:

c (1. Quell-Ressource . 1. Ergebnis => 1. Ziel-Ressource . 1. Parameter, 2. Quell-Ressource . 2. Ergebnis => 2. Ziel-Ressource . 2. Parameter usw.)

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. Die Ressourcen sind zu verketten, bevor die betreffenden Verarbeitungsfunktionen ausgelöst werden (y-Operator).

Verkettung 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. Anschließend können die Ressourcen anderweitig verkettet oder auch einzeln betrieben werden.

Ressource(n) freigeben: r-Operator:

r (1. Ressource, 2. Ressource usw.)

Die angegebenen Ressourcen werden freigegeben. Sie stehen somit für andere Verarbeitungsaufgaben zur Verfügung

Beispiel:

• Programmierabsicht: X := (A + B) * (C + D)

• nutzbare Ressourcentypen: ADD, MULT

Abb. 5 veranschaulicht die Ressourcenanordnung. Zur Verkettung vgl. Abb. 3.

Ausführliche Notation (jeder Vorgang einzeln):

s (ADD, ADD, MULT)

p (A => 1.1)

p (B => 1.2)

p (C => 2.1)

p (D => 2.2)

y (1)

y(2)

l (1.3 => 3.1)

l (2.3 => 3.2)

r (1, 2)

y (3)

a (3. 3 => X)

r (3)

Verkürzte Notation:

s (ADD, ADD, MULT)

p (A => 1.1, B => 1.2, C => 2.1, D => 2.2)

y (1, 2)

l (1.3 => 3.1, 2.3 => 3.2)

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)

a (3.3 => X)

r (1, 2, 3)

Abb. 5 Die Ressourcenanordnung des Beispiels.

ReAl und gegebene Programmiersprachen

ReAl ist zunächst eine maschinenunabhängige Zwischensprache (ähnlich dem bekannten Java-Bytecode). Das Ziel besteht aber nicht darin, mit möglichst wenigen Bytes auszukommen (Code-Kompression), sondern darin, wesentliche Feinheiten des Verarbeitungsprozesses genau zu beschreiben. ReAl wäre in diesem Sinne beispielsweise mit PostScript zu vergleichen. Typische Ziele:

• Den innewohnenden (inhärenten) Parallelismus bereits in statu nascendi zu erfassen,

• so zu tun, als ob es immer genügend Hardware gäbe. Damit ist der ReAl-Code invariant gegen die technologische Entwicklung.

• so zu tun, als könne man ohne weiteres spezielle Hardware bauen (durch Verkettung usw.). Somit sind je nach den Kosten- und Leistungszielen und nach dem Stand der Technologie Hard- und Software gegeneinander austauschbar.

Nutzungs-Szenarien:

• herkömmliche Programmiersprache => ReAl-Beschreibung,

• neuartige (ressourcenorientierte) Programmiersprache => ReAl-Beschreibung,

• ReAl-Beschreibung => ReAl Interpreter auf gegebener Maschine,

• ReAl-Beschreibung => compilierter Code für gegebene Maschine,

• ReAl-Beschreibung => Code für ReAl-Maschine.

Die hier verwendeten Notationen sind 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 ReAl-Textcode soll vielmehr kurz sein, um entsprechende Darstellungen programmtechnisch effektiv auswerten zu können (Durchmusterung, Analyse, Wandlung, Übersetzung usw.).

ReAl-Programme sind im Grunde Herstellungsanweisungen („man nehme ... und führe folgende Schritte aus ...“). Sie eignen sich also nur wenig zum Erfassen von Programmierabsichten (Gleichnis aus dem Maschinenbau: man wird eine Drehbank oder einen Verbrennungsmotor zunächst zeichnerisch darstellen und nicht sofort – unmittelbar vom Erfindungsgedanken ausgehend – eine Fertigungsdokumentation ausarbeiten).

Die Standardisierung von Ressourcen und einschlägigen Beschreibungsmitteln ist vor allem für die Nutzung als universelle Metasprache von Bedeutung.