fence

fence

RISC-V Assembler Referenz

lyszt.net behandelt fence und andere RISC-V-Befehle ausführlicher.

Beschreibung

FENCE-Anweisungen werden verwendet, um Geräte-E/A und Speicherzugriffe so zu ordnen, wie sie von anderen RISC-V-Harts und externen Geräten oder Coprozessoren gesehen werden. Jede Kombination von Geräteeingabe (I), Geräteausgabe (O), Speicherlesevorgängen (R) und Speicherschreibvorgängen (W) kann in Bezug auf jede Kombination derselben geordnet werden. Informell kann kein anderer RISC-V-Hart oder kein externes Gerät eine Operation in der successor-Menge nach einem FENCE vor einer Operation in der predecessor-Menge vor dem FENCE beobachten. memorymodel liefert eine präzise Beschreibung des RISC-V-Speicherkonsistenzmodells.

FENCE-Anweisungen ordnen auch Speicherlese- und -schreibvorgänge, die vom Hart ausgeführt werden, so, wie sie durch Speicherlese- und -schreibvorgänge eines externen Geräts beobachtet werden. FENCE-Anweisungen ordnen jedoch keine Beobachtungen von Ereignissen durch ein externes Gerät unter Verwendung eines anderen Signalisierungsmechanismus.

ℹ
Ein Gerät könnte einen Zugriff auf eine Speicherstelle über einen externen Kommunikationsmechanismus beobachten, z. B. ein speicherzugeordnetes Steuerregister, das ein Unterbrechungssignal an einen Interrupt-Controller treibt. Diese Kommunikation liegt außerhalb des Geltungsbereichs des FENCE-Ordnungsmechanismus, und daher können FENCE-Anweisungen keine Garantie dafür bieten, wann eine Änderung des Unterbrechungssignals für den Interrupt-Controller sichtbar ist. Bestimmte Geräte können zusätzliche Ordnungsgarantien bieten, um den Software-Overhead zu reduzieren, aber diese liegen außerhalb des Geltungsbereichs des RISC-V-Speichermodells.

Die EEI definiert, welche E/A-Operationen möglich sind und insbesondere, welche Speicheradressen bei Zugriff durch Lade- und Speicheranweisungen als Geräteeingabe- bzw. Geräteausgabeoperationen behandelt und geordnet werden statt als Speicherlese- und -schreibvorgänge. Beispielsweise werden speicherzugeordnete E/A-Geräte typischerweise mit nicht zwischengespeicherten Lade- und Speichervorgängen angesprochen, die unter Verwendung der I- und O-Bits statt der R- und W-Bits geordnet werden. Befehlssatzerweiterungen können auch neue E/A-Anweisungen beschreiben, die ebenfalls unter Verwendung der I- und O-Bits in einer FENCE-Anweisung geordnet werden.

Fence-Modus-Kodierung

Das FENCE-Modusfeld fm definiert die Semantik der FENCE-Anweisung. Ein FENCE (mit fm=0000) ordnet alle Speicheroperationen in seiner Vorgängermenge vor allen Speicheroperationen in seiner Nachfolgermenge.

Eine FENCE.TSO-Anweisung wird als FENCE-Anweisung mit fm=1000, predecessor=RW und successor=RW kodiert. FENCE.TSO ordnet alle Ladeoperationen in seiner Vorgängermenge vor allen Speicheroperationen in seiner Nachfolgermenge und alle Speicheroperationen in seiner Vorgängermenge vor allen Speicheroperationen in seiner Nachfolgermenge. Dadurch bleiben non-AMO-Speicheroperationen in der Vorgängermenge von FENCE.TSO ungeordnet gegenüber non-AMO-Ladevorgängen in seiner Nachfolgermenge.

ℹ
Da FENCE RW,RW eine Obermenge der Ordnungen auferlegt, die FENCE.TSO auferlegt, ist es korrekt, das Feld fm zu ignorieren und FENCE.TSO als FENCE RW,RW zu implementieren.

Die ungenutzten Felder in den FENCE-Anweisungen--rs1 and rd--sind für feinere Fences in zukünftigen Erweiterungen reserviert. Aus Gründen der Vorwärtskompatibilität müssen Basisimplementierungen diese Felder# ignorieren, und Standardsoftware muss diese Felder auf null setzen. Ebenso sind viele Einstellungen für fm und Vorgänger-/Nachfolgermengen ebenfalls für zukünftige Verwendung reserviert. Basisimplementierungen müssen alle derartigen reservierten Konfigurationen als FENCE-Anweisungen (mit fm=0000) behandeln, und Standardsoftware darf nur nicht reservierte Konfigurationen verwenden.

ℹ
Wir haben ein entspanntes Speichermodell gewählt, um hohe Leistung aus einfachen Maschinenimplementierungen und aus wahrscheinlichen zukünftigen Coprozessor- oder Beschleunigererweiterungen zu ermöglichen. Wir trennen die E/A-Ordnung von der Speicher-R/W-Ordnung, um unnötige Serialisierung innerhalb eines Gerätetreiber-Harts zu vermeiden und auch alternative Nicht-Speicherpfade zur Steuerung hinzugefügter Coprozessoren oder E/A-Geräte zu unterstützen. Einfache Implementierungen können zusätzlich die Felder predecessor and successor ignorieren und immer ein konservatives FENCE auf allen Operationen ausführen.