Zusammenfassung

  • RISC-V International beschreibt ein Profil als Standard-Basis-ISA mit Pflicht-Erweiterungen und wenigen Standardoptionen: ein gemeinsames Vokabular für Hardware- und Softwareplattformen.
  • Die Begründung zu RVA23 stellt klar: Eine Ratifizierung betrifft die Spezifikation einer Erweiterung, falls sie vorhanden ist; sie garantiert keinen Merkmalsbestand in jeder Implementierung und bestimmt nicht den tatsächlich verwendeten Mindeststand eines Binärökosystems.
  • Ein Nachweis zu einer Profilbehauptung trennt den Status eines Dokuments, die Aussage über eine Implementierung und die in eingesetzten Geräten beobachtete Kompatibilität.

Ein Profil benennt eine gemeinsame Fläche

Die Einleitung zu RISC-V Profiles gibt dem Wort Profil eine eng gefasste Aufgabe. Es besteht aus einer Standard-Basis-ISA, verpflichtenden ISA-Erweiterungen und einer kleinen Menge Standardoptionen. Damit können Plattformbauer und die Betreuer gemeinsamer Toolchains kurz und überprüfbar benennen, welchen Teil der ISA sie gemeinsam tragen wollen. Portierbare Software soll nicht jede denkbare Kombination von Erweiterungen als gewöhnlichen Unterstützungsfall behandeln müssen.

Diese Kürze hat operativen Wert. Ein Hardwareanbieter kann sagen, auf welches Profil sein Entwurf zielt. Ein Compilerteam kann erklären, welche definierte Fläche regulären Support erhält. Eine Softwareautorin kann eine Kompatibilitätsaussage mit einem bestimmten Dokument und einer bestimmten Version verbinden. Das ist aussagekräftiger als ein allgemeines Etikett „RISC-V-kompatibel“.

Die gleiche Einleitung zieht jedoch eine Grenze gegen Überdehnung. Profile sollen weder Kombinationen einzelner Erweiterungen noch benutzerdefinierte Erweiterungen verbieten. Spezialisierte Konfigurationen können fortbestehen, ohne dass der Text ihnen breite Softwareunterstützung oder Portabilität zwischen Hardwareplattformen zusagt. Ein Profil ist daher weder ein abschließender Katalog zulässiger Entwürfe noch eine Anweisung an jede Implementierung. Es ist eine Koordinationssprache für eine abgegrenzte Unterstützungsfläche.

Ratifiziert heißt nicht überall eingebaut

Die RVA23-Begründung benennt den entscheidenden Vorbehalt. Der Ratifizierungsprozess für ISA-Erweiterungen sichert die Einigung der Prozessoranbieter auf die Spezifikation einer Standarderweiterung, wenn diese Erweiterung vorhanden ist. Die Spezifikationen einzelner Erweiterungen garantieren aber nicht, dass in allen Implementierungen derselbe Satz vorhanden ist.

Dieser Vorbehalt muss an jeder Produktaussage hängen bleiben. Ein Eintrag in der Bibliothek ratifizierter Spezifikationen belegt den öffentlichen Dokumentstatus, den RISC-V International darstellt. Er belegt nicht, dass ein konkreter Prozessor die Erweiterung enthält, eine Platine sie zugänglich macht, Firmware sie aktiviert, ein Compiler sie ansteuert oder ein Kunde sie eingesetzt hat. Das sind verschiedene Tatsachenbehauptungen verschiedener Akteure mit unterschiedlicher Evidenz.

Auch die Bibliothek selbst wahrt diese Trennung. Sie führt Profiles und RVA23 als ratifizierte Spezifikationen und nennt Versionen sowie Dokumentrollen. Das ist ein starker Beleg über das öffentliche Spezifikationsregister. Es ist kein Produktkatalog, kein Versandregister, kein Testbericht und keine Erhebung installierter Geräte. Wer es als eines davon liest, leiht ihm eine Autorität, die es nicht beansprucht.

Der betriebliche Mindeststand entsteht anderswo

Warum die Unterscheidung für Binärsoftwaremärkte wichtig ist, erläutert RVA23 ebenfalls. Profile sollen Prozessoranbieter so ausrichten, dass Software sich in einer Implementierungsgeneration auf einen Merkmalsbestand stützen kann. Zugleich könne RISC-V International nicht vorschreiben, welche ISA-Merkmale ein Binärökosystem verwenden solle. Ein Ökosystem wähle gewöhnlich den niedrigsten gemeinsamen Nenner, den es in den eingesetzten Geräten seines Zielmarkts empirisch beobachte.

Das ist kein Mangel des Profilmodells, sondern eine ehrliche Arbeitsteilung. Ein Profil kann die Unsicherheit der Abstimmung reduzieren, bevor eine breite Gerätepopulation sichtbar ist. Das Ökosystem muss dennoch aus real beobachtbaren Geräten, Werkzeugen und Nutzungsumgebungen entscheiden, was es gefahrlos verlangen kann. Die eine Ebene veröffentlicht Kompatibilitätsvokabular; die andere legt anhand von Einsatzbelegen einen Betriebsstandard fest.

Die in RVA23 beschriebenen lokalisierten, Entwicklungs-, Erweiterungs- und Übergangsoptionen verdeutlichen dieselbe Grenze. Sie signalisieren unterschiedliche Erwartungen an Erkennung, Kosten, Lebenszyklus oder künftige Richtung. Keine Dokumentkategorie macht daraus automatisch einen Nachweis, dass eine Funktion in einem bestimmten Gerät vorhanden ist.

Der Behauptung einen Nachweis geben

Es braucht kein neues Zertifizierungsprogramm. Nützlich ist ein kleiner Nachweis zu jeder öffentlichen Profil- oder Kompatibilitätsbehauptung. Er nennt das zitierte Profil und seine Version, die Basis-ISA, die relevanten Pflicht-Erweiterungen, gegebenenfalls die behauptete Option, den Behauptenden, den abgegrenzten Umfang von Hardware, Firmware, Werkzeug oder Software sowie das Datum.

Sagt ein Anbieter, eine Platine implementiere ein Profil, kann er Konfiguration und reproduzierbaren Test beilegen. Sagt ein Distributor, ein Image unterstütze ein Profil, kann er Image, Toolchain und getesteten Geräteraum benennen. Sagt ein Ökosystem, es ziele auf einen Mindeststand, kann es die beobachtete Population und das Überprüfungsdatum angeben. Was fehlt, bleibt leer: Der Name einer Spezifikation darf eine Lücke nicht durch Andeutung füllen.

So bleiben drei Sätze getrennt, die oft ineinandergeschoben werden: „Dieses Profil ist ratifiziert“; „diese Implementierung hat diese Merkmale“; „dieser Softwaremindeststand ist für diese eingesetzte Population sicher“. Alle drei können richtig sein, entstehen aber nicht im selben Akt und nicht aus demselben Beleg.

Eine Grenze, die Wahlfreiheit bewahrt

Heng Lus Notizen liefern hier nur die Methode, keine Tatsachenquelle zu RISC-V: Ein Koordinationsartefakt soll eine begrenzte gemeinsame Bedingung beschreiben und keine noch nicht angenommene Realität in Kraft sprechen. Die Profildokumente enthalten diese technische Zurückhaltung bereits. Sie geben gemeinsame Sprache, lassen aber Raum für kundenspezifische Konfigurationen, optionale Pfade und getrennt beobachtete Entscheidungen von Ökosystemen.

Der Nachweis schafft weder eine zentrale Freigabe noch einen neuen Torwächter. Er verlangt nur, dass die sprechende Partei Art und Reichweite ihrer Behauptung offenlegt. Damit wird ein Anbieter nicht als Versprecher eines universellen Mindeststands gelesen, ein Softwareteam verwechselt kein Dokument mit einer Geräteerhebung, und ein Käufer hält keinen Markensatz für eine getestete Einsatzbehauptung.

Portabilität gewinnt, wenn Behauptungen eng genug zum Testen und vergleichbar genug zum Prüfen sind. Der Wert eines Profils liegt darin, Vokabular zu sein. Er schwindet, wenn dieses Vokabular die Autorität eines Produktaudits, eines Einsatzberichts oder einer Marktanweisung ausleihen soll.

Quellen

  1. RISC-V Profiles v1.0 — Introduction
  2. RVA23 Profile v1.0 — Rationale
  3. RISC-V-Bibliothek ratifizierter Spezifikationen
  4. RISC-V ABIs Specification — Preamble
  5. Heng Lu — The Multi-Stakeholder Mirage
  6. Heng Lu — Running-Code Primacy
  7. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption