imported>B.A.Enz: Änderung 265767670 von ~2026-77782-1 rückgängig gemacht; kein Tippfehler. Im Dativ mit Artikel schwache Deklination.

2026-03-31T14:09:37Z

Änderung 265767670 von ~2026-77782-1 rückgängig gemacht; kein Tippfehler. Im Dativ mit Artikel schwache Deklination.

Neue Seite

Eine '''Datenfluss-Architektur''' ist eine alternative [[Rechnerarchitektur]] zur sogenannten [[Von-Neumann-Architektur]], nach der die allermeisten heute gängigen Rechner [[Implementierung|implementiert]] sind. Ein nach der [[Datenfluss]]-Architektur implementierter Rechner heißt '''Datenflussrechner'''. Datenflussrechner versuchen, die Möglichkeiten der Parallelverarbeitung ihrer Rechenaufträge durch das [[Nebenläufigkeit|nebenläufige]] Ausführen einer Vielzahl von [[Thread (Informatik)|Threads]] auszunutzen. Implementierungen dieser Architektur waren experimentelle [[Mehrprozessorsystem|Multiprozessorrechner]], einen kommerziellen Erfolg konnten Rechner dieser Art nicht verbuchen. Nachteilige Eigenschaften der Datenfluss-Architektur veranlassten die Entwicklung hybrider Rechner, welche die Vorteile sowohl der Datenfluss-Architektur als auch der Von-Neumann-Architektur vereinten; viele Konzepte, die typisch für die Datenfluss-Architektur sind, „überlebten“ auf diese Weise und sind aufgrund dieser Entwicklung in den allermeisten heutigen Rechnern wiederzufinden.

== Motivation für die Entwicklung der Datenfluss-Architektur ==
Ein Von-Neumann-Rechner arbeitet einen sequenziellen [[Prozess (Informatik)|Prozess]] in einem [[Adressraum#Gebräuchliche Speicheradressräume|linearen Adressraum]] ab; der Grad an [[Nebenläufigkeit]], der dabei ausgenutzt werden kann, ist ziemlich gering. Im Unterschied dazu verarbeitet ein Datenflussrechner im Allgemeinen mehrere Threads von [[Maschinenbefehl]]en, die einen sogenannten ''Datenflussgraphen'' beschreiben, die in der Regel einen hohen Grad an Nebenläufigkeit besitzen.

[[Mehrprozessorsystem|Multiprozessorsysteme]] im Von-Neumann-Kontext bringen zwei zentrale Probleme mit sich: Die [[Antwortzeit|Latenzzeit]] beim Speicherzugriff, also die Zeit, die zwischen einer Speicheranfrage und der Antwort des Speichersystems vergeht, und das Problem der Synchronisation; damit ist die Notwendigkeit des ordnungserhaltenden Ausführens der Maschineninstruktionen gemäß der [[Datenabhängigkeit]]en gemeint. Als Alternative wurde das Datenfluss-Modell entwickelt; Rechner, die es implementieren, sollten nach der Vorstellung ihrer Entwickler eher imstande sein, mit den genannten Problemen umzugehen.<ref name="Nr1">J. Silic, B. Robic und T. Ungerer: ''Asynchrony in parallel computing: From data flow to multithreading''. Technical report CSD, Computer Systems Department, Josef Stefan Institute, Ljubljana, Slowenien, 1997.</ref>

== Unterschiede zur Von-Neumann-Architektur ==
Das Prinzip des Datenflusses wurde in den frühen 1970er Jahren von [[Jack Dennis]] und [[James Rumbaugh]] entwickelt. Der früheste Architekturentwurf von Dennis und [[David Misunas]] stammt von 1975<ref name="Nr2">Theo Ungerer: Datenflußrechner. Teubner-Verlag 1993</ref><ref>Dennis, Misunas ''A preliminary architecture for a basic data flow processor'', 2. Annual Symposium on Computer Architecture, Houston, Januar 1975</ref>, implementiert im Distributed Data Processor (DDP) von Texas Instruments 1979. Die erste Realisierung eines Datenflussrechners war der DDM 1 (Data Driven Machine 1) von [[Alan L. Davis]] und [[Robert S. Barton]] 1977 an der [[University of Utah]] in Zusammenarbeit mit [[Burroughs Corporation|Burroughs]].<ref>Edwin D. Reilly ''Milestones in Computer Science and Information Technology'', Greenwood Press 2003, Artikel Dataflow Machine</ref>

Ein Datenflussrechner kommt ohne zwei zentrale Merkmale der Von-Neumann-Architekturen aus: er bedarf keines [[Befehlszähler|Programmzählers]] und keines ''zentralen Speichers'', der fortlaufend aktualisiert wird und zu einem Flaschenhals beim Ausnutzen von Parallelität wurde<ref name="Nr1" />; im Gegensatz zur Von-Neumann-Architektur werden berechnete Ergebnisse, die Inputwerte für weitere Berechnungen sind, nicht zwischengespeichert, sondern existieren lediglich als temporäre „Nachrichten“ zwischen den Ausführungseinheiten.

Alle [[Mikroprozessor]]en, die nach dem gängigen Von-Neumann-Prinzip arbeiten, folgen einem streng sequenziellen Verarbeitungsmodell. Die Befehlsabfolge folgt dem [[Von-Neumann-Zyklus]], das heißt, nach dem Laden der gegenwärtigen Instruktion wird implizit die Adresse der nachfolgenden Instruktion angesteuert, diese wird geladen und ausgeführt. Das Laden des entsprechenden Befehls erfolgt unter der Kontrolle eines Programmzählers, was das reihenfolgeerhaltende Laden der einzelnen Maschinenbefehle impliziert.

Zwar zielt auch das [[Dynamisches Scheduling|dynamische Scheduling]] [[Superskalarität|superskalarer]] Prozessoren, welches alle modernen Prozessoren der Von-Neumann-Rechner implementieren, auf das Ausführen der Maschinenbefehle in Datenflussreihenfolge ab. Dabei wird der sequenziell gelesene Befehlsstrom zeitweise während des Bearbeitens in der [[Pipeline (Prozessor)|Pipeline]] semantikerhaltend umgeordnet. Das Ergebnis der Bearbeitung des Befehlsstromes muss letztendlich jedoch dem sequenziellen Abarbeiten des Befehlsstroms äquivalent sein.

Die Maschineninstruktionen werden beim Von-Neumann-Prinzip stets reihenfolgeerhaltend geladen und das Speichern der Ergebnisse in den [[Register (Prozessor)|Registern]] nach Beendigung des jeweiligen Befehls muss reihenfolgeerhaltend vorgenommen werden; so kann beispielsweise das Ergebnis des auf eine [[Sprunganweisung]] folgenden Befehls erst gespeichert werden, wenn die Sprungbedingung ausgewertet wurde und klar ist, ob der entsprechende Befehl überhaupt hätte ausgeführt werden sollen; die Berechnung des besagten Ergebnisses kann dagegen durchaus vor dem Auswerten der Sprungbedingung erfolgen. Das Von-Neumann-Prinzip erfordert also die Abarbeitung der Maschineninstruktionen unter Berücksichtigung von [[Kontrollfluss]]abhängigkeiten.

Die Abarbeitung des Programms eines Datenflussrechners wird von [[Datenabhängigkeit]]en bestimmt; das heißt, der Kontrollfluss ist hier mit dem Datenfluss der einzelnen Instruktionen identisch. Das bedeutet, jede Maschineninstruktion kann geladen, ausgeführt und das Ergebnis der Berechnung gespeichert werden, sobald ihre [[Speicherprogrammierbare Steuerung#Operanden|Operanden]] vorliegen; das zugrunde liegende Modell ist damit [[Inhärenz|inhärent]] asynchron. Das Konzept bringt es mit sich, dass es einige Herausforderungen der Von-Neumann-Architektur, wie die [[Sprungvorhersage]] – bei den verarbeiteten Datenflussgraphen gibt es keine Sprünge – und das reihenfolgeerhaltende Ausführen von Lade- und Speicherbefehle des abzuarbeitenden Programmes hier nicht gibt.

[[Compiler]] im Von-Neumann-Kontext analysieren ihren [[Quelltext|Quellcode]] in Bezug auf Datenabhängigkeiten, um die Instruktionen im erzeugten [[Bytecode]] in sequenzieller Reihenfolge richtig anordnen zu können. Welche Datenabhängigkeiten der Compiler konkret ermittelt hat, wird im Bytecode jedoch nicht vermerkt. Ein Datenflusscompiler hingegen vermerkt in dessen Binärcode ermittelte Datenabhängigkeiten. Jede Abhängigkeit wird zur Unterscheidung von den übrigen mit einer eindeutigen Markierung versehen, dies ermöglicht der ausführenden Datenflussmaschine das nebenläufige Abarbeiten unterschiedlich markierter Code-Segmente.

== Datenflussrechner ==
=== Grundlagen ===
==== Datenflusssprachen ====
Zum Schreiben der abzuarbeitenden Programme für einen Datenflussrechner bedarf es einer Programmiersprache, deren kompiliertes Maschinenprogramm zu seiner Abarbeitung nicht eines [[Befehlszähler|Programmzählers]] bedarf und mit der man sehr einfach [[Nebenläufigkeit|nebenläufige]] Vorgänge beschreiben kann.

Einige Beispiele für solche Sprachen sind:
* Id (Irvine data flow language)
* Lucid
* [[Lustre (Programmiersprache)|Lustre]]
* SISAL

Datenfluss-Programmiersprachen sind [[Deklarative Programmierung|deklarativ]]; sie sind mit [[Funktionale Programmierung|funktionalen Programmiersprachen]] verwandt, ihre Programme sind nichts anderes als Funktionen, die Eingabewerte auf Ausgabewerte abbilden. Beide befolgen das sogenannte ''Einmalzuweisungsprinzip'': Einer Variablen kann nicht in der gleichen Funktion mehrmals nacheinander ein Wert zugewiesen werden, was der eigentlichen mathematischen Bedeutung einer Variablen gerecht wird.

==== Datenflussgraphen ====
Programme, die in einer Datenfluss-Programmiersprache geschrieben sind, können mithilfe eines sogenannten Datenflussgraphen modelliert bzw. mithilfe eines [[Compiler]]s in Maschineninstruktionen übersetzt werden, die einen solchen beschreiben. Datenflussgraphen beschreiben in der Regel nebenläufige Prozesse, die von einem Datenflussrechner [[Multithreading|mehrfädig]] berechnet werden können.

Ein Datenflussgraph ist ein [[gerichteter Graph]], dessen Knoten Instruktionen darstellen; die Kanten zwischen den Knoten beschreiben die zugrunde liegenden Datenabhängigkeiten; Inputwerte für die Instruktionen werden in Form von Datenpaketen, genannt Tokens, auf den Kanten entlang propagiert. Zwei zentrale Charakteristika eines Datenflussgraphen sind ''Funktionalität'', das heißt, die Auswertung des Graphen ist dem Auswerten einer mathematischen Funktion äquivalent, und die ''Kompositionseigenschaft'', das heißt Graphen können beliebig kombiniert werden und damit einen neuen Graphen bilden.

Die Abarbeitung des Datenflussgraphen wird vermöge der gerichteten Kanten von [[Datenabhängigkeit]]en kontrolliert. Wenn genügend Tokens auf den Eingangskanten eines Knotens vorhanden sind, kann dieser ''feuern'', das heißt, einige der Tokens auf den Eingangskanten werden konsumiert und neue Tokens auf den Ausgangskanten produziert, was es nachfolgenden Knoten ermöglichen kann, zu feuern.
[[Datei:Datenflussgraph.jpg|mini|Einfacher Datenflussgraph]]
Der Datenflussgraph zur Rechten entspricht dem Programm:
<pre style="overflow:auto;">
Input: u, v, w;

x = u - (v + w);
y = u * (v + w);

Output: x, y;
</pre>

Dies ist kein sequenzielles Programm. Beim Abarbeiten des Graphen wandern die mit Werten markierten Tokens durch den Graphen; die Funktion des Knotens DUP ist es, das Token auf der Eingangskante auf beide Ausgangskanten zu duplizieren. Zu Beginn könnten die Knoten ADD und DUP feuern, entweder ein Knoten nach dem anderen oder beide gleichzeitig; das Feuern geht hier in Form einer asynchronen [[Nebenläufigkeit]] vonstatten. Wenn beide Knoten gefeuert haben, sind ihre beiden Nachfolgeknoten MUL und SUB imstande, zu feuern. Die Ausführungsreihenfolge beeinflusst eventuell die Laufzeit beim Abarbeiten, hat aber keinen Einfluss auf das Ergebnis. Die Abarbeitung des Programms ist also [[Determinismus (Algorithmus)|deterministisch]].

Konzeptuell verschiedene Datenflussgraphen sind denkbar. Solche Graphen unterscheiden sich in ihrem Verhalten und ihrer Ausdrucksmächtigkeit. Im Folgenden sind einige architektonische Variationen der Datenflussrechner geführt, die den zeitlichen Ablauf ihrer Entwicklung widerspiegelt und denen zum Teil verschiedene Typen eines Datenflussgraphen zugrunde liegen.

=== Statische Datenflussrechner ===
Die Architektur, die Graphen mit einem Knoten pro Kante verarbeitet, eine ''statische'' Architektur, wurde im Wesentlichen von [[Jack Dennis]] entwickelt. Hauptvorteil dieses Modells ist die Tatsache, dass es recht einfach ist, Knoten zu ermitteln, die imstande sind, zu feuern. Ein unerwünschter Effekt dieses Modells besteht darin, dass aufeinanderfolgende Iterationen einer Schleife nur teilweise überlappen können und der Grad der Nebenläufigkeit, der erreicht werden kann, auf diese Weise gemindert wird. Ein weiterer Nachteil des Modells ist das Fehlen von unterstützenden Programmierkonstrukten bei modernen Programmiersprachen.<ref name="Nr1" /> Dennoch wurden einige Rechner dieser Architektur gebaut, die die Grundlage für nachfolgende Generationen von Datenflussrechnern bildeten; im Folgenden sind einige Beispiele gelistet:
* ''MIT Static Dataflow Architecture'' ([[Massachusetts Institute of Technology]])
* ''NEC Image Pipelined Processor'' ([[NEC Electronics]])
* ''Hughes Dataflow Multiprocessor'' ([[Hughes Aircraft]])

=== Dynamische Datenflussrechner ===
Die Leistung eines Datenflussrechners kann bedeutend gesteigert werden, wenn Schleifendurchläufe und Unterprogrammaufrufe parallel verarbeitet werden können. Um dies zu erreichen, sollte jeder Schleifendurchlauf und jeder Unterprogrammaufruf imstande sein, eine separate [[Eintrittsinvarianz|eintrittsinvariante]] Instanz des korrespondierenden Teilgraphen auszuführen. Da diese Replikation eines solchen Teilgraphen in der Praxis sehr aufwändig ist, wird tatsächlich nur eine Instanz des Graphen im Speicher gehalten; deshalb muss jedes Token mit einem ''Tag'' versehen werden, der den [[Prozesskontext]] identifiziert. Die Regel zum Feuern wird für die Knoten dahingehend geändert, dass der Knoten genau dann feuert, wenn hinreichend viele Tokens mit identischen Tags auf den Inputkanten verfügbar sind. Datenfluss-Architekturen, die diese Methode implementieren, heißen auch ''dynamische'' Datenfluss-Architekturen. Die ersten Experimente mit dem dynamischen Datenflussprinzip wurden Ende der 1970er unternommen.<ref name="Nr2" />

Der Vorteil dieser Architektur ist eine gesteigerte [[Rechenleistung|Performance]] aufgrund dessen, dass nun mehrere Tokens auf den Kanten propagiert werden können. Ein Problem dieser Architektur ist das effiziente Synchronisieren zweier Operationen. Dies wirft das sogenannte ''Token-Matching-Problem'' auf, bei dem es festzustellen gilt, ob zwei Token dasselbe Tag tragen, also zum selben [[Prozesskontext]] gehören. Diese Vergleichsoperation erfordert einen assoziativen Speicherzugriff. Da [[Assoziativspeicher]] sehr teuer waren, wurde in der Regel ein in Hardware implementiertes [[Hashfunktion|Hash-Verfahren]] angewandt, das sich in vielerlei Hinsicht als ineffektiv erwies.<ref name="Nr2" /> Im Folgenden sind einige Beispiele für Implementierungen dieser Architektur gelistet:
* ''Manchester Dataflow Computer'' ([[University of Manchester]])
* ''MIT Tagged-Token Dataflow Machine'' ([[Massachusetts Institute of Technology]])
* ''PATTSY – Processor Array Tagged-Token System'' ([[University of Queensland]])

=== Dynamische Datenflussrechner mit explizitem Token-Speicher ===
Um das Token-Matching-Problem zu lösen und keines teuren assoziativen Speichers zu bedürfen, wurde das Konzept des ''expliziten Token-Speichers'' entwickelt. Grundidee dabei ist es, bei einer Schleifeniteration dynamisch einen so genannten „Aktivierungsrahmen“ im Token-Speicher bereitzustellen, der eine Speicherstelle für dasjenige Token bietet, welches zuerst bei der Vergleichseinheit ankommt. Die Adresse der Speicherstelle kann durch den Compiler errechnet werden. Trifft das zweite Token bei der Vergleichseinheit ein, wird das erste Token wieder aus dem Speicher gelesen und der Vergleich vorgenommen, so dass bei dieser Technik nur zwei Speicherzugriffe notwendig sind, anstatt einen Teil des Tokenspeicher nach einem passenden Token durchsuchen zu müssen, wie zuvor. Allerdings wird die Anzahl der gleichzeitig ausführbaren Schleifen- und Unterprogramminstanzen durch dieses Vorgehen beschränkt.<ref name="Nr1" /> Experimente mit dieser Architektur wurden Ende der 1980er unternommen<ref name="Nr2" />; ein Beispiel für eine Implementierung ist:
* ''Monsoon'' ([[Massachusetts Institute of Technology]] in Zusammenarbeit mit [[Motorola, Inc.]])

=== Vor- und Nachteile von Datenflussrechnern ===
'''Vorteile'''
* Ein Datenflussrechner kann viele Threads auf einem oder mehreren Prozessoren ausführen; seine [[Rechenleistung|Performance]] steigt dabei beinahe linear mit der Anzahl seiner Prozessoren
* Programmierer müssen sich weniger um explizite [[Nebenläufigkeit]] beim Programmieren kümmern; Datenflussrechner nutzen ''implizite Nebenläufigkeit'' aus, die zur Übersetzungszeit vom [[Compiler]] entdeckt wird
* Lange Zeit waren Datenflussrechner solchen der [[Von-Neumann-Architektur]] in puncto Speicherlatenz und Synchronisation überlegen

'''Nachteile'''
* Kein Nutzen von [[Register (Prozessor)|Registern]] – stattdessen ''Result-Forwarding'': Weil die zeitliche Abfolge, in der die einzelnen Befehle des Datenflussprogramms ausgeführt werden, nicht im Voraus festgelegt ist, können Register als Zwischenspeicher für Operanden nicht genutzt werden.
* Schlechtes Ausnutzen von [[Cache]]s: Die in der Von-Neumann-Architektur genutzte [[Lokalitätseigenschaft|Referenzlokalität]] beim Zugriff auf Daten- und Instruktionscaches, die aufgrund des sequenziellen Verarbeitungsmodells sehr stark ausgeprägt ist, ist in der Datenfluss-Architektur kaum vorhanden, bestimmt aber maßgeblich die Leistungsfähigkeit eines Caches. Highspeed-Prozessoren benötigen Caches, um ihre Ausführungseinheiten auslasten zu können.
* Leistungseinbußen aufgrund von Duplikationsoperationen
* Schlechte Performance beim Verarbeiten eines einzelnen [[Thread (Informatik)|Threads]]: Beim Verarbeiten eines einzelnen Threads müssen Operationstupel warten, bis die Vorgängeroperation beendet wurde. Ein Datenflussrechner hat seine Stärke beim Ausführen vieler Threads, um mit vielen unabhängigen Operationen seine Pipelines füllen und auslasten zu können
* Relativ breite Maschineninstruktionen: Die Breite der Maschineninstruktionen des ''Monsoon-Datenflussrechners'' betrug beispielsweise 144 Bit
* [[Overhead (EDV)|Overhead]] aufgrund des Token-Matching-Problems

=== Motivation für Multithreading ===
Datenflussrechner haben eine schlechte [[Rechenleistung|Performance]], wenn sie einen einzelnen sequenziellen [[Thread (Informatik)|Thread]] ausführen. Die jeweiligen Ergebnisse eines [[Tupel (Informatik)|Operationstupels]] werden in der letzten Stufe der [[Pipeline (Prozessor)|Pipeline]] berechnet und [[Pipeline-Hazard|Datenkonflikte]] würden dazu führen, dass nur jeweils eine Instruktion in der Pipeline verarbeitet wird, so dass die Pipeline offensichtlich keinen Nutzen bringt. Datenflussprogramme bestehen jedoch im Allgemeinen aus vielen [[Nebenläufigkeit|nebenläufigen]] Threads, so dass es möglich ist, die Pipeline fortlaufend mit datenunabhängigen Instruktionen zu füllen, die zu verschiedenen [[Prozesskontext]]en gehören, so dass keine Pipelinekonflikte entstehen und die Pipeline voll ausgelastet werden kann. Insbesondere ist es so auch möglich, lange [[Latenzzeit (Technik)|Latenzzeiten]] zu überbrücken, die beispielsweise Lade- und Speicheroperationen verursachen; in der Zwischenzeit werden einfach datenunabhängige Instruktionen anderer Threads in die Pipeline gespeist. Dem [[Multithreading]] heutiger Prozessoren, oder [[Hyper-Threading]] bei [[Intel]]s Pentium, liegt dasselbe Prinzip zugrunde.

== Hybride Architekturen ==
Datenflussrechner wurden vor allem in den 1980er Jahren gebaut, erwiesen sich aber mit Von-Neumann-[[Supercomputer]]n aufgrund des Engpasses beim Speicherzugriff als nicht wettbewerbsfähig. Die Nachteile, welche die Datenfluss-Architektur mit sich bringt, führten zur Entwicklung hybrider Architekturen, welche die Vorteile sowohl der Datenfluss-Architektur als auch der Von-Neumann-Architektur nutzen. Beide Architekturen dürfen aber nicht als [[Orthogonalität|orthogonale]] Rechner-[[Paradigma|Paradigmen]] gesehen werden.<ref name="Nr1" /> Das Spektrum solcher Hybride ist relativ breit; es reicht von einer einfachen Erweiterung des Von-Neumann-Prozessors mit einigen wenigen zusätzlichen Instruktionen bis zu spezialisierten Datenflusssystemen, die sich einer Vielzahl von Techniken bedienen, die für Von-Neumann-Rechner entwickelt wurden.

Einige wichtige Konzepte von Datenflussrechnern „überlebten“ aufgrund dieser „Konvergenz“ und sind in den allermeisten heutigen Prozessoren zu finden, so das dem ''Datenflussprinzip'' entsprechende nicht-reihefolgeerhaltende Ausführen der Maschinenbefehle beim dynamischen Scheduling superskalarer Prozessoren und das [[Multithreading]].

== Siehe auch ==
* [[Datenfluss]]
* [[Datenflussdiagramm]]
* [[Parallelrechner]]
* [[Analogrechner]]
* [[Digital Differential Analyzer|Digital differential analyzer]]

== Literatur ==
* Arvind und R. Nikhil: ''Executing a program on the MIT tagged-token dataflow architecture.'' In: ''IEEE Transaction on computers.'' 1990 ([https://pages.cs.wisc.edu/~isca2005/ttda.pdf cs.wisc.edu] PDF; 1,91 MB).
* G. Papadopoulos, D. Culler: ''Monsoon: an explicit token-store architecture.'' In: ''International Symposium on Computer Architecture (ISCA).'' 1990 (Beschreibt die Architektur des Monsoon-Datenflussrechners).
* J. Silic, B. Robic, T. Ungerer: ''Asynchrony in parallel computing: From data flow to multithreading.'' In: ''Technical report CSD, Computer Systems Department.'' Josef Stefan Institute, Ljubljana, Slowenien, 1997 (Listet alle bedeutenden Datenflussrechner, beschreibt deren historische Entwicklung und erklärt, warum heutige multithreadingfähige Prozessoren Abkömmlinge der Datenflussrechner sind).
* [[James Rumbaugh]]: ''A Parallel Asynchronous Computer Architecture For Data Flow Programs.'' MIT-LCS-TR-150, 1975 (Dissertation).

== Einzelnachweise ==
<references />

[[Kategorie:Rechnerarchitektur]]
[[Kategorie:Parallelverarbeitung]]

Datenfluss-Architektur - Versionsgeschichte

imported>B.A.Enz: Änderung 265767670 von ~2026-77782-1 rückgängig gemacht; kein Tippfehler. Im Dativ mit Artikel schwache Deklination.