Der Sonntagsfrage (https://www.computerbase.de/2021-12...x86-wem-gehoert-die-zukunft-in-server-und-pc/) und die anschließende Diskussion brachte mich auf die Idee, diesen Leserartikel zu verfassen. Ich beschäftige mich schon länger mit RISC-V und Prozessorarchitekturen im Allgemeinen, daher hoffe ich auch Relevantes dazu sagen zu können.
Inhalt:
Ich habe mir nun nicht alles, was ich hier schreibe, einfach ausgedacht, der Artikel nimmt inhaltlich teilweise Bezug auf den Vortrag „Instructions Sets want to be free“ von RISC-V Miterfinder Prof. Krste Asanović. Die Slides zu dem Vortrag gibt es u.a hier https://riscv.org/wp-content/uploads/2017/05/Mon1045-Why-RISC-V-ISAs-Want-to-be-Free.pdf. Krste Asanović und auch David Patterson haben diesen Vortrag zu unzähligen Gelegenheiten gehalten, eines der qualitativ besseren Videos davon gibt es hier:
Wer halbwegs englisch kann, sollte sich das unbedingt ansehen.
Die ISA beschreibt die Maschinenbefehle und den „sichtbaren“ Zustand einer CPU bzw. eines CPU-Kerns. Mit sichtbarem Zustand sind die CPU-Register und Statusbits gemeint. Wenn die CPU Befehle ausführt, ändert sie dabei ständig diesen Zustand. Dieser Zustand wird auch „architectural state“ genannt, da er den Inhalt aller in der ISA definierten Register darstellt.
Die ISA ist damit nun das wesentliche Merkmal einer bestimmten CPU „Familie“ wie ARM, x86 oder eben RISC-V. In früheren Jahren (z.B. der Zeit des 8086 vs. 68000), als man noch viel direkt in Maschinenbefehlen programmiert hat, haben die Leute sich sehr intensiv über die Vor- und Nachteile einer bestimmten ISA gestritten.
Das hatte damals auch eine große Bedeutung, denn bei den damals recht einfach aufgebauten Prozessoren war die interne Architektur (die sogenannte Mikroarchitektur) sehr eng mit der ISA verbunden. Dass z.B. ein 8086 viel weniger ISA-CPU Register als ein 68000 hatte, machte sich direkt bemerkbar.
Grundsätzlich muss man ISA und Mikroarchitektur als getrennte Ebenen betrachten, die gleiche ISA kann man mit ganz verschiedenen Mikroarchitekturen implementieren. Und das wird natürlich auch gemacht, z.B. bei ARM, wo es ja etliche Cortex-Axx Kerne gibt.
Das Konzept, eine ISA in verschiedenen Implementierungen zu realisieren, ist übrigens uralt; IBM hat es in den frühen 60ern mit seiner IBM 360 Familie realisiert. Hierzu ein sehr sehenswerter Vortrag von David Patterson:
Über die Mikroarchitektur definieren sich auch die Unterschiede zwischen verschiedenen Prozessoren der gleichen ISA. Aktuelle Anwendungsprozessoren, wie Intel Core oder AMD Ryzen haben sehr aufwändige „Multi Issue – Out of Order“ Mikroarchitekturen.
D.h. sie können mehrere Befehle parallel ausführen (Multi Issue) und sie dabei auch umsortieren (Out of Order) um die Menge an Befehlen pro Takt (IPC – Instructions per Clock) zu optimieren. Aktuelle CPUs können dabei mehrere hundert Befehle „in-flight“ haben. Das Tückische dabei ist, dass aus Sicht der ISA die Illusion aufrechterhalten werden muss, dass die Befehle alle schön einer nach dem anderen ausgeführt werden, und sich das entsprechend auch in Änderungen des Architectural state so darstellen muss. Die ISA ist also eine Abstraktionsebene, die sicherstellt, dass sich Software in der Regel nicht um die Details der Mikroarchitektur kümmern muss.
Wie eben schon ausgeführt, ist sie der Punkt wo „Software auf Hardware“ trifft. Die CPU kann nichts anderes, als Maschinenbefehle gemäß ihrer ISA auszuführen, daher muss jeder ausführbare Code in dieser Form vorliegen. Die ISA ist der Fixpunkt, auf den sich Software- und Hardwareentwickler verlassen müssen. Auf der Softwareseite kann man jede beliebige Programmiersprache erfinden, solange man einen Compiler hat, der am Schluss Code in der ISA erzeugt. Die Hardwareentwickler ihrerseits dürfen sich auch ausdenken, was sie wollen und was sie irgendwie in einen Chip gegossen bekommen, solange dieser die ISA Befehle ausführt, ist alles in Ordnung. Die ISA ermöglicht letztendlich, dass Software und Hardware unabhängig voneinander weiterentwickelt werden können.
Nun wird heutzutage gerne argumentiert, dass ja sowieso alle Software in Hochsprachen geschrieben wird, man sie einfach nur neu kompilieren muss und daher der Wechsel der ISA ja nicht so schwer ist. Das stimmt zwar, greift aber zu kurz:
Wenn man sich die IT-Welt ansieht, haben sich an verschiedenen sehr zentralen Stellen offene, herstellerunabhängige Standards durchgesetzt. Ein prominentes Beispiel ist die Internet-Protokollfamilie, also TCP/IP, und alles darum herum. Alles was er früher mal gab, wie NetBIOS, OSI, X.25, ist ausgestorben. Das gleiche gilt für den Layer-2, da hat Ethernet so Dinge wie Token Ring, ATM, usw. verdrängt.
Der Grund dafür ist ganz einfach: Weil die Standards von jedem implementiert werden können, gibt es keinen Grund mehr, verschiedene Standards parallel zu verwenden. Wichtig ist hier der Unterschied, zwischen freiem Standard und freier Implementierung. Natürlich gibt es proprietäre TCP/IP Stacks, aber der Standard selbst ist frei.
Nun ist die ISA ja, wie eben ausgeführt, auch eine zentrale Schnittstelle eines jeden Computersystems, und genau hier gab es lange keinen freien Standard. Die dominanten ISAs am Markt sind Eigentum ihrer Hersteller, und selbst in akademischen Projekten bekommt man schnell Probleme mit deren Patentanwälten.
Ein weiteres Problem der etablierten ISAs ist der historische Ballast, den sie mit sich führen. Das gilt für x86 genauso wie für ARM. Zusammen mit teilweise nicht öffentlichen Spezifikationen ist es dadurch kaum möglich, einen zu diesen ISA kompatiblen Prozessor zu bauen, unabhängig von der rechtlichen Frage. Schon allein dadurch gibt es bei Prozessoren nur ein kleines Oligopol. Die Alternative, für ein experimentelles Design wieder eine eigene ISA zu entwerfen, zieht einen Rattenschwanz an Folgen nach sich. Um einen Linux Kernel zu booten, muss man den C-Compiler (GCC), anpassen, die glibc und eben den Kernel selbst, alles keine Aufgaben, die trivial sind.
Hier kommt nun RISC-V ins Spiel. RISC-V definiert eine modulare, offen verwendbare ISA. Modular bedeutet, dass sie aus einem sehr kleinen Basis-Befehlssatz (RV32I) besteht, der um verschiedene Elemente (z.B. Floating-Point, Bit-Operationen, usw.) erweitert werden kann. Außerdem gibt es die ISA in 32- und in 64-Bit (und zukünftig auch 128-Bit).
Mit den heutzutage zur Verfügung stehenden Tools kann ein einfacher RISC-V Prozessor, der die „Basisspezifikation“ RV32I implementiert, von einem mittelmäßig begabten Computerarchitektur-Studenten im Rahmen einer Hausarbeit entwickelt werden. RV32I reicht zwar noch nicht, um Linux zu booten, aber für „Bare Metal“ C-Programme genügt es. Enorm hilfreich ist, dass es ein komplettes Toolset dafür gibt:
Durch dieses Toolset spart man mit RISC-V gegenüber einer „Eigenbau“ ISA enorm Zeit. Der modulare Aufbau der ISA stellt sicher, dass auch eine Simpel-CPU mit RV32I noch konform zur Spezifikation ist, und dass der GCC out-of-the-box darauf lauffähigen Code erzeugt. Man gibt einfach in der Aufrufzeile des Compilers den entsprechenden Level an (also in unserem Beispiel march=rv32i), dann wird der entsprechende Code erzeugt und auch die passende Library gelinkt.
Reicht es einem nicht, die CPU im Simulator auszuprobieren, braucht man keinen Zugriff auf eine Chipfabrik, sondern ein üblicher low-cost FPGA reicht schon, um so einen CPU in Hardware auszuprobieren. Also ungefähr das, was unzählige Mikrocontroller mit ARM Cortex-M auch tun. So ein einfacher RISC-V Prozessor entspricht dann etwa einem Cortex-M0.
Natürlich erreichen professionellere Teams mit mehr Knowhow und Ressourcen sehr viel mehr. Die offizielle Liste an RISC-V Designs https://riscv.org/exchange/cores-socs/ wird kontinuierlich länger.
Vermutlich gibt es bald für RISC-V allein mehr Designs als für alle anderen ISAs zusammen. Natürlich gibt es noch keine CPU auf dem Level eines aktuellen Performance Kerns für ARM oder X86, aber SiFive ist nicht mehr weit davon entfernt (https://www.sifive.com/cores/performance-p650)
Mit RISC-V stehen wir am Anfang einer Demokratisierung des Prozessordesigns. Das heute bestehende Oligopol an Prozessor Herstellern (bzw. im Falle von ARM–Designern) sorgt auch dafür, dass es weltweit nur relativ wenige Experten gibt, die sich mit CPU-Design auskennen. Denn Jobs gibt es ja nur bei diesen paar Firmen. Man sieht auch, dass die wenigen Experten gerne mal von einem Player zum anderen wechseln. Dabei ist CPU-Design keine Raketen-Wissenschaft; fast alle wichtigen Konzepte sind seit langem bekannt und liegen auch öffentlich vor (z.B. der Tomasulo-Algorithmus (https://de.wikipedia.org/wiki/Tomasulo-Algorithmus für das Scheduling von Instruktionen).
Es ist klar, dass man nicht durch das Lesen von ein paar Wikipedia-Artikeln einen M1-Konkurrenten in der Garage basteln kann, aber wir haben schon einmal erlebt, wie das Hobby-Projekt eines finnischen Informatik Studenten nahezu alle kommerziellen UNIX-Derivate langsam, aber sicher aus dem Markt gedrängt hat. Abgesehen von Mikrocontrollern ohne MMU und der Windows- bzw. Apple-Welt hat der Linux-Kernel heute nahezu 100% Marktdurchdringung.
Das ist eine Frage, die nicht leicht zu beantworten ist (und deren Antwort ich mir auch nicht wirklich zutraue).
Die RISC-V Initiatoren sagen, mit einem gewissen Augenzwinkern, dass sie nichts Geringeres als die Weltherrschaft anstreben. Sie argumentieren dabei mit der Idee des offenen Standards: Langfristig gibt es für die meisten Marktteilnehmer keine Motivation mehr, auf einen proprietären Standard zu setzen, wenn es einen offenen Standard mit einer freien Auswahl an qualitativ hochwertigen Implementierungen gibt.
RISC-V „frisst“ sich mittlerweile langsam durch das Ecosystem: Zuerst löst es die unzähligen Inhouse Microcontroller ab, die in alle möglichen Chips (z.B. USB-SATA Bridges, usw.) stecken. Hier sind immer noch archaische 8-Bit Designs wie 8051 üblich, da diese lizenzfrei verfügbar sind. Dadurch, dass man RISC-V Cores, im Gegensatz zu ARM, beliebig anpassen und modifizieren darf, kann man auch spezielle Anforderungen damit erfüllen. So hat z.B. Western Digital einen Open Source RISC-V Core entwickelt: (https://github.com/chipsalliance/Cores-SweRV-EH2), den sie in Storage Controllern einsetzen wollen.
Drive bekommt RISC-V von Russland, China und Indien, spätestens seit dem Huawei-Bann ist chinesischen Tech-Firmen sehr klar geworden, dass sie nicht von den USA abhängig sein wollen. Ich denke, das erste Endkunden Produkt, das einen RISC-V Kern als Anwendungsprozessor einsetzen wird, wird daher in China entstehen. Erste vielversprechende CPU-Designs aus China gibt es schon. Alibaba macht es auch hier Amazon nach, und investiert in CPU-Entwicklung, aber eben RISC-V anstatt ARM. Ob das für uns in Europa eine bessere Alternative als die heutigen US-Produkte sein wird, kann man natürlich lange diskutieren.
Für einen RISC-V Desktop und Smartphone fehlen zurzeit noch ein paar wichtige Dinge (unter anderem eben ausgereifte JIT-Engines speziell für Javascript), aber an all diesen Dingen wird gearbeitet.
Aber klar, ich bin einerseits überzeugt, dass RISC-V gekommen ist, um zu bleiben, aber in welchen Marktsegmenten es sich etablieren wird, und in welchem Zeitraum, kann man ganz schwer sagen.
P.S.: Es ist mein erster Leserartikel bei CB, ich hoffe Ihr findet ihn interessant. Ich freue mich über jedes Feedback, auch bzgl. Schreibfehlern und falsch gesetzte Kommas
Ich hoffe es sind nicht viele Fehler übrig geblieben, ich bin nicht sehr gut im Korrekturlesen meiner eigenen Texte...
Inhalt:
- Einleitung
- Was ist eine Instruction Set Architecture (ISA)?
- ISA vs. Mikroarchitektur
- Warum hat die ISA eine so zentrale Bedeutung?
- Warum eine freie ISA?
- Was bringt das?
- Wann gibt es ein Smartphone oder gar einen PC mit RISC-V?
Einleitung
Ich habe mir nun nicht alles, was ich hier schreibe, einfach ausgedacht, der Artikel nimmt inhaltlich teilweise Bezug auf den Vortrag „Instructions Sets want to be free“ von RISC-V Miterfinder Prof. Krste Asanović. Die Slides zu dem Vortrag gibt es u.a hier https://riscv.org/wp-content/uploads/2017/05/Mon1045-Why-RISC-V-ISAs-Want-to-be-Free.pdf. Krste Asanović und auch David Patterson haben diesen Vortrag zu unzähligen Gelegenheiten gehalten, eines der qualitativ besseren Videos davon gibt es hier:
Was ist eine Instruction Set Architecture (ISA)?
Die ISA beschreibt die Maschinenbefehle und den „sichtbaren“ Zustand einer CPU bzw. eines CPU-Kerns. Mit sichtbarem Zustand sind die CPU-Register und Statusbits gemeint. Wenn die CPU Befehle ausführt, ändert sie dabei ständig diesen Zustand. Dieser Zustand wird auch „architectural state“ genannt, da er den Inhalt aller in der ISA definierten Register darstellt.
Die ISA ist damit nun das wesentliche Merkmal einer bestimmten CPU „Familie“ wie ARM, x86 oder eben RISC-V. In früheren Jahren (z.B. der Zeit des 8086 vs. 68000), als man noch viel direkt in Maschinenbefehlen programmiert hat, haben die Leute sich sehr intensiv über die Vor- und Nachteile einer bestimmten ISA gestritten.
Das hatte damals auch eine große Bedeutung, denn bei den damals recht einfach aufgebauten Prozessoren war die interne Architektur (die sogenannte Mikroarchitektur) sehr eng mit der ISA verbunden. Dass z.B. ein 8086 viel weniger ISA-CPU Register als ein 68000 hatte, machte sich direkt bemerkbar.
ISA vs. Mikroarchitektur
Grundsätzlich muss man ISA und Mikroarchitektur als getrennte Ebenen betrachten, die gleiche ISA kann man mit ganz verschiedenen Mikroarchitekturen implementieren. Und das wird natürlich auch gemacht, z.B. bei ARM, wo es ja etliche Cortex-Axx Kerne gibt.
Das Konzept, eine ISA in verschiedenen Implementierungen zu realisieren, ist übrigens uralt; IBM hat es in den frühen 60ern mit seiner IBM 360 Familie realisiert. Hierzu ein sehr sehenswerter Vortrag von David Patterson:
Über die Mikroarchitektur definieren sich auch die Unterschiede zwischen verschiedenen Prozessoren der gleichen ISA. Aktuelle Anwendungsprozessoren, wie Intel Core oder AMD Ryzen haben sehr aufwändige „Multi Issue – Out of Order“ Mikroarchitekturen.
D.h. sie können mehrere Befehle parallel ausführen (Multi Issue) und sie dabei auch umsortieren (Out of Order) um die Menge an Befehlen pro Takt (IPC – Instructions per Clock) zu optimieren. Aktuelle CPUs können dabei mehrere hundert Befehle „in-flight“ haben. Das Tückische dabei ist, dass aus Sicht der ISA die Illusion aufrechterhalten werden muss, dass die Befehle alle schön einer nach dem anderen ausgeführt werden, und sich das entsprechend auch in Änderungen des Architectural state so darstellen muss. Die ISA ist also eine Abstraktionsebene, die sicherstellt, dass sich Software in der Regel nicht um die Details der Mikroarchitektur kümmern muss.
Warum hat die ISA eine so zentrale Bedeutung?
Wie eben schon ausgeführt, ist sie der Punkt wo „Software auf Hardware“ trifft. Die CPU kann nichts anderes, als Maschinenbefehle gemäß ihrer ISA auszuführen, daher muss jeder ausführbare Code in dieser Form vorliegen. Die ISA ist der Fixpunkt, auf den sich Software- und Hardwareentwickler verlassen müssen. Auf der Softwareseite kann man jede beliebige Programmiersprache erfinden, solange man einen Compiler hat, der am Schluss Code in der ISA erzeugt. Die Hardwareentwickler ihrerseits dürfen sich auch ausdenken, was sie wollen und was sie irgendwie in einen Chip gegossen bekommen, solange dieser die ISA Befehle ausführt, ist alles in Ordnung. Die ISA ermöglicht letztendlich, dass Software und Hardware unabhängig voneinander weiterentwickelt werden können.
Nun wird heutzutage gerne argumentiert, dass ja sowieso alle Software in Hochsprachen geschrieben wird, man sie einfach nur neu kompilieren muss und daher der Wechsel der ISA ja nicht so schwer ist. Das stimmt zwar, greift aber zu kurz:
- Software wird meistens in Binärform ausgeliefert, nicht nur bei Windows. Es macht auch unter Linux, selbst für technisch bewanderte Nutzer, einen riesigen Unterschied, ob das neue Paket nur ein „sudo apt-get install xyz“ entfernt ist oder man sich durch 10 Seiten Readme Files mit kryptischen Build-Anweisungen wühlen muss.
- Der Anteil der Software, der abhängig von der ISA ist (neben Compilern, auch „JIT“-Engines für Javascript, Java, C#), ist zwar klein, aber wichtig für ein Ecosystem. Ohne z.B. eine Javascript-JIT Engine ist eine Plattform für Desktop und Smartphone faktisch unbrauchbar
- Auch die Betriebssysteme selbst sind von der ISA abhängig. Auch hier ist der Anteil an direktem Assembler Codes zwar winzig, aber erhebliche Teile des Kernelcodes hängen von Datenstrukturen im Prozessor (Pagetables, Interruptvektoren, CSR-Register) ab.
Warum eine freie ISA?
Wenn man sich die IT-Welt ansieht, haben sich an verschiedenen sehr zentralen Stellen offene, herstellerunabhängige Standards durchgesetzt. Ein prominentes Beispiel ist die Internet-Protokollfamilie, also TCP/IP, und alles darum herum. Alles was er früher mal gab, wie NetBIOS, OSI, X.25, ist ausgestorben. Das gleiche gilt für den Layer-2, da hat Ethernet so Dinge wie Token Ring, ATM, usw. verdrängt.
Der Grund dafür ist ganz einfach: Weil die Standards von jedem implementiert werden können, gibt es keinen Grund mehr, verschiedene Standards parallel zu verwenden. Wichtig ist hier der Unterschied, zwischen freiem Standard und freier Implementierung. Natürlich gibt es proprietäre TCP/IP Stacks, aber der Standard selbst ist frei.
Nun ist die ISA ja, wie eben ausgeführt, auch eine zentrale Schnittstelle eines jeden Computersystems, und genau hier gab es lange keinen freien Standard. Die dominanten ISAs am Markt sind Eigentum ihrer Hersteller, und selbst in akademischen Projekten bekommt man schnell Probleme mit deren Patentanwälten.
Ein weiteres Problem der etablierten ISAs ist der historische Ballast, den sie mit sich führen. Das gilt für x86 genauso wie für ARM. Zusammen mit teilweise nicht öffentlichen Spezifikationen ist es dadurch kaum möglich, einen zu diesen ISA kompatiblen Prozessor zu bauen, unabhängig von der rechtlichen Frage. Schon allein dadurch gibt es bei Prozessoren nur ein kleines Oligopol. Die Alternative, für ein experimentelles Design wieder eine eigene ISA zu entwerfen, zieht einen Rattenschwanz an Folgen nach sich. Um einen Linux Kernel zu booten, muss man den C-Compiler (GCC), anpassen, die glibc und eben den Kernel selbst, alles keine Aufgaben, die trivial sind.
Hier kommt nun RISC-V ins Spiel. RISC-V definiert eine modulare, offen verwendbare ISA. Modular bedeutet, dass sie aus einem sehr kleinen Basis-Befehlssatz (RV32I) besteht, der um verschiedene Elemente (z.B. Floating-Point, Bit-Operationen, usw.) erweitert werden kann. Außerdem gibt es die ISA in 32- und in 64-Bit (und zukünftig auch 128-Bit).
Mit den heutzutage zur Verfügung stehenden Tools kann ein einfacher RISC-V Prozessor, der die „Basisspezifikation“ RV32I implementiert, von einem mittelmäßig begabten Computerarchitektur-Studenten im Rahmen einer Hausarbeit entwickelt werden. RV32I reicht zwar noch nicht, um Linux zu booten, aber für „Bare Metal“ C-Programme genügt es. Enorm hilfreich ist, dass es ein komplettes Toolset dafür gibt:
- Die GNU Compiler Collection inkl. Tools wie dem gdb (Debugger)
- Glibc und newlib als Runtime Libraries
- Den Linux Kernel nebst angepassten Userland
- Eine Verifikation Suite, mit der man einen Prozessor bzw. dessen Simulation auf Einhaltung der Spezifikation prüfen kann
- Einen ISA Simulator, der das „golden Model“ der ISA darstellt, gegen das man prüfen kann.
Durch dieses Toolset spart man mit RISC-V gegenüber einer „Eigenbau“ ISA enorm Zeit. Der modulare Aufbau der ISA stellt sicher, dass auch eine Simpel-CPU mit RV32I noch konform zur Spezifikation ist, und dass der GCC out-of-the-box darauf lauffähigen Code erzeugt. Man gibt einfach in der Aufrufzeile des Compilers den entsprechenden Level an (also in unserem Beispiel march=rv32i), dann wird der entsprechende Code erzeugt und auch die passende Library gelinkt.
Was bringt das?
Reicht es einem nicht, die CPU im Simulator auszuprobieren, braucht man keinen Zugriff auf eine Chipfabrik, sondern ein üblicher low-cost FPGA reicht schon, um so einen CPU in Hardware auszuprobieren. Also ungefähr das, was unzählige Mikrocontroller mit ARM Cortex-M auch tun. So ein einfacher RISC-V Prozessor entspricht dann etwa einem Cortex-M0.
Natürlich erreichen professionellere Teams mit mehr Knowhow und Ressourcen sehr viel mehr. Die offizielle Liste an RISC-V Designs https://riscv.org/exchange/cores-socs/ wird kontinuierlich länger.
Vermutlich gibt es bald für RISC-V allein mehr Designs als für alle anderen ISAs zusammen. Natürlich gibt es noch keine CPU auf dem Level eines aktuellen Performance Kerns für ARM oder X86, aber SiFive ist nicht mehr weit davon entfernt (https://www.sifive.com/cores/performance-p650)
Mit RISC-V stehen wir am Anfang einer Demokratisierung des Prozessordesigns. Das heute bestehende Oligopol an Prozessor Herstellern (bzw. im Falle von ARM–Designern) sorgt auch dafür, dass es weltweit nur relativ wenige Experten gibt, die sich mit CPU-Design auskennen. Denn Jobs gibt es ja nur bei diesen paar Firmen. Man sieht auch, dass die wenigen Experten gerne mal von einem Player zum anderen wechseln. Dabei ist CPU-Design keine Raketen-Wissenschaft; fast alle wichtigen Konzepte sind seit langem bekannt und liegen auch öffentlich vor (z.B. der Tomasulo-Algorithmus (https://de.wikipedia.org/wiki/Tomasulo-Algorithmus für das Scheduling von Instruktionen).
Es ist klar, dass man nicht durch das Lesen von ein paar Wikipedia-Artikeln einen M1-Konkurrenten in der Garage basteln kann, aber wir haben schon einmal erlebt, wie das Hobby-Projekt eines finnischen Informatik Studenten nahezu alle kommerziellen UNIX-Derivate langsam, aber sicher aus dem Markt gedrängt hat. Abgesehen von Mikrocontrollern ohne MMU und der Windows- bzw. Apple-Welt hat der Linux-Kernel heute nahezu 100% Marktdurchdringung.
Wann gibt es ein Smartphone oder gar einen PC mit RISC-V?
Das ist eine Frage, die nicht leicht zu beantworten ist (und deren Antwort ich mir auch nicht wirklich zutraue).
Die RISC-V Initiatoren sagen, mit einem gewissen Augenzwinkern, dass sie nichts Geringeres als die Weltherrschaft anstreben. Sie argumentieren dabei mit der Idee des offenen Standards: Langfristig gibt es für die meisten Marktteilnehmer keine Motivation mehr, auf einen proprietären Standard zu setzen, wenn es einen offenen Standard mit einer freien Auswahl an qualitativ hochwertigen Implementierungen gibt.
RISC-V „frisst“ sich mittlerweile langsam durch das Ecosystem: Zuerst löst es die unzähligen Inhouse Microcontroller ab, die in alle möglichen Chips (z.B. USB-SATA Bridges, usw.) stecken. Hier sind immer noch archaische 8-Bit Designs wie 8051 üblich, da diese lizenzfrei verfügbar sind. Dadurch, dass man RISC-V Cores, im Gegensatz zu ARM, beliebig anpassen und modifizieren darf, kann man auch spezielle Anforderungen damit erfüllen. So hat z.B. Western Digital einen Open Source RISC-V Core entwickelt: (https://github.com/chipsalliance/Cores-SweRV-EH2), den sie in Storage Controllern einsetzen wollen.
Drive bekommt RISC-V von Russland, China und Indien, spätestens seit dem Huawei-Bann ist chinesischen Tech-Firmen sehr klar geworden, dass sie nicht von den USA abhängig sein wollen. Ich denke, das erste Endkunden Produkt, das einen RISC-V Kern als Anwendungsprozessor einsetzen wird, wird daher in China entstehen. Erste vielversprechende CPU-Designs aus China gibt es schon. Alibaba macht es auch hier Amazon nach, und investiert in CPU-Entwicklung, aber eben RISC-V anstatt ARM. Ob das für uns in Europa eine bessere Alternative als die heutigen US-Produkte sein wird, kann man natürlich lange diskutieren.
Für einen RISC-V Desktop und Smartphone fehlen zurzeit noch ein paar wichtige Dinge (unter anderem eben ausgereifte JIT-Engines speziell für Javascript), aber an all diesen Dingen wird gearbeitet.
Aber klar, ich bin einerseits überzeugt, dass RISC-V gekommen ist, um zu bleiben, aber in welchen Marktsegmenten es sich etablieren wird, und in welchem Zeitraum, kann man ganz schwer sagen.
P.S.: Es ist mein erster Leserartikel bei CB, ich hoffe Ihr findet ihn interessant. Ich freue mich über jedes Feedback, auch bzgl. Schreibfehlern und falsch gesetzte Kommas
Ich hoffe es sind nicht viele Fehler übrig geblieben, ich bin nicht sehr gut im Korrekturlesen meiner eigenen Texte...
Zuletzt bearbeitet:
. Das nimmt sich also nicht viel, zu RISC-V.
.
