RISC-V - RISC-V

RISC-V
RISC-V-logo.svg
Designer Universität von Kalifornien, Berkeley
Bits
Eingeführt 2010
Ausführung
Entwurf RISC
Typ Laden-Laden
Codierung Variable
Verzweigung Vergleichen und verzweigen
Endianität Wenig
Seitengröße 4 KiB
Erweiterungen
Offen Ja und lizenzfrei
Register
Allgemeiner Zweck (einschließlich eines Immer-Null-Registers)
Gleitkomma

RISC-V (ausgesprochen "Risiko-Fünf") ist eine offene Standard- Befehlssatzarchitektur (ISA), die auf etablierten Prinzipien des Computers mit reduziertem Befehlssatz (RISC) basiert . Im Gegensatz zu den meisten anderen ISA-Designs wird die RISC-V ISA unter Open-Source-Lizenzen bereitgestellt , für deren Nutzung keine Gebühren anfallen. Eine Reihe von Unternehmen bieten RISC-V-Hardware an oder haben dies angekündigt, Open-Source-Betriebssysteme mit RISC-V-Unterstützung sind verfügbar und der Befehlssatz wird in mehreren gängigen Software- Toolchains unterstützt .

Als RISC-Architektur ist die RISC-V ISA eine Load-Store-Architektur . Seine Gleitkommabefehle verwenden Gleitkomma nach IEEE 754 . Zu den bemerkenswerten Merkmalen des RISC-V ISA gehören Bitmuster zur Vereinfachung der Multiplexer in einer CPU, ein architekturneutrales Design und die wichtigsten Bits von unmittelbaren Werten, die an einer festen Stelle platziert werden, um die Vorzeichenerweiterung zu beschleunigen . Der Befehlssatz ist für eine Vielzahl von Anwendungen konzipiert. Der Basisbefehlssatz hat eine feste Länge von natürlich ausgerichteten 32-Bit- Befehlen, und die ISA unterstützt Erweiterungen mit variabler Länge, wobei jeder Befehl eine beliebige Anzahl von 16-Bit- Paketen in der Länge haben könnte. Teilmengen unterstützen kleine eingebettete Systeme , Personalcomputer , Supercomputer mit Vektorprozessoren und 19-Zoll-Rack- montierte Parallelcomputer im Lagermaßstab .

Die Befehlssatzspezifikation definiert 32-Bit- und 64-Bit- Adressraumvarianten . Die Spezifikation enthält eine Beschreibung einer 128-Bit- Flat-Adressraum-Variante, als Extrapolation von 32- und 64-Bit-Varianten, aber die 128-Bit-ISA bleibt bewusst "nicht eingefroren", weil es noch so wenig praktische Erfahrungen mit so großem Speicher gibt Systeme.

Das Projekt begann 2010 an der University of California, Berkeley , aber jetzt sind viele der aktuellen Mitwirkenden Freiwillige, die nicht mit der Universität verbunden sind. Im Gegensatz zu anderen akademischen Designs, die typischerweise nur für eine einfache Darstellung optimiert sind, beabsichtigten die Designer, dass der RISC-V-Befehlssatz für praktische Computer verwendbar ist.

Ab Juni 2019 werden Version 2.2 der User-Space-ISA und Version 1.11 der privilegierten ISA eingefroren , sodass die Software- und Hardwareentwicklung fortgesetzt werden kann. Die User-Space-ISA, jetzt in Unprivileged ISA umbenannt, wurde als Version 20191213 aktualisiert, ratifiziert und eingefroren. Eine Debug-Spezifikation liegt als Entwurf, Version 0.13.2, vor.

Begründung

Prototyp des RISC-V-Prozessors, Januar 2013

CPU-Design erfordert Design-Know-how in mehreren Fachgebieten: elektronische digitale Logik , Compiler und Betriebssysteme . Zur Deckung der Kosten für ein solches Team, kommerzielle Anbieter von Computer - Designs, wie Arm Ltd. und MIPS Technologies , Ladungslizenzgebühren für die Nutzung ihrer Designs, Patente und Urheberrechte . Sie verlangen auch oft Geheimhaltungsvereinbarungen, bevor sie Dokumente veröffentlichen, die die detaillierten Vorteile ihrer Designs beschreiben. In vielen Fällen beschreiben sie nie die Gründe für ihre Designentscheidungen.

RISC-V wurde mit dem Ziel ins Leben gerufen, eine praktische ISA zu entwickeln, die Open Source ist, akademisch nutzbar und in jedem Hardware- oder Softwaredesign ohne Lizenzgebühren einsetzbar ist. Außerdem werden die Begründungen für jede Entwurfsentscheidung des Projekts, zumindest in groben Zügen, erläutert. Die RISC-V-Autoren sind Akademiker mit umfangreicher Erfahrung im Computerdesign, und der RISC-V ISA ist eine direkte Entwicklung aus einer Reihe akademischer Computerdesign-Projekte. Es wurde zum Teil ins Leben gerufen, um solche Projekte zu unterstützen.

Um eine große, kontinuierliche Benutzergemeinschaft aufzubauen und damit Designs und Software zu sammeln, unterstützen die RISC-V ISA-Designer absichtlich eine Vielzahl praktischer Anwendungsfälle: kompakte, leistungsstarke und energiesparende Real-World-Implementierungen ohne übermäßige Architektur für eine bestimmte Mikroarchitektur . Die Anforderungen einer großen Basis von Mitwirkenden sind einer der Gründe, warum RISC-V für viele mögliche Anwendungen entwickelt wurde.

Die Hauptaussage der Designer ist, dass der Befehlssatz die Schlüsselschnittstelle in einem Computer ist, da er sich an der Schnittstelle zwischen der Hardware und der Software befindet. Wenn ein guter Befehlssatz offen und für alle verfügbar wäre, kann er die Softwarekosten drastisch senken, indem er weit mehr Wiederverwendung ermöglicht. Es sollte auch einen verstärkten Wettbewerb zwischen Hardwareanbietern auslösen, die dann mehr Ressourcen für das Design und weniger für den Softwaresupport aufwenden können.

Die Designer behaupten, dass neue Prinzipien im Instruction Set Design selten werden, da sich die erfolgreichsten Designs der letzten vierzig Jahre immer ähnlicher geworden sind. Von denen, die scheiterten, taten dies die meisten, weil ihre Sponsorunternehmen finanziell nicht erfolgreich waren, nicht weil die Instruktionssätze technisch schlecht waren. Daher sollte ein gut gestalteter offener Befehlssatz, der nach bewährten Prinzipien entwickelt wurde, von vielen Anbietern langfristig unterstützt werden.

RISC-V fördert auch die akademische Nutzung. Die Einfachheit der ganzzahligen Teilmenge ermöglicht grundlegende Schülerübungen und ist eine einfache ISA, um Software zur Steuerung von Forschungsmaschinen zu ermöglichen. Die ISA mit variabler Länge bietet Erweiterungen sowohl für Schülerübungen als auch für Forschung, und der getrennte privilegierte Befehlssatz ermöglicht die Forschung in der Betriebssystemunterstützung, ohne Compiler neu zu entwerfen. Das offene Paradigma des geistigen Eigentums von RISC-V ermöglicht die Veröffentlichung, Wiederverwendung und Modifikation von abgeleiteten Designs.

Geschichte

Der Begriff RISC stammt aus der Zeit um 1980. Zuvor gab es einige Erkenntnisse, dass einfachere Computer effektiv sein könnten (zB John Cocke bei IBM Research ), aber die Designprinzipien wurden nicht umfassend beschrieben. Einfache, effektive Computer waren schon immer von akademischem Interesse und führten 1990 zum RISC-Befehlssatz DLX für die erste Ausgabe von Computer Architecture: A Quantitative Approach, dessen Co-Autor David Patterson war und der er später am RISC- V Ursprung. DLX war für Bildungszwecke vorgesehen; Akademiker und Hobbyisten implementierten es mit feldprogrammierbaren Gate-Arrays , aber es war nie wirklich für den kommerziellen Einsatz gedacht. ARM- CPUs, Version 2 und früher, hatten einen gemeinfreien Befehlssatz und werden immer noch von der GNU Compiler Collection (GCC), einem beliebten Compiler für freie Software, unterstützt . Für diese ISA existieren drei Open-Source- Kerne , die jedoch nie hergestellt wurden. OpenRISC ist eine auf DLX basierende Open-Source-ISA mit zugehörigen RISC-Designs und wird vollständig von GCC- und Linux- Implementierungen unterstützt, obwohl es auch nur wenige kommerzielle Implementierungen gibt.

Krste Asanović von der University of California, Berkeley, hatte einen Forschungsbedarf für ein Open-Source-Computersystem, und im Jahr 2010 beschloss er, eines in einem "kurzen, dreimonatigen Projekt über den Sommer" mit mehreren seiner Mitarbeiter zu entwickeln und zu veröffentlichen Absolventen. Der Plan war, sowohl akademischen als auch industriellen Nutzern zu helfen. David Patterson aus Berkeley schloss sich der Zusammenarbeit an, da er der Begründer des Berkeley RISC war , und das RISC-V ist die namensgebende fünfte Generation seiner langen Reihe kooperativer RISC-basierter Forschungsprojekte. In dieser Phase lieferten die Studenten erste Software, Simulationen und CPU-Designs.

Erster Raven1 bringt ST28nm im Berkeley Wireless Research Center (BWRC) im Juni 2012 auf

Die RISC-V-Autoren und ihre Institution haben die ISA-Dokumente und mehrere CPU-Designs ursprünglich unter BSD-Lizenzen bezogen , die es ermöglichen, abgeleitete Werke – wie RISC-V-Chipdesigns – entweder offen und frei oder geschlossen und proprietär zu sein. Die ISA-Spezifikation selbst (dh die Kodierung des Befehlssatzes) wurde 2011 als Open Source mit allen vorbehaltenen Rechten veröffentlicht. Der eigentliche technische Bericht (ein Ausdruck der Spezifikation) wurde später unter eine Creative Commons-Lizenz gestellt, um eine Verbesserung durch externe Mitwirkende durch die RISC-V Foundation und später RISC-V International zu ermöglichen.

Eine vollständige Geschichte von RISC-V wurde auf der Website von RISC-V International veröffentlicht.

RISC-V Foundation und RISC-V International

Kommerzielle Benutzer benötigen einen stabilen ISA, bevor sie ihn in einem Produkt verwenden können, das viele Jahre halten kann. Um dieses Problem anzugehen, wurde die RISC-V Foundation gegründet, um geistiges Eigentum im Zusammenhang mit der RISC-V-Definition zu besitzen, zu pflegen und zu veröffentlichen. Die ursprünglichen Urheber und Eigentümer haben ihre Rechte an die Stiftung abgegeben. Geleitet wird die Stiftung von CEO Calista Redmond , die diese Funktion im Jahr 2019 übernahm, nachdem sie offene Infrastrukturprojekte bei IBM geleitet hatte .

Im November 2019 kündigte die RISC-V Foundation ihren Umzug in die Schweiz an , da sie Bedenken hinsichtlich der US-Handelsvorschriften hatte. Seit März 2020 trägt die Organisation den Namen RISC-V International, ein Schweizer gemeinnütziger Wirtschaftsverband.

Ab 2019 veröffentlicht RISC-V International die Dokumente, die RISC-V definieren, frei und erlaubt die uneingeschränkte Nutzung der ISA für das Design von Soft- und Hardware. Allerdings können nur Mitglieder von RISC-V International abstimmen, um Änderungen zu genehmigen, und nur Mitgliedsorganisationen verwenden das markenrechtlich geschützte Kompatibilitätslogo.

Auszeichnungen

  • 2017: Analyst's Choice Award der Linley Group für die beste Technologie (für den Instruktionssatz)

Entwurf

ISA-Basis und Erweiterungen

RISC-V ist modular aufgebaut und besteht aus alternativen Basisteilen mit zusätzlichen optionalen Erweiterungen. Die ISA-Basis und ihre Erweiterungen werden in einer gemeinsamen Anstrengung von Industrie, Forschungsgemeinschaft und Bildungseinrichtungen entwickelt. Die Basis spezifiziert Befehle (und ihre Codierung), Kontrollfluss, Register (und ihre Größen), Speicher und Adressierung, logische (dh ganzzahlige) Manipulation und Hilfsfunktionen. Die Basis allein kann einen vereinfachten Allzweckcomputer mit vollständiger Softwareunterstützung einschließlich eines Allzweckcompilers implementieren.

Die Standarderweiterungen sind so spezifiziert, dass sie mit allen Standardbasen und miteinander ohne Konflikte funktionieren.

Viele RISC-V-Computer implementieren möglicherweise die kompakte Erweiterung, um den Stromverbrauch, die Codegröße und die Speichernutzung zu reduzieren. Es gibt auch Pläne für die Zukunft, Hypervisoren und Virtualisierung zu unterstützen .

Zusammen mit einer Supervisor-Befehlssatzerweiterung S definiert ein RVGC alle Befehle, die zur bequemen Unterstützung eines Universalbetriebssystems erforderlich sind .

ISA-Basis und Erweiterungen
Name Beschreibung Ausführung Status Anweisungsanzahl
Base
RVWMO Schwache Speicherordnung 2.0 Ratifiziert
RV32I Basis-Integer-Befehlssatz, 32-Bit 2.1 Ratifiziert 40
RV32E Base Integer Instruction Set (eingebettet), 32-Bit, 16 Register 1,9 Offen 40
RV64I Basis-Integer-Befehlssatz, 64-Bit 2.1 Ratifiziert fünfzehn
RV128I Basis-Integer-Befehlssatz, 128-Bit 1.7 Offen fünfzehn
Verlängerung
m Standarderweiterung für Integer Multiplikation und Division 2.0 Ratifiziert 8 (RV32) / 13 (RV64)
EIN Standarderweiterung für atomare Anweisungen 2.1 Ratifiziert 11 (RV32) / 22 (RV64)
F Standarderweiterung für Gleitkommazahlen mit einfacher Genauigkeit 2.2 Ratifiziert 26 (RV32) / 30 (RV64)
D Standarderweiterung für Gleitkommazahlen mit doppelter Genauigkeit 2.2 Ratifiziert 26 (RV32) / 32 (RV64)
Zicsr Kontroll- und Statusregister (CSR) 2.0 Ratifiziert 6
Zifencei Anleitung-Fetch Fence 2.0 Ratifiziert 1
g Abkürzung für die IMAFDZicsr Zifencei-Basis und -Erweiterungen, die eine Standard-Allzweck-ISA darstellen sollen N / A N / A
Q Standarderweiterung für Quad-Precision Floating-Point 2.2 Ratifiziert 28 (RV32) / 32 (RV64)
L Standarderweiterung für Dezimal-Gleitkomma 0.0 Offen
C Standarderweiterung für komprimierte Anweisungen 2.0 Ratifiziert 40
B Standarderweiterung für Bitmanipulation 1.0 Gefroren 42
J Standarderweiterung für dynamisch übersetzte Sprachen 0.0 Offen
T Standarderweiterung für Transaktionsspeicher 0.0 Offen
P Standarderweiterung für gepackte SIMD-Anweisungen 0,2 Offen
V Standarderweiterung für Vektoroperationen 1.0 Gefroren 186
K Standarderweiterung für skalare Kryptographie 1.0.0-rc4 Gefroren
n Standarderweiterung für Interrupts auf Benutzerebene 1.1 Offen 3
h Standarderweiterung für Hypervisor 1.0.0-rc Gefroren fünfzehn
S Standarderweiterung für Anweisungen auf Supervisor-Ebene 1,12 Gefroren 7
Zam Falsch ausgerichtete Atome 0,1 Offen
Ztso Gesamtzahl der Bestellungen im Geschäft 0,1 Gefroren
32-Bit-RISC-V-Befehlsformate
Format Bit
31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 fünfzehn 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Registrieren/Registrieren funt7 rs2 rs1 funt3 rd Opcode
Sofort imm[11:0] rs1 funt3 rd Opcode
Obere unmittelbare imm[31:12] rd Opcode
Geschäft imm[11:5] rs2 rs1 funt3 imm[4:0] Opcode
Zweig [12] imm[10:5] rs2 rs1 funt3 imm[4:1] [11] Opcode
Springen [20] imm[10:1] [11] imm[19:12] rd Opcode
  • opcode (7 Bits): Gibt teilweise an, welche der 6 Arten von Befehlsformaten .
  • funct7 und funct3 (10 Bit): Diese beiden Felder spezifizieren neben dem Opcode- Feld die auszuführende Operation.
  • rs1 , rs2 oder rd (5 Bits): Gibt per Index das Register an, das den ersten Operanden (dh das Quellregister), den zweiten Operanden und das Zielregister enthält, an die das Berechnungsergebnis geleitet wird.

Um die Kombinationen von Funktionalitäten, die implementiert werden können, zu bändigen, wird eine Nomenklatur definiert, um sie in Kapitel 27 der aktuellen ratifizierten Unprivileged ISA Specification zu spezifizieren. Zuerst wird die Befehlssatzbasis spezifiziert, die Codierung für RISC-V, die Registerbitbreite und die Variante; zB RV64I oder RV32E. Dann folgen Buchstaben, die implementierte Erweiterungen in der Reihenfolge der obigen Tabelle angeben. Auf jeden Buchstaben kann ein Major folgen, optional gefolgt von "p" und einer Minor-Optionsnummer. Wenn die Nebenversionsnummer weggelassen wird, wird standardmäßig 0 verwendet, und wenn die Versionsnummer vollständig weggelassen wird, wird standardmäßig 1.0 verwendet. Somit kann RV64IMAFD als RV64I1p0M1p0A1p0F1p0D1p0 oder einfacher als RV64I1M1A1F1D1 geschrieben werden. Zwischen Erweiterungen können zur besseren Lesbarkeit Unterstriche verwendet werden, zum Beispiel RV32I2_M2_A2.

Die Basis-, erweiterte Ganzzahl- und Gleitkomma-Berechnungen und Synchronisationsprimitive für Multi-Core-Computing, die Basis- und Erweiterungs-MAFD, werden für allgemeine Berechnungen als notwendig erachtet und haben daher die Abkürzung G.

Ein kleiner 32-Bit-Computer für ein eingebettetes System könnte RV32EC sein. Ein großer 64-Bit-Computer könnte RV64GC sein; dh Abkürzung für RV64IMAFDZicsrZifenceiC.

Mit der Zunahme der Anzahl von Erweiterungen sieht der Standard nun vor, dass Erweiterungen mit einem einzelnen "Z" benannt werden, gefolgt von einem alphabetischen Namen und einer optionalen Versionsnummer. Zifencei benennt beispielsweise die Instruktions-Fetch-Erweiterung. Zifencei2 und Zifencei2p0 nennen Version 2.0 derselben. Der erste Buchstabe nach dem "Z" weist laut Konvention auf die am engsten verwandte alphabetische Erweiterungskategorie IMAFDQLCBJTPVN hin. Somit bezieht sich die Zam-Erweiterung für falsch ausgerichtete Atome auf die "A"-Standarderweiterung. Im Gegensatz zu Einzelzeichenerweiterungen müssen Z-Erweiterungen durch Unterstriche getrennt, nach Kategorie und dann innerhalb jeder Kategorie alphabetisch gruppiert werden. Zum Beispiel Zicsr Zifencei Zam.

Für die Supervisor-Berechtigungsebene spezifische Erweiterungen werden auf die gleiche Weise mit "S" als Präfix benannt. Hypervisor-spezifische Erweiterungen werden mit "H" als Präfix benannt. Erweiterungen auf Maschinenebene werden mit den drei Buchstaben "Zxm" vorangestellt. Befehlssatzerweiterungen auf Supervisor-, Hypervisor- und Maschinenebene sind nach weniger privilegierten Erweiterungen benannt.

RISC-V-Entwickler können ihre eigenen nicht standardmäßigen Befehlssatzerweiterungen erstellen. Diese folgen der Namenskonvention "Z", jedoch mit "X" als Präfix. Sie sollten nach allen Standarderweiterungen angegeben werden, und wenn mehrere Nicht-Standarderweiterungen aufgeführt sind, sollten sie alphabetisch aufgelistet werden.

Registersätze


Name registrieren		 Symbolischer
Name		 Beschreibung Gespeichert von
32 Ganzzahl - Register
x0 Null Immer null
x1 ra Absender Anrufer
x2 sp Stapelzeiger Angerufener
x3 gp Globaler Zeiger
x4 tp Fadenzeiger
x5 t0 Temporäre / alternative Absenderadresse Anrufer
x6–7 t1–2 Vorübergehend Anrufer
x8 s0/fp Gespeicherter Register-/Rahmenzeiger Angerufener
x9 s1 Gespeichertes Register Angerufener
x10–11 a0–1 Funktionsargument / Rückgabewert Anrufer
x12–17 a2–7 Funktionsargument Anrufer
x18–27 s2–11 Gespeichertes Register Angerufener
x28–31 t3–6 Vorübergehend Anrufer
32 Gleitkomma- Erweiterungsregister
f0–7 ft0–7 Gleitkomma-Provisorien Anrufer
f8–9 fs0–1 Gleitkomma-gespeicherte Register Angerufener
f10–11 fa0–1 Gleitkomma-Argumente/Rückgabewerte Anrufer
f12–17 fa2–7 Gleitkomma-Argumente Anrufer
f18–27 fs2–11 Gleitkomma-gespeicherte Register Angerufener
f28–31 ft8–11 Gleitkomma-Provisorien Anrufer

RISC-V hat 32 (oder 16 in der eingebetteten Variante) Integer- Register und, wenn die Gleitkomma-Erweiterung implementiert ist, separate 32 Gleitkomma- Register. Mit Ausnahme von Speicherzugriffsbefehlen adressieren Befehle nur Register.

Das erste Ganzzahlregister ist ein Nullregister, und der Rest sind Mehrzweckregister. Ein Speichern im Nullregister hat keine Auswirkung, und ein Lesen liefert immer 0. Die Verwendung des Nullregisters als Platzhalter sorgt für einen einfacheren Befehlssatz.

move rx to rywird add r0 to rx and store in ry.

Steuer- und Statusregister sind vorhanden, aber Benutzermodusprogramme können nur auf diejenigen zugreifen, die für die Leistungsmessung und die Gleitkommaverwaltung verwendet werden.

Es gibt keine Anweisungen zum Sichern und Wiederherstellen mehrerer Register. Diese galten als unnötig, zu komplex und vielleicht zu langsam.

Speicherzugriff

Wie viele RISC-Designs ist RISC-V eine Lade-Speicher-Architektur : Befehle adressieren nur Register, wobei Lade- und Speicherbefehle zum und vom Speicher übertragen werden.

Die meisten Lade- und Speicherbefehle enthalten einen 12-Bit-Offset und zwei Registerkennungen. Ein Register ist das Basisregister. Das andere Register ist die Quelle (für ein Speichern) oder das Ziel (für ein Laden).

Der Offset wird einem Basisregister hinzugefügt, um die Adresse zu erhalten. Die Bildung der Adresse als Basisregister plus Offset ermöglicht einzelnen Befehlen den Zugriff auf Datenstrukturen. Zeigt das Basisregister beispielsweise auf die Spitze eines Stapels, können einzelne Befehle auf die lokalen Variablen eines Unterprogramms im Stapel zugreifen. Ebenso können die Lade- und Speicherbefehle auf eine datensatzartige Struktur oder ein speicherabgebildetes E/A-Gerät zugreifen. Die Verwendung des Registers mit konstanter Null als Basisadresse ermöglicht es einzelnen Befehlen, auf den Speicher nahe der Adresse Null zuzugreifen.

Der Speicher wird als 8-Bit-Byte adressiert, wobei die Wörter in Little-Endian- Reihenfolge vorliegen . Auf Wörter bis zur Registergröße kann mit den Lade- und Speicherbefehlen zugegriffen werden.

Auf Speicheradressen, auf die zugegriffen wird, muss nicht auf ihre Wortbreite ausgerichtet werden, aber Zugriffe auf ausgerichtete Adressen können schneller sein; zum Beispiel können einfache CPUs unausgerichtete Zugriffe mit langsamer Softwareemulation implementieren, die von einem Ausrichtungsfehler-Interrupt angetrieben wird.

Wie bei vielen RISC-Befehlssätzen (und einigen Befehlssätzen für komplexe Befehlssätze von Computern (CISC) wie den x86- und IBM System/360- Familien) fehlen RISC-V Adressmodi, die in die Register zurückschreiben. Es wird beispielsweise nicht automatisch inkrementiert.

RISC-V verwaltet Speichersysteme, die von CPUs oder Threads gemeinsam genutzt werden, indem sichergestellt wird, dass ein Ausführungsthread seine Speicheroperationen immer in der programmierten Reihenfolge sieht. Aber zwischen Threads und E/A-Geräten ist RISC-V vereinfacht: Es garantiert nicht die Reihenfolge der Speicheroperationen, außer durch spezifische Anweisungen wie fence.

Eine fenceAnweisung garantiert, dass die Ergebnisse von Vorgängeroperationen für Nachfolgeroperationen anderer Threads oder E/A-Geräte sichtbar sind. fencekann die Reihenfolge der Kombinationen von Speicher- und speicherabgebildeten E/A-Operationen garantieren. ZB kann es Speicherlese- und -schreiboperationen trennen, ohne die I/O-Operationen zu beeinflussen. Oder, wenn ein System E/A-Geräte parallel zum Speicher betreiben kann, fencesie nicht zwingt, aufeinander zu warten. Eine CPU mit einem Thread kann fenceals nop.

RISC-V ist Little-Endian und ähnelt anderen bekannten, erfolgreichen Computern, beispielsweise x86 . Dies reduziert auch die Komplexität und die Kosten einer CPU geringfügig, da sie alle Wortgrößen in der gleichen Reihenfolge liest. Beispielsweise dekodiert der RISC-V-Befehlssatz beginnend mit dem am niedrigsten adressierten Byte des Befehls. Die Spezifikation lässt die Möglichkeit von nicht standardmäßigen Big-Endian- oder Bi-Endian-Systemen offen.

Einige RISC-CPUs (wie MIPS , PowerPC , DLX und Berkeleys RISC-I) platzieren 16 Bit Offset in den Lasten und Speichern. Sie setzen die oberen 16 Bits durch einen Befehl zum Laden des oberen Worts . Dies ermöglicht ein einfaches Setzen der oberen Halbwortwerte, ohne Bits zu verschieben. Die meiste Verwendung des oberen Halbwortbefehls macht jedoch 32-Bit-Konstanten, wie Adressen. RISC-V verwendet eine SPARC- ähnliche Kombination aus 12-Bit-Offsets und 20-Bit- Set-Upper- Befehlen. Der kleinere 12-Bit-Offset hilft kompakten 32-Bit-Lade- und -Speicherbefehlen, zwei von 32 Registern auszuwählen und dennoch über genügend Bits zu verfügen, um die Befehlscodierung von RISC-V mit variabler Länge zu unterstützen.

Sofort

RISC-V verarbeitet 32-Bit-Konstanten und -Adressen mit Befehlen, die die oberen 20 Bits eines 32-Bit-Registers setzen. Oberes Sofort luiladen lädt 20 Bits in die Bits 31 bis 12. Dann kann ein zweiter Befehl, wie zum Beispiel addi, die unteren 12 Bits setzen. Kleine Zahlen oder Adressen können gebildet werden, indem das Nullregister anstelle von verwendet wird lui.

Dieses Verfahren wird erweitert, um positionsunabhängigen Code durch Hinzufügen eines Befehls zu ermöglichen, auipcder 20 obere Adressbits erzeugt, indem er einen Offset zum Programmzähler hinzufügt und das Ergebnis in einem Basisregister speichert. Dadurch kann ein Programm 32-Bit-Adressen generieren, die sich auf den Programmzähler beziehen.

Das Basisregister kann oft unverändert mit den 12-Bit-Offsets der Lade- und Speichervorgänge verwendet werden. Bei Bedarf addikönnen die unteren 12 Bits eines Registers gesetzt werden. In 64-Bit- und 128-Bit-ISAs luiund auipcVorzeichen-erweitern Sie das Ergebnis, um die größere Adresse zu erhalten.

Einige schnelle CPUs können Befehlskombinationen als einzelne verschmolzene Befehle interpretieren . luioder auipckönnen gute Kandidaten sein, um mit addi, Lasten oder Speichern zu verschmelzen .

Unterprogrammaufrufe, Sprünge und Verzweigungen

Der Unterprogrammaufruf jal(Sprung und Link) von RISC-V legt seine Rückkehradresse in einem Register ab. Dies ist bei vielen Computerdesigns schneller, weil es im Vergleich zu Systemen, die eine Rücksprungadresse direkt auf einen Stapel im Speicher schieben, einen Speicherzugriff spart. jalhat einen 20-Bit- Offset mit Vorzeichen ( Zweierkomplement ). Der Offset wird mit 2 multipliziert und dann dem PC hinzugefügt, um eine relative Adresse zu einem 32-Bit-Befehl zu erzeugen. Wenn das Ergebnis nicht an einer 32-Bit-Adresse liegt (dh gleichmäßig durch 4 teilbar ist), kann die CPU eine Ausnahme erzwingen .

RISC-CPUs V springe zur berechneten Adressen unter Verwendung einer Sprung- und Link-Register , jalrBefehls. jalrist ähnlich wie jal, erhält aber seine Zieladresse durch Hinzufügen eines 12-Bit-Offsets zu einem Basisregister. (Im Gegensatz jaldazu wird dem PC ein größerer 20-Bit-Offset hinzugefügt.)

jalrDas Bitformat von ist wie das registerbezogene Laden und Speichern. jalrKann wie diese mit den Befehlen verwendet werden, die die oberen 20 Bits eines Basisregisters setzen, um 32-Bit-Verzweigungen vorzunehmen, entweder auf eine absolute Adresse (mit lui) oder auf eine PC-relative Adresse ( auipcfür positionsunabhängigen Code ). (Die Verwendung einer konstanten Null-Basisadresse ermöglicht Einzelbefehlsaufrufe an eine kleine (den Offset), feste positive oder negative Adresse.)

RISC-V recycelt jalund jalrerhält unbedingte 20-Bit-PC-relative Sprünge und unbedingte registerbasierte 12-Bit-Sprünge. Sprünge machen das Verknüpfungsregister einfach zu 0, damit keine Rücksprungadresse gespeichert wird.

RISC-V recycelt auch jalr, um von einem Unterprogramm zurückzukehren: Dazu wird jalrdas Basisregister von auf das von jaloder gespeicherte Verknüpfungsregister gesetzt jalr. jalr's Offset ist null und das Linkage-Register ist null, so dass es keinen Offset gibt und keine Rücksprungadresse gespeichert wird.

Wie bei vielen RISC-Designs muss ein RISC-V-Compiler bei einem Unterprogrammaufruf einzelne Anweisungen verwenden, um Register beim Start auf dem Stack zu speichern und diese dann beim Beenden vom Stack wiederherzustellen. RISC-V hat keine Befehle zum Speichern mehrerer oder Wiederherstellen mehrerer Register. Diese wurden gedacht, um die CPU zu komplex und möglicherweise langsam zu machen. Dies kann mehr Coderaum beanspruchen. Die Designer planten, die Codegröße mit Bibliotheksroutinen zu reduzieren, um Register zu speichern und wiederherzustellen.

RISC-V hat kein Bedingungscoderegister oder Übertragsbit . Die Designer glaubten, dass Bedingungscodes schnelle CPUs komplexer machen, indem sie Interaktionen zwischen Befehlen in verschiedenen Ausführungsphasen erzwingen. Diese Wahl macht die Mehrfachpräzisionsarithmetik komplexer. Auch einige numerische Aufgaben benötigen mehr Energie. Daher wird die Prädikation (die bedingte Ausführung von Anweisungen) nicht unterstützt. Die Designer behaupten, dass sehr schnelle, ungeordnete CPU-Designs ohnehin eine Prädikation durchführen, indem sie den Vergleichszweig und den bedingten Code parallel ausführen und dann die Auswirkungen des ungenutzten Pfads verwerfen. Sie behaupten auch, dass die Vorhersage selbst in einfacheren CPUs weniger wertvoll ist als die Verzweigungsvorhersage , die die meisten mit bedingten Verzweigungen verbundenen Blockierungen verhindern kann. Code ohne Prädikation ist größer, mit mehr Verzweigungen, aber sie behaupten auch, dass ein komprimierter Befehlssatz (wie der Satz C von RISC-V ) dieses Problem in den meisten Fällen löst.

Stattdessen verfügt RISC-V über kurze Verzweigungen, die Vergleiche durchführen: gleich, ungleich, kleiner als, vorzeichenlos kleiner als, größer oder gleich und vorzeichenlos größer oder gleich. Zehn Vergleichsverzweigungsoperationen werden mit nur sechs Befehlen implementiert, indem die Reihenfolge der Operanden im Assembler umgekehrt wird . Zum Beispiel kann eine Verzweigung, wenn größer als durch weniger als mit einer umgekehrten Operandenreihenfolge ausgeführt werden.

Die Vergleichszweige haben einen vorzeichenbehafteten Zwölf-Bit-Bereich und springen relativ zum PC.

Im Gegensatz zu einigen RISC-Architekturen enthält RISC-V keinen Verzweigungsverzögerungsschlitz , eine Position nach einem Verzweigungsbefehl, die mit einem Befehl gefüllt werden kann, der unabhängig davon ausgeführt wird, ob die Verzweigung genommen wird oder nicht. RISC-V lässt einen Verzweigungsverzögerungs-Slot weg, weil es Multicycle-CPUs, superskalare CPUs und lange Pipelines erschwert. Dynamische Verzweigungsprädiktoren haben sich gut genug bewährt, um den Bedarf an verzögerten Verzweigungen zu reduzieren.

Bei der ersten Begegnung mit einer Verzweigung sollten RISC-V-CPUs annehmen, dass eine negative relative Verzweigung (dh das Vorzeichenbit des Offsets ist "1") genommen wird. Dies setzt voraus, dass eine Rückwärtsverzweigung eine Schleife ist, und stellt eine Standardrichtung bereit, so dass einfache Pipeline-CPUs ihre Pipeline von Befehlen füllen können. Abgesehen davon erfordert RISC-V keine Verzweigungsvorhersage , aber Kernimplementierungen dürfen sie hinzufügen. RV32I reserviert einen "HINT"-Befehlsbereich, der derzeit keine Hinweise auf Verzweigungen enthält.

Arithmetische und logische Sätze

RISC-V trennt Mathematik in einen minimalen Satz von Integer- Befehlen (Satz I ) mit Addieren, Subtrahieren, Verschieben, bitweiser Logik und Vergleichszweigen. Diese können die meisten anderen RISC-V-Befehlssätze mit Software simulieren. (Die atomaren Befehle sind eine bemerkenswerte Ausnahme.) RISC-V fehlen derzeit die zählführenden Nullen und Bitfeldoperationen, die normalerweise verwendet werden, um Software-Gleitkomma in einem reinen Ganzzahlprozessor zu beschleunigen.

Die Integer-Multiplikationsbefehle (Menge M ) umfassen vorzeichenbehaftete und vorzeichenlose Multiplikation und Division. Ganzzahlige Multiplikationen und Divisionen mit doppelter Genauigkeit sind ebenso enthalten wie Multiplikationen und Divisionen, die das High-Word des Ergebnisses erzeugen . Das ISA-Dokument empfiehlt, dass Implementierer von CPUs und Compilern eine standardisierte Sequenz von High- und Low-Multiplikations- und Divisionsbefehlen nach Möglichkeit zu einer Operation verschmelzen .

Die Gleitkomma- Befehle (Satz F ) umfassen Arithmetik mit einfacher Genauigkeit und auch Vergleichszweige ähnlich der Ganzzahlarithmetik. Es erfordert einen zusätzlichen Satz von 32 Gleitkommaregistern. Diese sind von den Integer-Registern getrennt. Die Gleitkommabefehle mit doppelter Genauigkeit (Satz D ) gehen im Allgemeinen davon aus, dass die Gleitkommaregister 64 Bit (dh doppelte Breite) haben und die F- Untermenge mit der D- Gruppe koordiniert ist . Ein 128-Bit-Gleitkomma-ISA ( Q ) mit vierfacher Genauigkeit ist ebenfalls definiert. RISC-V-Computer ohne Gleitkomma können eine Gleitkomma-Softwarebibliothek verwenden.

RISC-V verursacht keine Ausnahmen bei arithmetischen Fehlern, einschließlich Überlauf , Unterlauf, Unternormal und Division durch Null. Stattdessen erzeugen sowohl Integer- als auch Gleitkomma-Arithmetik vernünftige Standardwerte und setzen Statusbits. Eine Division durch Null kann von einer Verzweigung nach der Division entdeckt werden. Die Statusbits können durch ein Betriebssystem oder einen periodischen Interrupt getestet werden.

Atomare Speicheroperationen

RISC-V unterstützt Computer, die den Arbeitsspeicher von mehreren CPUs und Threads gemeinsam nutzen . Das Standard-Speicherkonsistenzmodell von RISC-V ist die Release-Konsistenz . Das heißt, Lade- und Speichervorgänge können im Allgemeinen neu geordnet werden, aber einige Ladevorgänge können als Erwerbsoperationen bezeichnet werden, die späteren Speicherzugriffen vorausgehen müssen, und einige Speicherungen können als Freigabeoperationen bezeichnet werden, die früheren Speicherzugriffen folgen müssen.

Der Basisbefehlssatz enthält minimale Unterstützung in Form eines fenceBefehls , um eine Speicherordnung zu erzwingen. Obwohl dies ausreichend ist ( fence r, rwstellt Erwerb bereit und fence rw, wstellt Freigabe bereit ), können kombinierte Operationen effizienter sein.

Die atomare Speicheroperationserweiterung unterstützt zwei Arten von atomaren Speicheroperationen für die Releasekonsistenz. Erstens stellt es ladereservierte lr und speicherbedingte sc Allzweckbefehle bereit . lrführt einen Ladevorgang durch und versucht, diese Adresse für seinen Thread zu reservieren. Eine spätere Speicherbedingung scfür die reservierte Adresse wird nur ausgeführt, wenn die Reservierung nicht durch einen dazwischenliegenden Speicher von einer anderen Quelle gebrochen wird. Wenn das Speichern erfolgreich ist, wird eine Null in ein Register geschrieben. Wenn dies fehlgeschlagen ist, weist ein Wert ungleich Null darauf hin, dass die Software den Vorgang wiederholen muss. In beiden Fällen wird die Reservierung freigegeben.

Die zweite Gruppe von atomaren Befehlen führt Lese-Modifizier-Schreib- Sequenzen aus: ein Laden (was optional ein Laden-Erfassen ist) in ein Zielregister, dann eine Operation zwischen dem geladenen Wert und einem Quellregister, dann ein Speichern des Ergebnisses (was kann optional ein Store-Release sein). Wenn die Speicherbarrieren optional sind, können die Operationen kombiniert werden. Die optionalen Operationen werden durch Erwerbs- und Freigabebits aktiviert , die in jedem atomaren Befehl vorhanden sind. RISC-V definiert neun mögliche Operationen: swap (Quellregisterwert direkt verwenden); hinzufügen; bitweise und, oder, und exklusiv-oder; und signiertes und nicht signiertes Minimum und Maximum.

Ein Systemdesign kann diese kombinierten Operationen mehr als lrund optimieren sc. Wenn beispielsweise das Zielregister für einen Swap die Konstante Null ist, kann das Laden übersprungen werden. Wenn der gespeicherte Wert seit dem Laden unverändert ist, kann die Speicherung übersprungen werden.

Das IBM System/370 und seine Nachfolger, einschließlich z/Architecture und x86 , implementieren beide einen Vergleichs-und-Swap-cas Befehl ( ), der einen Speicherort im Speicher testet und bedingt aktualisiert: Wenn der Speicherort einen erwarteten alten Wert enthält, wird er casersetzt durch ein gegebener neuer Wert; es gibt dann eine Angabe zurück, ob es die Änderung vorgenommen hat. Jedoch wird gewöhnlich ein einfacher Befehl vom Ladetyp ausgeführt, bevor casder alte Wert abgerufen wird. Das klassische Problem besteht darin, dass, wenn ein Thread einen Wert A liest (lädt) , einen neuen Wert C berechnet und dann ( cas) verwendet, um A durch C zu ersetzen , er keine Möglichkeit hat zu wissen, ob gleichzeitige Aktivität in einem anderen Thread A durch einen ersetzt hat anderen Wert B und dann das A dazwischen wiederhergestellt . Bei einigen Algorithmen (zB solchen, bei denen die Werte im Speicher Zeiger auf dynamisch zugewiesene Blöcke sind) kann dieses ABA-Problem zu falschen Ergebnissen führen. Die gebräuchlichste Lösung verwendet einen doppelt breitencas Befehl, um sowohl den Zeiger als auch einen benachbarten Zähler zu aktualisieren; leider erfordert ein solcher Befehl ein spezielles Befehlsformat, um mehrere Register zu spezifizieren, führt mehrere Lese- und Schreibvorgänge durch und kann einen komplexen Busbetrieb haben.

Die lr/ scAlternative ist effizienter. Es erfordert normalerweise nur eine Speicherladung, und es ist wünschenswert, langsame Speicheroperationen zu minimieren. Es ist auch genau: Es steuert alle Zugriffe auf die Speicherzelle, anstatt nur ein Bitmuster zu gewährleisten. Im Gegensatz zu cas, kann es jedoch Livelock zulassen , bei dem zwei oder mehr Threads wiederholt dazu führen, dass die Anweisungen des anderen fehlschlagen. RISC-V garantiert Vorwärtsfortschritt (kein Livelock), wenn der Code Regeln bezüglich des Timings und der Reihenfolge der Anweisungen befolgt: 1) Er darf nur die I- Teilmenge verwenden. 2) Um wiederholte Cache-Fehltreffer zu verhindern, darf der Code (einschließlich der Wiederholungsschleife) nicht mehr als 16 aufeinanderfolgende Befehle belegen. 3) Es darf keine System- oder Zaunanweisungen enthalten oder Rückwärtszweige zwischen den lrund genommen werden sc. 4) Die Rückwärtsverzweigung zur Wiederholungsschleife muss zur ursprünglichen Sequenz führen.

Die Spezifikation enthält Beispiele dafür, wie diese Teilmenge verwendet wird, um eine Datenstruktur zu sperren.

Komprimierte Teilmenge

Der Standard-RISC-V-ISA gibt an, dass alle Befehle 32 Bit haben. Dies führt zu einer besonders einfachen Implementierung, führt jedoch wie bei anderen RISC-Prozessoren mit einer solchen Befehlscodierung zu einer größeren Codegröße als bei anderen Befehlssätzen. Um dies zu kompensieren, sind die 32-Bit- Befehle von RISC-V tatsächlich 30 Bits; 3 ⁄ 4 des Opcode- Raums sind für einen optionalen (aber empfohlenen) komprimierten Befehlssatz variabler Länge , RVC, reserviert , der 16-Bit-Befehle enthält. Wie ARMs Thumb und MIPS16 sind die komprimierten Befehle einfach Aliase für eine Teilmenge der größeren Befehle. Im Gegensatz zu ARMs Thumb oder dem MIPS Compressed Set wurde Speicherplatz von Anfang an reserviert, sodass es keinen separaten Betriebsmodus gibt. Standard- und komprimierte Anweisungen können frei gemischt werden. (Erweiterungsbuchstabe ist C .)

Da (wie Thumb-1 und MIPS16) die komprimierten Anweisungen einfach alternative Codierungen (Aliasnamen) für eine ausgewählte Teilmenge größerer Anweisungen sind, kann die Komprimierung im Assembler implementiert werden, und es ist nicht unbedingt erforderlich, dass der Compiler davon weiß.

Ein Prototyp von RVC wurde 2011 getestet. Der Prototypcode war 20 % kleiner als ein x86- PC und MIPS- komprimierter Code und 2 % größer als der ARM Thumb-2- Code. Es reduzierte auch erheblich sowohl den benötigten Cache-Speicher als auch den geschätzten Stromverbrauch des Speichersystems.

Der Forscher beabsichtigte, die binäre Größe des Codes für kleine Computer, insbesondere eingebettete Computersysteme , zu reduzieren . Der Prototyp enthielt 33 der am häufigsten verwendeten Befehle, die unter Verwendung von Operationscodes, die zuvor für den komprimierten Satz reserviert waren, als kompakte 16-Bit-Formate umkodiert wurden. Die Komprimierung erfolgte im Assembler , ohne Änderungen am Compiler. Komprimierte Befehle ließen Felder weg, die oft Null sind, verwendeten kleine Sofortwerte oder griffen auf Teilmengen (16 oder 8) der Register zu. addiist sehr verbreitet und oft komprimierbar.

Ein Großteil des Größenunterschieds im Vergleich zum Thumb-Set von ARM ist darauf zurückzuführen, dass RISC-V und der Prototyp keine Anweisungen zum Speichern und Wiederherstellen mehrerer Register haben. Stattdessen generierte der Compiler konventionelle Befehle, die auf den Stack zugreifen. Der Prototyp des RVC-Assemblers konvertierte diese dann oft in komprimierte Formen, die halb so groß waren. Dies benötigte jedoch immer noch mehr Codeplatz als die ARM-Befehle, die mehrere Register speichern und wiederherstellen. Der Forscher schlug vor, den Compiler so zu modifizieren, dass er Bibliotheksroutinen zum Speichern und Wiederherstellen von Registern aufruft. Diese Routinen würden dazu neigen, in einem Code-Cache zu verbleiben und daher schnell zu laufen, wenn auch wahrscheinlich nicht so schnell wie ein Save-Multiple-Befehl.

Standard-RVC erfordert die gelegentliche Verwendung von 32-Bit-Befehlen. Mehrere nicht standardmäßige RVC-Vorschläge sind vollständig, erfordern keine 32-Bit-Befehle und sollen höhere Dichten als Standard-RVC aufweisen. Ein weiterer Vorschlag baut darauf auf und behauptet, ebenfalls weniger Codierungsbereich zu verwenden.

Eingebettete Teilmenge

Ein Befehlssatz für die kleinsten Embedded- CPUs (Satz E) wird auf andere Weise reduziert: Es werden nur 16 der 32 Integer-Register unterstützt. Gleitkomma-Anweisungen sollten nicht unterstützt werden (die Spezifikation verbietet dies als unwirtschaftlich), daher muss eine Gleitkomma-Softwarebibliothek verwendet werden. Der komprimierte Satz C wird empfohlen. Der privilegierte Befehlssatz unterstützt nur den Maschinenmodus, den Benutzermodus und Speicherschemata, die eine Basis- und gebundene Adressverschiebung verwenden.

Es gab Diskussionen über ein Mikrocontroller-Profil für RISC-V, um die Entwicklung tief eingebetteter Systeme zu erleichtern . Es konzentriert sich auf schnellere, einfache C-Sprachunterstützung für Interrupts, vereinfachte Sicherheitsmodi und eine vereinfachte POSIX- Anwendungsbinärschnittstelle.

Korrespondenten haben auch kleinere, nicht standardmäßige 16-Bit- RV16E- ISAs vorgeschlagen: Mehrere ernsthafte Vorschläge würden die 16-Bit- C- Befehle mit 8 × 16-Bit-Registern verwenden. Ein April - Scherz vorgeschlagen , eine sehr praktische Anordnung: Nutzen 16 × 16-Bit - Ganzzahl - Register, mit der Standard - EIMC (. , Darunter 32-Bit - Befehle) ISAs Der Witz verwendet Bankumschaltung , wenn ein 32-Bit - CPU deutlich überlegen sein würden , mit dem größeren Adressraum.

Privilegierter Befehlssatz

Die ISA von RISC-V enthält eine separate privilegierte Befehlssatzspezifikation. Ab August 2019 wird Version 1.11 von RISC-V International ratifiziert.

Version 1.11 der Spezifikation unterstützt verschiedene Arten von Computersystemen:

  1. Systeme , die nur den Maschinenmodus haben , vielleicht für eingebettete Systeme ,
  2. Systeme mit sowohl dem Maschinenmodus (für den Supervisor ) als auch dem Benutzermodus, um Betriebssysteme zu implementieren, die den Kernel in einem privilegierten Modus ausführen .
  3. Systeme mit Maschinenmodus, Hypervisoren , mehreren Supervisoren und Benutzermodi unter jedem Supervisor.

Diese entsprechen in etwa Systemen mit höchstens vier Ringen von Privilegien und Sicherheit: Maschine, Hypervisor, Supervisor und Benutzer. Es wird auch erwartet, dass jede Schicht über eine dünne Schicht standardisierter unterstützender Software verfügt, die mit einer privilegierteren Schicht oder Hardware kommuniziert.

Der Gesamtplan für diese ISA besteht darin, den Hypervisor-Modus orthogonal zu den Benutzer- und Supervisor-Modi zu machen. Das grundlegende Merkmal ist ein Konfigurationsbit, das entweder dem Supervisor-Level-Code erlaubt, auf Hypervisor-Register zuzugreifen, oder eine Unterbrechung bei Zugriffen verursacht. Dieses Bit ermöglicht es dem Supervisor-Modus, die von einem Hypervisor benötigte Hardware direkt zu handhaben. Dies vereinfacht einen Hypervisor vom Typ 2, der von einem Betriebssystem gehostet wird. Dies ist ein beliebter Modus zum Ausführen von Computern auf Lagerebene. Um nicht gehostete Hypervisoren vom Typ 1 zu unterstützen, kann das Bit bewirken, dass diese Zugriffe auf einen Hypervisor unterbrochen werden. Das Bit vereinfacht die Verschachtelung von Hypervisoren, bei denen ein Hypervisor unter einem Hypervisor läuft. Es soll auch den Supervisor-Code vereinfachen, indem es dem Kernel erlaubt, seine eigenen Hypervisor-Funktionen mit seinem eigenen Kernel-Code zu verwenden. Als Ergebnis unterstützt die Hypervisor-Form der ISA fünf Modi: Maschine, Supervisor, Benutzer, Supervisor-unter-Hypervisor und Benutzer-unter-Hypervisor.

Die Spezifikation des privilegierten Befehlssatzes definiert explizit Hardware- Threads oder harts . Mehrere Hardware-Threads sind bei leistungsfähigeren Computern eine gängige Praxis. Wenn ein Thread angehalten wird und auf Speicher wartet, können andere häufig fortfahren. Hardware-Threads können helfen, die große Anzahl von Registern und Ausführungseinheiten in schnellen CPUs außerhalb der Reihenfolge besser zu nutzen. Schließlich können Hardware-Threads eine einfache, leistungsstarke Möglichkeit sein, Interrupts zu handhaben : Es ist kein Speichern oder Wiederherstellen von Registern erforderlich, sondern es wird einfach ein anderer Hardware-Thread ausgeführt. Der einzige Hardwarethread, der in einem RISC-V-Computer erforderlich ist, ist jedoch Thread null.

Die vorhandenen Steuer- und Statusregisterdefinitionen unterstützen die Fehler- und Speicherausnahmen von RISC-V sowie eine kleine Anzahl von Interrupts. Für Systeme mit mehr Interrupts definiert die Spezifikation auch einen Interrupt-Controller. Interrupts beginnen immer auf der höchsten privilegierten Maschinenebene, und die Steuerregister jeder Ebene haben explizite Weiterleitungsbits , um Interrupts an weniger privilegierten Code weiterzuleiten . Beispielsweise muss der Hypervisor keine Software enthalten, die bei jedem Interrupt ausgeführt wird, um einen Interrupt an ein Betriebssystem weiterzuleiten. Stattdessen kann er beim Setup Bits setzen, um den Interrupt weiterzuleiten.

In der Spezifikation werden mehrere Speichersysteme unterstützt. Physical-only ist für die einfachsten eingebetteten Systeme geeignet . Es gibt auch drei virtuelle Speichersysteme im UNIX- Stil für Speicher, der in Massenspeichersystemen zwischengespeichert wird. Die virtuellen Speichersysteme haben drei Größen, mit Adressen der Größe 32, 39 und 48 Bit. Alle virtuellen Speichersysteme unterstützen 4 KiB-Seiten, mehrstufige Seitentabellenbäume und verwenden sehr ähnliche Algorithmen, um die Seitentabellenbäume zu durchlaufen. Alle sind entweder für Hardware- oder Software-Page-Table-Walking ausgelegt. Um optional die Kosten von Seitentabellendurchläufen zu reduzieren, können Seiten mit übergroßer Größe Blattseiten in höheren Ebenen des Seitentabellenbaums eines Systems sein. SV32 hat einen zweischichtigen Seitentabellenbaum und unterstützt 4 MiB Superpages. SV39 hat eine dreistufige Seitentabelle und unterstützt 2 MiB Superpages und 1 GiB Gigapages. SV48 ist erforderlich, um SV39 zu unterstützen. Es hat auch eine 4-stufige Seitentabelle und unterstützt 2 MiB Superpages, 1 GiB Gigapages und 512 GiB Terapages. Superpages werden an den Seitengrenzen für die nächstniedrigere Seitengröße ausgerichtet.

Bit-Manipulation

Eine nicht genehmigte Bitmanipulations-ISA (B) für RISC-V ist in Arbeit und wird ab Januar 2021 überprüft. Gut gemacht, kann eine Bitmanipulationsuntermenge kryptografische, grafische und mathematische Operationen unterstützen. Die im Entwurf dokumentierten Aufnahmekriterien waren konform mit den RV5-Philosophien und ISA-Formaten, wesentliche Verbesserungen der Codedichte oder -geschwindigkeit (dh mindestens eine 3-zu-1-Reduzierung der Anweisungen) und erhebliche reale Anwendungen, einschließlich bereits vorhandener Compiler Unterstützung. Version 0.93 enthält Anweisungen zum Zählen führender Nullen, Zählen von gesetzten Bits, Ausführen von Logikoperationen mit Negierung, Packen von zwei Wörtern in ein Register, Nehmen von Min oder Max, Vorzeichenerweiterung, Einzelbit-Operationen, Verschieben von Einsen, Rotieren, eine verallgemeinerte Bit- Umkehr-, Shuffle- und Crossbar-Permutationen, verallgemeinerte Oder-Kombinationen, Bitfeldplatzierung, Extrahieren und Ablegen, übertragslose Multiplikation, CRC-Befehle, Bitmatrix-Operationen (nur RV64), bedingte Mischung, bedingte Verschiebung, Trichterverschiebungen und vorzeichenlose Adresse Berechnungen.

Verpackte SIMD

Gepackte SIMD-Befehle werden von kommerziellen CPUs häufig verwendet, um die Multimedia- und andere digitale Signalverarbeitung kostengünstig zu beschleunigen . Für einfache, kostenreduzierte RISC-V-Systeme schlug die Spezifikation der Basis-ISA vor, die Bits der Gleitkommaregister zu verwenden, um eine parallele Einzelbefehls-Mehrfachdaten( SIMD ) -Unterwortarithmetik durchzuführen .

Im Jahr 2017 veröffentlichte ein Anbieter einen detaillierteren Vorschlag an die Mailingliste, der als Version 0.1 zitiert werden kann. Ab 2019 variiert die Effizienz dieser vorgeschlagenen ISA von 2x bis 5x einer Basis-CPU für eine Vielzahl von DSP-Codecs. Dem Vorschlag fehlten Instruktionsformate und eine Lizenzzuweisung an RISC-V International, aber er wurde von der Mailingliste geprüft. Einige unbeliebte Teile dieses Vorschlags waren, dass er einen Bedingungscode hinzufügte, den ersten in einem RISC-V-Design, benachbarte Register verknüpfte (auch ein erster) und einen Schleifenzähler hat, der in einigen Mikroarchitekturen schwierig zu implementieren sein könnte.

Eine frühere, viel beachtete Implementierung für eine 64-Bit-CPU war die Multimedia-Anleitung von PA-RISC: Multimedia Acceleration eXtensions . Es erhöhte die Leistung der CPU bei digitalen Signalverarbeitungsaufgaben um das 48-Fache oder mehr und ermöglichte 1995 praktische Echtzeit- Videocodecs . Neben der nativen 64-Bit-Mathematik konnte die PA-RISC MAX2-CPU mit vier 16-Bit-Subwörtern rechnen gleichzeitig mit mehreren Überlaufmethoden. Es könnte auch Unterwörter an andere Positionen verschieben. MAX2 von PA-RISC wurde bewusst vereinfacht. Es fehlte die Unterstützung für 8-Bit- oder 32-Bit-Subwörter. Die 16-Bit-Teilwortgröße wurde gewählt, um die meisten digitalen Signalverarbeitungsaufgaben zu unterstützen. Diese Anweisungen waren kostengünstig zu entwerfen und zu bauen.

Vektorset

Der vorgeschlagene Vektorverarbeitungs- Befehlssatz kann den gepackten SIMD- Satz obsolet machen. Die Designer hoffen, genügend Flexibilität zu haben, damit eine CPU Vektorbefehle in den Registern eines Standardprozessors implementieren kann. Dies würde minimale Implementierungen mit ähnlicher Leistung wie eine Multimedia-ISA wie oben ermöglichen. Ein echter Vektor-Coprozessor könnte jedoch denselben Code mit höherer Leistung ausführen.

Mit Stand vom 29. Juni 2015 ist der Vektorverarbeitungsvorschlag ein konservatives, flexibles Design eines Allzweck- Vektorprozessors mit gemischter Präzision , der geeignet ist, Rechenkerne auszuführen . Code würde leicht auf CPUs mit unterschiedlichen Vektorlängen portiert, idealerweise ohne Neukompilierung.

Im Gegensatz dazu sind SIMD-Erweiterungen mit kurzen Vektoren weniger bequem. Diese werden in x86 , ARM und PA-RISC verwendet . Bei diesen erzwingt eine Änderung der Wortbreite eine Änderung des Befehlssatzes, um die Vektorregister zu erweitern (im Fall von x86 von 64-Bit- MMX- Registern zu 128-Bit- Streaming SIMD Extensions (SSE), zu 256-Bit- Advanced Vektorerweiterungen (AVX) und AVX-512 ). Das Ergebnis ist ein wachsender Befehlssatz und die Notwendigkeit, den Arbeitscode auf die neuen Befehle zu portieren.

In der RISC-V-Vektor-ISA ist, anstatt die Vektorlänge in der Architektur festzulegen, ein Befehl ( setvl) verfügbar, der eine angeforderte Größe annimmt und die Vektorlänge auf das Minimum der Hardwaregrenze und der angeforderten Größe setzt. Der RISC-V-Vorschlag ähnelt also eher dem Long-Vektor-Design von Cray oder der Scalable Vector Extension von ARM. Das heißt, jeder Vektor in bis zu 32 Vektoren hat die gleiche Länge.

Die Anwendung spezifiziert die benötigte Gesamtvektorbreite, und der Prozessor bestimmt die Vektorlänge, die er mit verfügbaren On-Chip-Ressourcen bereitstellen kann. Dies erfolgt in Form eines Befehls ( vsetcfg) mit vier unmittelbaren Operanden, der die Anzahl der benötigten Vektorregister jeder verfügbaren Breite angibt. Die Gesamtzahl darf die adressierbare Grenze von 32 nicht überschreiten, kann aber auch geringer sein, wenn die Anwendung nicht alle benötigt. Die Vektorlänge wird durch den verfügbaren Speicher auf dem Chip dividiert durch die Anzahl der für jeden Eintrag benötigten Speicherbytes begrenzt. (Es können auch zusätzliche Hardwaregrenzen vorhanden sein, die wiederum Implementierungen im SIMD-Stil ermöglichen.)

Außerhalb von Vektorschleifen kann die Anwendung die Anzahl der angeforderten Vektorregister auf Null setzen, was dem Betriebssystem die Arbeit erspart, sie bei Kontextwechseln zu speichern .

Die Vektorlänge ist nicht nur architektonisch variabel, sondern auch so ausgelegt, dass sie zur Laufzeit variiert. Um diese Flexibilität zu erreichen, verwendet der Befehlssatz wahrscheinlich Datenpfade mit variabler Breite und Operationen vom variablen Typ, die polymorphes Überladen verwenden. Der Plan ist, dass diese die Größe und Komplexität von ISA und Compiler reduzieren können.

Neuere experimentelle Vektorprozessoren mit Datenpfaden variabler Breite zeigen auch profitable Steigerungen bei den Operationen pro Sekunde (Geschwindigkeit), Fläche (geringere Kosten) und Watt (längere Batterielebensdauer).

Im Gegensatz zu einer typischen modernen Grafikverarbeitungseinheit ist keine spezielle Hardware zur Unterstützung der Verzweigungsprädikation geplant . Stattdessen wird eine Compiler-basierte Prädikation mit geringeren Kosten verwendet.

Externes Debug-System

Es gibt eine vorläufige Spezifikation für den hardwareunterstützten Debugger von RISC-V . Der Debugger verwendet ein Transportsystem wie die Joint Test Action Group ( JTAG ) oder den Universal Serial Bus ( USB ), um auf Debug-Register zuzugreifen. Eine Standard-Hardware-Debug-Schnittstelle kann entweder eine standardisierte abstrakte Schnittstelle oder eine Befehlszuführung unterstützen .

Ab Januar 2017 bleibt die genaue Form der abstrakten Schnittstelle undefiniert, aber Vorschläge umfassen ein speicherabgebildetes System mit standardisierten Adressen für die Register von Debug-Geräten oder ein Befehlsregister und ein Datenregister, auf das das Kommunikationssystem zugreifen kann. Korrespondenten behaupten , dass ähnliche Systeme verwendet werden , von Freescale ‚s Debug- Hintergrundbetrieb Interface (BDM) für einige CPUs, ARM , OpenRISC und Aeroflex ‘ s LEON .

Bei der Befehlszuführung verarbeitet die CPU eine Debug-Ausnahme, um einzelne in ein Register geschriebene Befehle auszuführen. Dies kann durch ein Datenweiterleitungsregister und ein Modul zum direkten Zugriff auf den Speicher ergänzt werden. Durch die Befehlszuführung kann der Debugger genau wie eine Software auf den Computer zugreifen. Es minimiert auch Änderungen in der CPU und passt sich an viele CPU-Typen an. Dies sei besonders für RISC-V geeignet, da es explizit für viele Computertypen entwickelt wurde. Das Datenweiterleitungsregister ermöglicht es einem Debugger, eine Datenbewegungsschleife in den RAM zu schreiben und dann die Schleife auszuführen, um Daten mit einer Geschwindigkeit nahe der maximalen Geschwindigkeit des Datenkanals des Fehlersuchsystems in den Computer hinein oder aus ihm heraus zu bewegen. Korrespondenten sagen , dass ähnliche Systeme verwendet werden , MIPS Technologies MIPS , Intel Quark , Tensilica 's Xtensa und für Freescale Power - ISA - CPUs' Background Debug Mode - Schnittstelle (BDM).

Ein Anbieter schlug ein Hardware-Trace-Subsystem zur Standardisierung vor, spendete ein konformes Design und leitete eine Überprüfung ein. Der Vorschlag betrifft ein Hardwaremodul, das die Codeausführung auf den meisten RV5-CPUs verfolgen kann. Um die Datenrate zu reduzieren und einfachere oder kostengünstigere Pfade für die Ablaufverfolgungsdaten zu ermöglichen, erzeugt der Vorschlag keine Ablaufverfolgungsdaten, die aus einem Binärbild des Codes berechnet werden könnten. Es sendet nur Daten, die "nicht zuordenbare" Pfade durch das Programm anzeigen, beispielsweise welche bedingten Verzweigungen genommen werden. Um die Datenraten zu reduzieren, werden berechenbare Verzweigungen, wie z. B. unbedingte Verzweigungen, nicht verfolgt. Die vorgeschlagene Schnittstelle zwischen dem Modul und der Steuereinheit ist ein logisches Signal für jeden nicht ableitbaren Befehlstyp. Adressen und andere Daten müssen in einem spezialisierten Bus bereitgestellt werden, der an geeignete Datenquellen in einer CPU angeschlossen ist. Die an eine externe Trace-Einheit gesendete Datenstruktur besteht aus einer Reihe von Kurznachrichten mit den benötigten Daten. Die Details des Datenkanals werden im Vorschlag bewusst nicht beschrieben, da mehrere sinnvoll sein dürften.

Implementierungen

Die RISC-V-Organisation verwaltet eine Liste der RISC-V-CPU- und SoC-Implementierungen.

Bestehende

Bestehende proprietäre Implementierungen umfassen:

  • Alibaba Group kündigte im Juli 2019 den 2,5 GHz 16-Core 64-Bit (RV64GCV) XuanTie 910 Prozessor an, der nicht in Ordnung ist
  • Allwinner Technology hat die XianTie C906 CPU in ihren D1 Anwendungsprozessor integriert.
  • Andes Technology Corporation , ein Premier-Gründungsmitglied von RISC-V International. Die RISC-V-CPU-Familien reichen von winzigen 32-Bit-Cores bis hin zu fortschrittlichen 64-Bit-Cores mit DSP-, FPU-, Vector-, Linux-, Superskalar- und/oder Multicore-Funktionen.
  • CloudBEAR ist ein Prozessor-IP-Unternehmen, das seine eigenen RISC-V-Cores für eine Reihe von Anwendungen entwickelt.
  • Codasip, ein Gründungsmitglied von RISC-V International, hat eine Reihe von energiesparenden Embedded-, Hochleistungs-Embedded- und Anwendungsprozessorkernen entwickelt.
  • Cortus, ein Platin-Gründungsmitglied von RISC-V International, verfügt über eine Reihe von RISC-V-Implementierungen und ein komplettes IDE-/Toolchain-/Debug-Ökosystem, das es im Rahmen seines SoC-Designgeschäfts kostenlos anbietet.
  • Espressif hat seinem ESP32- S2-Mikrocontroller einen RISC-V-ULP-Coprozessor hinzugefügt. Im November 2020 kündigte Espressif seinen ESP32-C3 an, eine Single-Core, 32-Bit, RISC-V (RV32IMC) basierende MCU.
  • GigaDevice verfügt über eine Reihe von MCUs basierend auf RISC-V (RV32IMAC, GD32V-Serie), von denen einer auf dem Longan Nano-Board verwendet wird, das von einem chinesischen Elektronikunternehmen Sipeed hergestellt wird .
  • GreenWaves Technologies gab im Februar 2018 die Verfügbarkeit von GAP8 bekannt, einem 32-Bit-1-Controller plus 8 Rechenkernen, einem 32-Bit-SoC (RV32IMC) und einem Entwicklerboard. Das GAPuino GAP8-Entwicklungsboard wurde im Mai 2018 ausgeliefert.
  • Instant SoC RISC-V Cores von FPGA Cores. System On Chip, einschließlich RISC-V-Kerne, definiert durch C++.
  • Micro Magic Inc. kündigte im Oktober 2020 den weltweit schnellsten 64-Bit-RISC-V-Kern mit 5 GHz und 13.000 CoreMarks an.
  • SiFive , ein Unternehmen, das speziell für die Entwicklung von RISC-V-Hardware gegründet wurde, hat 2017 Prozessormodelle veröffentlicht. Dazu gehört ein Quad-Core-64-Bit- System (RV64GC) auf einem Chip (SoC), das universelle Betriebssysteme wie z Linux.
  • Syntacore, ein Gründungsmitglied von RISC-V International und einer der ersten kommerziellen RISC-V-IP-Anbieter, entwickelt und lizenziert die RISC-V-IP-Familie seit 2015. Ab 2018 umfasst die Produktlinie acht 32- und 64-Bit-Cores, einschließlich Open-Source-SCR1-MCU-Kern (RV32I/E[MC]). Erste kommerzielle SoCs, basierend auf dem Syntacore IP, wurden 2016 demonstriert.
  • Codasip und UltraSoC haben vollständig unterstütztes geistiges Eigentum für eingebettete RISC-V-SOCs entwickelt, die die RISC-V-Cores von Codasip und andere IPs mit den Debug-, Optimierungs- und Analysefunktionen von UltraSoC kombinieren.
  • Ab 2020 verwendet der indische Verteidigungs- und Strategiesektor den von IIT-Madras entwickelten 64-Bit-RISC-V-basierten 100-350-MHz-Risecreek-Prozessor, der von Intel mit einem 22-nm- FinFET- Prozess hergestellt wird.

In Entwicklung

  • ASTC hat eine RISC-V-CPU für eingebettete ICs entwickelt.
  • Center for Development of Advanced Computing (C-DAC) in Indien entwickelt einen Single-Core-32-Bit-In-Order, einen Single-Core-64-Bit-In-Order und drei Out-of-Order-Single-, Dual- und Quad-Core-RISC- V-Prozessor unter der Vega-Serie.
  • Cobham Gaisler NOEL-V 64-Bit.
  • Computer Laboratory der University of Cambridge hat dieses Betriebssystem in Zusammenarbeit mit dem FreeBSD- Projekt auf 64-Bit-RISC-V portiert, um es als Hardware-Software-Forschungsplattform zu verwenden.
  • Esperanto Technologies gab bekannt, dass sie drei RISC-V-basierte Prozessoren entwickeln: den Hochleistungskern ET-Maxion , den energieeffizienten Kern ET-Minion und den Grafikprozessor ET-Graphics .
  • Die ETH Zürich und die Universität Bologna haben im Rahmen des Projekts Parallel Ultra-Low Power (PULP) für energieeffizientes IoT-Computing den Open-Source-Prozessor RISC-V PULPino gemeinsam entwickelt.
  • Europäische Prozessorinitiative (EPI), RISC-V Accelerator Stream.
    Illustration des ersten funktionierenden RISC-V- Chipmusters von EPI im Jahr 2021.
  • Rekonfigurierbaren Intelligent System Engineering Group (RISE) der IIT-Madras entwickelt sechs Shakti Serie RISC-V Open-Source - CPU - Design für sechs verschiedene Anwendungen, von einem kleinen 32-Bit - CPU für das Internet der Dinge (IoT) bis hin zu großen, 64- Bit-CPUs, die für Computer im Lagerbereich wie Serverfarmen entwickelt wurden, die auf RapidIO- und Hybrid Memory Cube- Technologien basieren . 32-Bit-Moushik wurde von RISE erfolgreich für die Anwendung von Kreditkarten, elektronischen Wahlmaschinen (EVMs), Überwachungskameras, Tresorschlössern und personalisierten Gesundheitsmanagementsystemen gebootet .
  • lowRISC ist ein gemeinnütziges Projekt zur Implementierung eines vollständig quelloffenen Hardware- Systems auf einem Chip (SoC) basierend auf der 64-Bit-RISC-V-ISA.
  • Nvidia plant den Einsatz von RISC-V, um ihren Falcon-Prozessor auf ihren GeForce- Grafikkarten zu ersetzen .
  • Das RV64X-Konsortium arbeitet an einer Reihe von Grafikerweiterungen für RISC-V und hat angekündigt, einen Open-Source-RISC-V-Kern mit einer GPU-Einheit zu entwickeln.
  • SiFive kündigte seinen ersten RISC-V - Hochleistungs-CPU-Kern an, den Prozessor-IP der U8-Serie.
  • Esperanto ET-SoC-1, ein 200 TOPS "Kilocore" Supercomputer auf einem Chip, mit 1088 kleinen 64-Bit In-Order-ET-Minion-Kernen mit Tensor/Vektor-Einheiten und 4 großen 64-Bit Out-of-Order ET-Maxion Kerne

Open Source

Es gibt viele Open-Source-RISC-V-CPU-Designs, darunter:

  • Die Berkeley-CPUs. Diese sind in einer einzigartigen Hardware-Designsprache, Chisel , implementiert und einige sind nach berühmten Lokomotiven benannt:
    • 64-Bit-Rakete. Rocket eignet sich möglicherweise für kompakte Zwischencomputer mit geringem Stromverbrauch, wie z. B. für persönliche Geräte. Benannt nach Stephensons Rakete .
    • Die 64-Bit- Berkeley-Out-of-Order-Maschine (BOOM). Die Berkeley Out-of-Order Machine (BOOM) ist ein synthetisierbarer und parametrisierbarer Open Source RV64GC RISC-V-Kern, der in der Chisel-Hardware-Konstruktionssprache geschrieben wurde. BOOM verwendet einen Großteil der für Rocket erstellten Infrastruktur und kann für Personal-, Supercomputer- und Lagercomputer verwendet werden.
    • Fünf 32-Bit- Sodor-CPU-Designs von Berkeley, die für Studentenprojekte entwickelt wurden. Sodor ist die fiktive Insel der Züge in Kindergeschichten um Thomas the Tank Engine .
  • picorv32 von Claire Wolf, eine 32-Bit- Mikrocontroller-Einheit (MCU)-Klasse RV32IMC-Implementierung in Verilog .
  • scr1 von Syntacore, einer 32-Bit- Mikrocontroller-Einheit (MCU)-Klasse RV32IMC-Implementierung in Verilog .
  • PULPino (Riscy und Zero-Riscy) von der ETH Zürich / Universität Bologna. Die Kerne in PULPino implementieren eine einfache RV32IMC ISA für Mikrocontroller (Zero-Riscy) oder eine leistungsfähigere RV32IMFC ISA mit benutzerdefinierten DSP-Erweiterungen für die eingebettete Signalverarbeitung.
  • Western Digital kündigte im Dezember 2018 einen RV32IMC-Kern namens SweRV EH1 an, der ein 2-Wege-Superskalar in der Reihenfolge und ein neunstufiges Pipeline-Design aufweist. Im Dezember 2019 kündigte WD den SweRV EH2 als In-Order-Core mit zwei Hardware-Threads und einer neunstufigen Pipeline und den SweRV EL2 als Single Issue Core mit einer 4-stufigen Pipeline an. WD plant den Einsatz von SweRV-basierten Prozessoren in ihren Flash-Controllern und SSDs und veröffentlichte es im Januar 2019 als Open Source für Dritte.
  • NEORV32 von Stephan Nolting, eine hochkonfigurierbare 32-Bit- Mikrocontrollereinheit (MCU) der Klasse RV32[I/E]MACUX_Zbb_Zfinx_Zicsr_Zifencei CPU mit On-Chip-Debugger-Unterstützung, geschrieben in plattformunabhängigem VHDL . Das Projekt umfasst ein mikrocontrollerähnliches SoC, das bereits gängige Module wie UART, Timer, SPI, TWI, ein TRNG und eingebettete Speicher enthält.

Software

Ein normales Problem für einen neuen Befehlssatz ist zunächst ein Mangel an CPU-Designs und Software - beide Probleme schränken seine Verwendbarkeit ein und verringern die Akzeptanz. Obwohl dies 2016 ein Problem gewesen sein mag, wurde seitdem eine große Anzahl von CPU-Designs veröffentlicht und Software portiert oder verwendet. Die Software umfasst Toolchains, Betriebssysteme, Middleware und Designsoftware.

Zu den verfügbaren RISC-V-Softwaretools gehören eine GNU Compiler Collection (GCC)-Toolchain (mit GDB, dem Debugger), eine LLVM- Toolchain, der OVPsim- Simulator (und die Bibliothek von RISC-V Fast Processor Models), der Spike-Simulator und ein Simulator in QEMU (RV32GC/RV64GC).

Betriebssystemunterstützung existiert für den Linux- Kernel, FreeBSD und NetBSD , aber die Anweisungen für den Supervisor-Modus waren vor Juni 2019 nicht standardisiert, daher ist diese Unterstützung vorläufig. Die vorläufige FreeBSD-Portierung auf die RISC-V-Architektur wurde im Februar 2016 vorgeschaltet und in FreeBSD 11.0 ausgeliefert. Portierungen der Debian- und Fedora- Linux-Distributionen sowie eine Portierung von Haiku stabilisieren sich (beide unterstützen nur 64-Bit-RISC-V, ohne Pläne, die 32-Bit-Version zu unterstützen). Eine Portierung von Das U-Boot existiert. UEFI Spec v2.7 hat die RISC-V-Bindung definiert und eine TianoCore- Portierung wurde von HPE- Ingenieuren durchgeführt und soll vorgeschaltet werden. Es gibt eine vorläufige Portierung des seL4-Mikrokernels . Hex Five hat den ersten Secure IoT Stack für RISC-V mit FreeRTOS- Unterstützung veröffentlicht. Auch xv6 , eine moderne Neuimplementierung von Sixth Edition Unix in ANSI C, die für pädagogische Zwecke im MIT verwendet wird , wurde portiert. Pharos RTOS wurde auf 64-Bit-RISC-V portiert (einschließlich Zeit- und Speicherschutz). Siehe auch Vergleich von Echtzeit-Betriebssystemen .

Es existiert ein Simulator, um ein RISC-V-Linux-System in einem Webbrowser mit JavaScript auszuführen .

QEMU unterstützt den Betrieb (mit Binärübersetzung ) von 32- und 64-Bit-RISC-V-Systemen (zB Linux) mit einer Reihe von emulierten oder virtualisierten Geräten (seriell, parallel, USB, Netzwerk, Speicher, Echtzeituhr, Watchdog, Audio), sowie das Ausführen von RISC-V-Linux-Binärdateien (Übersetzen von Systemaufrufen in den Host-Kernel). Es unterstützt Multi-Core-Emulation (SMP).

Der CREATOR-Simulator ist portabel und ermöglicht das Erlernen verschiedener Assemblersprachen verschiedener Prozessoren (CREATOR hat Beispiele mit einer Implementierung von RISC-V- und MIPS32-Anweisungen).

Der erweiterbare Lernsimulator WepSIM implementiert eine (mikroprogrammierte) Untermenge von RISC-V-Befehlen (RV32IM) und ermöglicht die Ausführung von Unterprogrammen in der Assemblierung.

Bei der Erstellung von RISC-V-IP-Cores wurden eine Reihe von Sprachen angewendet, darunter eine Scala-basierte Hardwarebeschreibungssprache, Chisel , die die Designs auf Verilog für die Verwendung in Geräten reduzieren kann , und die CodAL-Prozessorbeschreibungssprache, die zur Beschreibung verwendet wurde RISC-V-Prozessorkerne und zur Generierung entsprechender HDKs (RTL, Testbench & UVM) und SDKs. Die RISC-V International Compliance Task Group verfügt über ein GitHub-Repository für RV32IMC.

Entwicklungswerkzeuge

  • IAR Systems hat die erste Version der IAR Embedded Workbench für RISC-V veröffentlicht, die in der ersten Version RV32 32-Bit RISC-V Cores und Erweiterungen unterstützt. Zukünftige Versionen werden 64-Bit-Unterstützung und Unterstützung für den kleineren RV32E-Basisbefehlssatz sowie Zertifizierungen für funktionale Sicherheit und Sicherheitslösungen umfassen.
  • Lauterbach hat seinen TRACE32 JTAG- Debuggern Unterstützung für RISC-V hinzugefügt . Lauterbach kündigte außerdem Unterstützung für SiFives RISC-V NEXUS- basiertes Prozessor-Trace an.
  • SEGGER hat seine Debug-Probe J-Link , seine integrierte Entwicklungsumgebung Embedded Studio und sein RTOS embOS und seine eingebettete Software um Unterstützung für RISC-V-Cores erweitert .
  • UltraSOC schlug ein Standard-Trace-System vor und spendete eine Implementierung.

Siehe auch

Verweise

Weiterlesen

Bibliotheksressourcen zu
RISC-V

Externe Links