Gast
#7309126
Schau mal hier:
https://www.espressif.com/en/news/ESP32-P4
So langsam merkt man das ARM bald in Schwitzen kommen wird. :)
Olaf
Gast
#7309141
So langsam merkt man das ARM bald in Schwitzen kommen wird. :)
Und morgen, liebe Kinder, erzählt euch Olaf einen neues Märchen.
Gast
#7309173
Ich erwähne jetzt mal nicht, daß schon der 6502 ein RISC-Prozessor war.
Gut, dass du es nicht erwähnt hast.
Gast
#7309179
Ich erwähne jetzt mal nicht, daß schon der 6502 ein RISC-Prozessor war.
Das "in Schwung" bezieht sich bestimmt auf die Taktfrequenz. Der 6502 war da doch noch etwas bescheidener ;-)
Da finde ich die Ankündigung, dass Android offiziell Risc-V unterstützen wird interessanter.
Ansonsten wird das der Preis regeln. ARM kostet royalties, Risc-V nicht. Damit sind Chips billiger. Ergo fehlt nur noch eine stabile Entwicklungsumgebung... De-facto gibt's die - muss für die Industrie wahrscheinlich nur noch etwas besser "abhängen".
Gigadevice hat mit den 32F103/32vf103 imho den schlaueren Schritt getätigt... Zuerst portiert man mit überschaubarm Aufwand auf die GD32 peripherals, wenn das läuft tauscht man noch den Compiler und spart sich noch ein paar Cent.
73
Schau mal hier:
Ich hätte ja gern meinen Router/Firewall durch einen mit RISC-V ersetzt. Leider sind die einzigen Boards (der benötigten Größenordnung, sollte mindestens SATA oder nVME haben), auf denen FreeBSD brauchbar läuft, entweder schon lange vergriffen oder anderweitig nicht lieferbar. Die Chipkrise macht halt auch vor RISC-V nicht halt.
Die beste Werbung für RISC-V kommt ja imho von ARM selbst:
https://www.heise.de/news/ARM-verklagt-Qualcomm-wegen-Lizenz-und-Markenrechtsverletzung-7249968.html
Qualcomm hat bereits angekündigt, zukünftig auch RISC-V zu unterstützen:
https://www.fierceelectronics.com/electronics/qualcomm-invests-sifive-for-risc-v-architecture
Die grossen Hersteller sind längst im Boot, und es ist imho nur eine Frage der Zeit, bis RISC-V zu einem ernsthaften Mitbewerber für ARM gewachsen ist.
Das erinnert mich ein Wenig an die Frühzeit von Linux, als das mit Solaris, AIX, Irix, SCO usw. vergleichen wurde - wie das ausgegangen ist wissen wir ja inzwischen.
Klar steckt das derzeit noch in den Kinderschuhen, aber, warten wir mal ab! Es wird sicher nicht schaden, sich bereits jetzt intensiver mit dem Thema zu beschäftigen.
Die beste Werbung für RISC-V kommt ja imho von ARM selbst:
Mein Eindruck ist auch, dass ARM langfristig die Felle davon schwimmen sieht, und daher kurzfristig alles rausholen will, was die Anwälte hergeben. Dabei in Kauf nehmend, den Prozess des Wegekelns zu beschleunigen.
Die Übernahme- und Verkaufsversuche bzgl ARM gehen in die gleiche Richtung: Einen Plan B vorbereiten, bevor mein Konkurrent mir den Hals abdreht, indem er ARM kauft. Kartellbedenken haben das zwar verhindert, aber darauf ist kein Verlass. ARM setzte sich vielfach gerade deshalb durch, weil alle die gleiche Chance hatten.
Aufgrund der bekannten politisch inspirierten Lieferkettenprobleme sind die Chinesen geradezu gezwungen, das Weite zu suchen.
Google wiederum liefe in Gefahr, die Kontrolle über Android zu verlieren, wenn sie RISC/V ignorierten. Analog Oracle und die Flucht der Nutzer zu LibreOffice/MariaDB statt OpenOffice/MySQL.
Die grossen Hersteller sind längst im Boot, und es ist imho nur eine Frage der Zeit, bis RISC-V zu einem ernsthaften Mitbewerber für ARM gewachsen ist.
Wer Highend-Cores für ARMv8 bauen kann, ohne rein von der Technik der Implementierung her auf kostenpflichtige IP von ARM zurückzugreifen zu müssen, der kann das auch bei RISC/V. So immens verschieden sind die nicht. Qualcomm hat da bereits Erfahrung.
In Controller-Cores ist es jenseits von SIMD-Code nur dort ein Problem, wo man Peripherie aus dem ARM-Zoo einsetzt. Stammt die Peripherie aus dem eigenen Stall oder aus dritten Quellen, kann der Core ersetzt werden, ohne dass sich für die Kunden viel mehr ändert als die Compiler-Lizenz und der Umgang mit dem Interrupt-Controller. So arg viel C/C++-Code ist es nicht, der direkt vom Core abhängt.
Hier noch ein interessanter Vortrag zu dem Thema: https://www.youtube.com/watch?v=L9jvLsvkmdM
Gast
#7314201
Wenn die Architektur nur nicht so schrottig wäre…
Manchmal frage ich mich beim Betrachten von Prozessorarchitekturen, was eigentlich mit den Leuten schief gegangen ist, die den Kram verbrochen haben. Wie kommt man auf die dämliche Idee einen Prozessor ohne ALU-Flags zu bauen?
Oder wie bei Cypress die älteren Varianten der M8-Prozessoren, die nicht selber den MSB vom Programcounter am Ende einer 256-Byte Page inkrementieren konnten. Da hat man natürlich echt was gespart m(
Wie kommt man auf die dämliche Idee einen Prozessor ohne ALU-Flags zu bauen?
Man könnte das umgekehrt formulieren: Wer heute eine neue Befehlssatzarchitektur definiert, die sich auch für den Einsatz jenseits einfacher Mikrocontroller eignen soll, und dennoch solche Flags einbaut, der hat die letzten Jahrzehnte Entwicklung zu diesem Thema ignoriert.
Solche Flags sorgen für oft unnötige Abhängigkeiten von Befehlen untereinander und erhöhen den Aufwand erheblich, sobald mehr als ein Befehl pro Takt ausgeführt werden soll. Sie stellen eine zentrale einzelne Ressource dar, und das ist ein Problem.
Wie kommt man auf die dämliche Idee einen Prozessor ohne ALU-Flags zu bauen?
Wie bereits geschrieben - bei superskalaren Prozessoren verursacht das Flags Register deutlichen Mehraufwand.
Dazu kommt, dass wir nicht mehr mit 8 Bit Prozessoren arbeiten. Wenn man seine 16 oder 32 Bit Rechenoperationen aus 8 Bit Teilen zusammensetzen muss, dann sieht man eine intensive Verwendung der Flags. Bei einem 64 Bit Prozessor wird man sie in normalen Rechenoperationen kaum benötigen.
Sprungbefehle kann man hingegen ohne Flags besser implementieren. Ein "alter" Prozessor benötigt ein Compare und Conditional Jump. "Moderne" RISC Prozessoren arbeiten hier gerne mit einem "Compare and Jump" - also nur ein Befehl statt zwei und keine Abhängigkeiten mit einem Register das sich die verschiedenen Ausführungseinheiten teilen müssen.
Es ist immer etwas problematisch, wenn man den Fachleuten mal eben so Unfähigkeit unterstellt. Das betrifft nicht nur RISC V, sondern auch DEC Alpha oder MIPS. Ich würde lieber etwas länger darüber nachdenken, ob es nicht vielleicht doch einen guten Grund für die Vorgehensweise gibt.
Gast
#7315341
Solche Flags sorgen für oft unnötige Abhängigkeiten von Befehlen untereinander und erhöhen den Aufwand erheblich, sobald mehr als ein Befehl pro Takt ausgeführt werden soll. Sie stellen eine zentrale einzelne Ressource dar, und das ist ein Problem.
Diese Flags nicht zu haben führt zu einem Mehraufwand, der alle Performancegewinne mindestens kompensiert.
Die logische Lösung wäre es die Flags pro Register zu haben. Alles andere ist einfach Unsinn.
Diese Flags nicht zu haben führt zu einem Mehraufwand, der alle Performancegewinne mindestens kompensiert.
RISC/V: "The conditional branches were designed to include arithmetic comparison operations between two registers (as also done in PA-RISC and Xtensa ISA), rather than use condition codes (x86, ARM, SPARC, PowerPC), or to only compare one register against zero (Alpha, MIPS), or two registers only for equality (MIPS). This design was motivated by the observation that a combined compare-and-branch instruction fits into a regular pipeline, avoids additional condition code state or use of a temporary register, and reduces static code size and dynamic instruction fetch traffic. [...] Another advantage of a fused compare-and-branch instruction is that branches are observed earlier in the front-end instruction stream, and so can be predicted earlier. There is perhaps an advantage to a design with condition codes in the case where multiple branches can be taken based on the same condition codes, but we believe this case to be relatively rare."
The RISC-V Instruction Set Manual, Volume I: User-Level ISA, Version 2.1
Beitrag #7315388 wurde von einem Moderator gelöscht.
Beitrag #7315401 wurde von einem Moderator gelöscht.
Beitrag #7315407 wurde von einem Moderator gelöscht.
Gast
#7315412
Wenn das so bedeutend und revolutionär wäre, warum wird nicht seit Jahrzehnten nur noch MIPS benutzt?
Beitrag #7315422 wurde von einem Moderator gelöscht.
Wenn das so bedeutend und revolutionär wäre, warum wird nicht seit Jahrzehnten nur noch MIPS benutzt?
Weil der Zusammenhang zwischen technischen Eigenschaften und wirtschaftlichem Erfolg in vielen Branchen recht locker ist. Wichtiger ist es, zum richtigen Zeitpunkt mit einer passenden Lösung zu richtigen Preis verfügbar zu sein. Gut muss sie nicht sein, nur gerade gut genug. Der Erfolg von x86 beruht direkt darauf.
MIPS hatte sich lange Zeit in Bereich von Highend-CPUs getummelt, wie damals fast alle 32-Bitter. Das anbieten, was mit verfügbarer Technologie gerade noch machbar ist. ARM anderseits war angetreten, keine Spitzenleistung zum Spitzenpreis zu liefern, sondern minimierte den Aufwand für mittlere Leistung. Als dann im Embedded Bereich und bei Custom Chips eine 32-Bit Architektur benötigt wurde, war ARM zur Stelle, und obendrein offen für alle Kunden, ohne Bevorzugung. Das war m.E. der Schlüssel zum Erfolg. Man war zum richtigen Zeitpunkt mit passenden Lösungen auf dem Markt.
Beitrag #7315442 wurde von einem Moderator gelöscht.
Ich hätte ja gern meinen Router/Firewall durch einen mit RISC-V ersetzt.
Warum? Ist das jetzt hipp? Was kann RISC-V, was die aktuellen ARM und weiß der Geier nicht können?
Die grossen Hersteller sind längst im Boot, und es ist imho nur eine Frage der Zeit, bis RISC-V zu einem ernsthaften Mitbewerber für ARM gewachsen ist.
Konkurrenz belebt das Geschäft und den Wettbewerb. Die Grundlage einer gesunden Wirtschaft. Weder Monopole noch Planwirtschaft will man wirklich haben.
Gast
#7315479
Weder Monopole noch Planwirtschaft will man wirklich haben.
Jepp. Sogar Oligopole sind extrem schädlich. Das Problem ist halt: Die sind (einmal etabliert) SEHR stabil. Sie bilden effektiv Kartelle, auch wenn man die Kartellbildung formal nicht nachweisen kann, ja es ist sogar fraglich, ob eine solche überhaupt beabsichtigt ist oder war. Effektiv ergibt sich das Quasi-Kartell aber trotzdem...
Sprich: das wird nicht der Markt richten. Denn der erzeugt sowas...
Gast
#7315481
Weil der Zusammenhang zwischen technischen Eigenschaften und wirtschaftlichem Erfolg in vielen Branchen recht locker ist. Wichtiger ist es, zum richtigen Zeitpunkt mit einer passenden Lösung zu richtigen Preis verfügbar zu sein. Gut muss sie nicht sein, nur gerade gut genug.
Dem stimme ich zu. Aber ich denke auch das manchmal auf geheimnisvolle weise auch noch Glueck dabei war.
Und manchmal auch Dinge die den Leuten heute nicht mehr klar sind. Ein schoenes Beispiel der MCS51 kam ja von Intel, er wurde bei uns aber auch von Philips/Siemens gemacht. Es gab ein Handbuch in Deutsch! Das duerfte bei einer Menge Leuten damals den Anfang leichter gemacht haben weil Englisch nicht so selbstverstaendlich war wie heute. Dafuer hatte der Z80 interessanterweise in Japan einen grossen Liebhaberkreis (vgl: Gameboy, Sharp E220, Toshiba-Controller) Ursache duerfte dort in den MSX-Computern gelegen haben die dort beliebter waren weil sie japanisch unterstuetzt haben.
Der enorme Aufstieg von ARM hatte IMHO etwas damit zutun das zwar viele Hersteller MCUs herstellen konnten, aber mit erstaunen feststellten das sie immer mehr Aufwand und Geld in Compiler, Debugger und Entwicklungsumgebung steckten und die Kunden das nicht immer zu zahlen bereit waren.
Und bei RISC/V ist es natuerlich eine bemerkenswerte Kombination aus Geiz ist Geil und Politik. Sowas muss ja praktisch erfolgreich sein. :)
Olaf
Es gab ein Handbuch in Deutsch!
Das waren eben andere Zeiten. Ich besitze ein deutsches Handbuch zur 68000, von Motorola höchstselbst.
Gast
#7315490
Hi, ich gebe jetzt aich mal meinen Senf dazu.
- Fuer IOT-Gateway gibt es etwas von Renesas RZFive (Linux)
- Fuer die Bastler auf Kickstarter visionfive-2 (Linux)
- Risc-V cores werden gerne in ASICs verwendet.
In China arbeiten sehr viele Firmen an RISC-V um von ARM weg zukommen. Ich sehe auf der Arbeit keinen grossen Unterschied weder im Handling noch bei der Geschwindigkeit. Nach u-boot ist alles der gleiche Sumpf.
Die logische Lösung wäre es die Flags pro Register zu haben. Alles andere ist einfach Unsinn.
Schau Dir einfach mal den Assembler-Code zu einem compilierten Programmteil an und überprüfe selber, wie oft das Paar "Compare - Jump" vorkommt und wie oft ein Flag außerhalb dieser Situation abgeprüft wird. Die beiden Befehle Compare - Jump sind bei modernen Architekturen ein Befehl.
Ich behaupte mal, dass es genau umgekehrt ist: in 95% aller Fälle ist der Umweg über das Flag Register nachteilig. Nur aus Kompatibilität existiert es in den alten Architekturen noch. Aber vielleicht hast Du konkrete Gegenbeispiele, dass es viele Situationen gibt, in denen der Umweg vorteilhaft ist?
Die beiden Befehle Compare - Jump sind bei modernen Architekturen ein Befehl.
Und werden mindestens bei Intels x86 im Rahmen der Dekodierung zu einem internen Befehl zusammengelegt.
Ich hätte ja gern meinen Router/Firewall durch einen mit RISC-V ersetzt.
Warum?
Weil ich durchaus auch gern mal experimentiere. Schließlich habe ich ja auch keinen Plastikboxrouter – auch aktuell schon nicht. Aktuell ist es allerdings ein Intel Atom, der in die Jahre gekommen ist. Netzteil ist abgeraucht (Mini-ATX-Sonderlocke, jetzt durch externes ATX-Netzteil ersetzt), der schnellste ist er nicht mehr, und energieverbrauchsmäßig sollte das inzwischen halt auch besser gehen.
Schätzungsweise wird es dann natürlich eher ein ARM-Board werden, eben weil RISC-V mit der nötigen Peripherie (wenigstens SATA oder nVME) aktuell noch schlechter zu haben sind. Aber auch bei ARMs sehen wir die Engpässe ja, siehe Raspberry Pi.
Gast
#7315550
Sprungbefehle kann man hingegen ohne Flags besser implementieren. Ein "alter" Prozessor benötigt ein Compare und Conditional Jump. "Moderne" RISC Prozessoren arbeiten hier gerne mit einem "Compare and Jump" - also nur ein Befehl statt zwei und keine Abhängigkeiten mit einem Register das sich die verschiedenen Ausführungseinheiten teilen müssen.
CJNE sind keine zwei Befehle sondern nur einer. (wieviel Takte das braucht ist was anders). Eine Logikschaltung (in ner CPU) kann überhaupt keinen JMP machen ohne dazu ein Flag auszuwerten! Wenn das Flag nicht zuerst mit Befehl erzeugt wird, dann muss es halt innerhalb eines sogen. 'Compare and Jump'-Befehls erzeugt werden.
Wenn das Flag nicht zuerst mit Befehl erzeugt wird, dann muss es halt innerhalb eines sogen. 'Compare and Jump'-Befehls erzeugt werden.
Diese Information ist dann aber keine aufwändige zentrale Ressource mehr.
Das waren eben andere Zeiten. Ich besitze ein deutsches Handbuch zur 68000, von Motorola höchstselbst.
Vom Chefdesigner signiert? ;-)
Gast
#7315589
Wenn das Flag nicht zuerst mit Befehl erzeugt wird, dann muss es halt innerhalb eines sogen. 'Compare and Jump'-Befehls erzeugt werden.
Diese Information ist dann aber keine aufwändige zentrale Ressource mehr.
Dafür aber ein aufwändiger Befehl.
Vom Chefdesigner signiert? ;-)
Eine Art Trophäe, wegen der mitunter schaurigen Übersetzung. Ich hatte zwei englische, ein Bekannter die deutsche. Also habe wir getauscht. Er verstand genau wie ich in dieser Branche Englisch besser als Deutsch.
Dafür aber ein aufwändiger Befehl.
Weniger Aufwand als zwei Befehle, die durch die besagte Ressource verbunden sind. Es wäre kein Fehler, die Köpfe hinter RISC-V zu respektieren.
Gast
#7315611
Es ist mehr Aufwand einen 'CompareAndJump'-Befehl zu implementieren, als einen 'Branch'-Befehl (der lediglich ein Flag auswertet (das sowiso schon da ist)).
das sowiso schon da ist
In diesem Fall ist die Flag aber nicht vorhanden und der Overhead für Flags als zentrale Resource, sowie die Dekodierungslogik für die zusätzlichen obsoleten Instruktion zum Verändern der Flags entfallen
Gast
#7315641
Es braucht keine 'Dekodierungslogik', kein 'Overhead' zum verändern der Flags; Die Flags werden einfach stand.mässig (was keine ! zusätzl. Zeit braucht) mit jedem (Rechen)Befehl erzeugt und gespeichert.
Es braucht keine 'Dekodierungslogik', kein 'Overhead' zum verändern der Flags; Die Flags werden einfach stand.mässig (was keine ! zusätzl. Zeit braucht) mit jedem (Rechen)Befehl erzeugt und gespeichert.
Eine Frage der Perspektive. Beim ATmega88 oder dem Cortex M3 sind Flags sehr einfach zu implementieren. Beim Intels Raptor Lake oder Apples M1 sind sie höllisch komplex.
Wenn man also eine Architektur konzipiert, die in der Minimalversion den Cortex M Konkurrenz machen soll, aber am anderen Ende der Skala auch in Smartphones und Laptops einsetzbar sein soll, spielt das eine wesentliche Rolle.
Die Flags werden einfach stand.mässig (was keine ! zusätzl. Zeit braucht) mit jedem (Rechen)Befehl erzeugt und gespeichert.
Du hast es noch nicht begriffen.
Es geht nicht drum, wie "aufwändig" irgendeine Dekodierung ist. Das ist Logik, das ist einfach und schnell.
Der Aufwand entsteht in den Pipelines und irgendwelchen Vorhersagen. An der Stelle ist es effizienter, keine globalen Abhängigkeiten zu haben, sondern alles (also Test und Entscheidung) direkt in einem Befehl. Globale "Flags" sind dabei externe Bedingungen, auf die man Rücksicht nehmen müsste, während ein simpler Vergleich komplett innerhalb des Befehls abgehandelt werden kann.
Bei "kleinen" Architekturen musste man die Flags noch häufig benutzen, um mehrere kleine Datentypen in der Arithmetik zu einem größeren zusammenzufügen. Bei einer 64-Bit-CPU braucht man sowas nur noch selten; da sind die Flags dann nur noch Sprungentscheidungen ("wenn Ergebnis 0, dann spring zum Ende der Schleife"), und da ist es effizienter, Test und Sprung in einem Befehl zu haben.
Das ist zumindest, was ich jetzt aus der Diskussion mitgenommen habe …
Gast
#7315652
Der RISCV-Befehlssatz ist m.E. nicht besonders für die händische Assemblerprogrammierung geeignet. Der eine oder andere könnte dann zu dem Schluss kommen, dass es eine schlechte Architektur sei. Den Compilern (und -bauern) ist der Punkt aber egal.
Das ist zumindest, was ich jetzt aus der Diskussion mitgenommen habe …
Yep. Bei x86 gibt es ein ziemlich böses Beispiel dafür, was Flags anrichten können. Weil die Status-Flags keine einzige Verwaltungseinheit sind, sondern sich in 3 unabhängige Gruppen aufteilen. Weil manche Befehle nur manche Flags beeinflussen. Und weil zu viele Befehle sie beeinflussen.
Beispiel, handoptimierter Code eines x86 Kenners:
1 |
|
2 |
|
3 |
|
Bei einem OoO Core existieren hier mehrere unabhängige Datenflüsse.
-
Die DEC Befehle sind nur von sich selbst abhängig, können also autakt voran laufen, einer pro Takt.
-
Die Ladeoperationen sind nur von DEC abhängig, können diesen also direkt hinterdrein hoppeln, einer pro Takt. Die Latenz des Zugriffs verschwindet in der Tiefe der OoO-Puffer und tritt nicht in Erscheinung.
-
Die Additionen sind nur vom Ergebnis der Ladeoperation und sich selbst abhängig, laufen den beiden vorigen Datenflüssen weit hinterher.
Sind die Puffer der OoO-Engine tief genug, ergibt das 1 Takt pro Iteration.
Betrachtet man die Flags als eine Einheit, muss DEC das davon nicht beeinflusste C-Flag durchreichen, hat also eine Abhängigkeit vom vorigen Zustand von C. Und das hat Folgen, denn nun laufen diese Operationen im Gänsemarsch hintereinander ab, und nur der Sprung verschwindet:
1 |
|
2 |
|
3 |
|
4 |
|
5 |
|
6 |
|
7 |
|
Nun sind es also 6 Takte pro Iteration, nicht mehr 1.
Wenn man aber diese 3 Flag-Gruppen trennt, verdreifacht man den Aufwand für Renaming und Abhängigkeitserkennung der Flags.
Der RISCV-Befehlssatz ist m.E. nicht besonders für die händische Assemblerprogrammierung geeignet.
Ist zwar nicht dafür gedacht, aber eigentlich ziemlich geradeaus, ohne grosse Überraschungen. Ausser natürlich, ein Leben ohne Flags sei zwar möglich, aber sinnlos.
Wenn du eine leidlich moderne Architektur erleben willst, die so wirklich überhaupt nicht für Assembler taugt: Maxims MaxQ2000 (ausgerechnet ;-).
CJNE sind keine zwei Befehle sondern nur einer. (wieviel Takte das braucht ist was anders).
Und ein Belegt dafür, dass auch die Z80 Entwickler erkannt haben, dass es Sinn machen kann, den Vergleich und den Sprung in ein Befehl zusammen zu fassen.
Bei 8 Bit Prozessoren war das allerdings von etwas eingeschränkten Nutzen solange man keine 16 Bit oder 32 Bit Compares hat. Dann braucht man halt das Flag Register.
Eine Logikschaltung (in ner CPU) kann überhaupt keinen JMP machen ohne dazu ein Flag auszuwerten! Wenn das Flag nicht zuerst mit Befehl erzeugt wird, dann muss es halt innerhalb eines sogen. 'Compare and Jump'-Befehls erzeugt werden.
Ja, es macht aber kein Umweg über ein Flag Register welches mit mehreren superskalaren Ausführungseinheiten geteilt werden muss.
Gast
#7315820
während ein simpler Vergleich komplett innerhalb des Befehls abgehandelt werden kann.
Nö. Ein Comparator/Vergleich mit anschliesendem JMP erfordert mehr Zeit als ein JMP anhand eines Flags das bereits gesetzt ist.
Und ein Flag bei einer Rechen-Op zusätzl. zu erzeugen und zu speichern kostet auch keine zusätzl. Zeit.
ein Flag Register welches mit mehreren superskalaren Ausführungseinheiten geteilt werden muss.
Nö. Je Ausführungseinheit ein Flag-Register.
Gast
#7315836
Nö. Je Ausführungseinheit ein Flag-Register.
Super. Und woher weißt du dann in welcher execution engine der Befehl ausgeführt wurde? Genau, weißt du nicht. Wenn dann Flags pro Register.
Was man bei RISC-V vielleicht verstehen sollte: Es geht nicht um die beste Performance im e Bereich der Cortex-M Prozessoren. Dafür skaliert der Core wunderbar in den high performance Bereich und das besser als ARM. Man kann mit RISC-V einfach Designs entwerfen mit 10 execution engines.
Gast
#7315843
Je Ausführungseinheit ein Flag-Register.
Super. Und woher weißt du dann in welcher execution engine der Befehl ausgeführt wurde? Genau, weißt du nicht.
Doch. Die Engine weiss, in welcher Einheit das ausgeführt wurde, denn die hat den Befehl dorthin verteilt.
Wenn dann Flags pro Register.
Blödsinn.
Gast
#7315857
Globale "Flags" sind dabei externe Bedingungen,
Nö. Flags sind keine Bedingungen.
Dafür aber ein aufwändiger Befehl.
Weniger Aufwand als zwei Befehle, die durch die besagte Ressource verbunden sind.
Nö. Rechenbefehle sind meist sowiso nötig, also liegt da nichts näher, als parallel dazu (was keine 1/100 ns kostet) ein entspr. Flag mit abzuspeichern; Bei dann evtl. folgendem ..JMP..Befehl braucht dieses Flag dann eben NICHT mehr sep. erzeugt werden (was daher ZeitEinsparung! bedeuted und die Sache schneller macht (denn eine Comparator-Auswertung kriegt man zeitl. nicht umsonst)).
Es geht ja auch nicht nur um einen einzelnen Befehl, sondern um den Befehlssatz und dessen Effizienz insgesamt.
Zum Beispiel ist 64-Bit Arithmetic auf einem 32-Bit RISC-V umständlich:
1 |
|
2 |
|
3 |
|
4 |
|
1 |
|
2 |
|
3 |
|
4 |
|
5 |
|
6 |
|
Die ersten beiden Befehle addieren High- und Low-Teil unabhängig voneinander. Der dritte Befehl ist in C-Speek "a2 = a0 < a2" und berechnet das Carry nach a2. Der vierte Befehl schließlich addiert das Carry auf den High-Teil.
Mit Carry-Flag und entsprechenden Befehlen braucht das nur 2 Instruktionen.
Die Frage ist dann, wie oft sowas in einer Applikation auftaucht, und ob es merklich zum Resourcen-Verbrauch beiträgt (Energie-, Zeit-, Die- und Speicherverbrauch, in dieser Reihenfolge).
Und die Frage ist auch, wie ist die Effizienz (wieder bezüglich Energie, Zeit und Speicher etc.) einer hinreichend gleichen Architektur /mit/ Flags, und zwar bezogen auf komplette Anwendungen. Abermals muss man feststellen, dass Sequenzen wie oben selten sind. Bei einem Core mit Flags wären aber alle Befehle aufwändiger und würden mehr Energie verbrauchen (da mehr Gates).
Eine unangenehme Eigenschaft von Flags ist dass sie Anhängigkeit zwischen Befehlen einführen. Das macht Pipelines weniger effizient, und auch auf Software-Ebene gibt es Einschränkungen, z.B. führen weniger Abhängigkeiten zu besseren Möglichkeiten für Scheduling. So könnte ein Compiler Instruktionen anderer Befehle zwischen die der 64-Bit Addition schedulen; Bei einem Core mit Flags ist das oftmals nicht möglich.
Und für einfache Sprungbefehle kann man ein Flag in einem Register setzen (SLT) und abhängig davon springen. Cores ohne Flags wie RISC-V haben aber i.d.R. zusätzlich auch Compare-and-Branch Instruktionen wie BLT, die nur einen Befehl belegen. Und bedingte Sprünge dürften um Größenordnungen häufiger sein als 64-Bit Arithmetik.
Und schließlich: Falls die Applikation so durchsetzt ist von 64-Bit Integer Arithmetik, kann man einen 64-Bit Typ in Betracht ziehen.
Gute Zusammenfassung, Johann
Gast
#7315918
Die Frage ist dann, wie oft sowas in einer Applikation auftaucht, und ob es merklich zum Resourcen-Verbrauch beiträgt (Energie-, Zeit-, Die- und Speicherverbrauch, in dieser Reihenfolge).
Bei MIPS ist der Zeit-, Die- und Speicherverbrauch schlechter.
Eine unangenehme Eigenschaft von Flags ist dass sie Anhängigkeit zwischen Befehlen einführen.
Dies führte bei manchen Architekturen zu mehreren Flag-Registern. Bei IBM Power zu 8 Stück zu 4 Bits, wobei da auch die ursprüngliche Mehrchip-Implementierung eine Rolle spielte. Bei Intels IA64 fanden sich 64(?) Predication-Register. Damit lassen sich Erzeugung und Verwendung von Bedingungen trennen.
Allerdings stammten diese Ideen aus der Zeit vor tiefen Out of Order Implementierungen. In der Hoffnung, es ginge auch ohne. Gewonnen haben aber die OoO. Und dann hatte man mit den zusätzlichen Ressourcen zusätzlichen Aufwand, der wenig einbrachte.
Bei ARMv8 fällt die Abkehr von Predication auf. Weder die in jedem Befehl enthaltene Form bei 32-Bit ARM, noch die Präfix-basierte Methode von Thumb2 finden sich wieder. Das legt nahe, dass es effektiv keine Vorteile bringt, denn eine solchen Entscheidung basiert nicht auf Wolkenkuckucksheimen, sondern auf Untersuchungen realer Programme.
Gast
#7316105
Eine unangenehme Eigenschaft von Flags ist dass sie Anhängigkeit zwischen Befehlen einführen.
Dafür ist die positive Eigenschaft davon, dass man auf sie zugreifen kann OHNE weitere Rechenleistung zu benötigen. Ein Design ohne solch expliz. Flags ist also weniger leistungsfähig.
Gast
#7316106
Wo liegen eigentlich die Vorteile, wenn man ein Carry Flag unabhängig von Takt hat (also erstmal so stehen bleibt, bis was neues kommt), oder eines, das getaktet ist und mit jedem Befehl gewissermaßen neu "aufgefrischt" wird?
Wo liegen eigentlich die Vorteile, wenn man ein Carry Flag unabhängig von Takt hat
Was meinst du damit? Man hat zwar schon asynchrone Prozessoren ausprobiert, die also nicht über einen zentralen Takt verfügen. Abgehoben hat das bisher nicht. Von einem asynchronen C-Flag habe ich nicht gehört.
Es gab allerdings einen 32-Bit Prozessor, der sein Ergebnis in 3 Stufen lieferte. In der ersten Stufe die unteren 16 Bits, in der zweiten die oben 16 Bits und in der dritten die Statusinformation. Voll gepipelined.
Gast
#7316182
Eine unangenehme Eigenschaft von Flags ist dass sie Anhängigkeit zwischen Befehlen einführen.
Dafür ist die positive Eigenschaft davon, dass man auf sie zugreifen kann OHNE weitere Rechenleistung zu benötigen.
Das Nadelöhr aktueller CPUs ist aber nicht die RECHENleistung ...
Ein Design ohne solch expliz. Flags ist also weniger leistungsfähig.
Falsch.
Die Leistungsfähigkeit der Prozessoren hängt seit ungefähr 30 Jahren nicht an der nackten Rechenleistung der ALU, sondern an der Cleverness der Ablaufsteuerung.
Man darf daher nicht blindlings die ALU-Leistung steigern, sondern muss umgekehrt alles unterlassen, was der Ablauf- steuerung die Arbeit schwer macht. Vermeidbare Abhängigkeiten zwischen Befehlen sind ein guter Kandidat dafür.
Gast
#7316230
Ein Design ohne solch expliz. Flags ist also weniger leistungsfähig.
Falsch.
Falsch. Und wenn die Ablaufsteuerung für sich gesehen noch so leistungsfähig ist, ist diese CPU - ohne diese Flags - insgesamt weniger leistungsfähig.
Falsch.
Nun, die Schöpfer von RISC/V haben ganz offensichtlich komplett vergessen, dich mit einzubeziehen. Bei deiner Kompetenz ist ihnen da wirklich was entgangen.
(Wer Ironie findet, darf sie gern behalten.)
Bei deiner Kompetenz ist ihnen da wirklich was entgangen.
Eine Diskussion mit MCUA ist ebenso sinnvoll wie mit Josef-Mr Hedaxdezimal . . .
Gast
#7316271
Eine Diskussion mit MCUA ist ebenso sinnvoll wie mit Josef-Mr Hedaxdezimal . . .
Vor all Dingen sagt du das
Gast
#7316277
Nun, die Schöpfer von RISC/V haben ganz offensichtlich komplett vergessen, dich mit einzubeziehen. Bei deiner Kompetenz ist ihnen da wirklich was entgangen.
Vieleicht haben die ja komplett vergessen dich einzuladen. Dann hättest du erklären können, wie es nicht geht.
Gast
#7316281
Die Leistungsfähigkeit der Prozessoren hängt seit ungefähr 30 Jahren nicht an der nackten Rechenleistung der ALU, sondern an der Cleverness der Ablaufsteuerung.
So blöd sind dann die Chipdesigner dann doch nicht.
Die Geschwindigkeit wird in der Praxis entweder von der ALU in einer kritischen Schleife bestimmt, oder wenn die ALU nicht die Geschwindigkeitsbreme ist, dann ist es der Speicherzugriff (heute häufiger). Nur wenn Dilettanten am Werk sind, die keine Ahnung von der Architektur haben, spielt die Ablaufsteuerung rein.
Die ganze Diskussion um die Flags ist akademisch. Denn ungewollte Abhängigkeiten von den Flags spielen selten eine Rolle und die kann man ganz einfach beseitigen, indem man die Flags vorher löscht. Einfach indem man 0 ins Register schreibt, das ist eine Operation die nebenher mitgemacht wird.
Die Risc/v Architektur scheint aber nicht das Gelbe vom Ei zu sein:
Keine Flags: https://gmplib.org/list-archives/gmp-devel/2021-September/006013.html
Zu einfache Addressierungsarten, RAM-ineffizienter Code: https://lobste.rs/s/yqqhxu/llvm_for_m68k_completed_not_merged
Keine 2 Operanden Operationen: https://stackoverflow.com/questions/65006052/how-do-i-write-not-operation-for-the-risc-v-assembly-language
Keine vernünftigen Bit Operationen, keine Rotation, kein NOT: https://stackoverflow.com/questions/57949406/rotating-bits-in-risc-v
All das führt zu vielen Extensions, die die Architektur zerfransen. Risc/V scheint eine überholte rein akademische Architektur zu sein, die halt hergenommen wird, weil die Leute keine Gebühren an ARM zahlen wollen, aber zu faul sind was zeitgemäßes zu bauen. Die Randbedingungen haben sich seit den 90'ern fundamental geändert. Damals waren Transistoren relative teuer, heute kosten sie nichts. Damals war RAM im Vergleich zu CPU viel schneller als heute. Damals haben parallele Recheneinheiten keine grosse Rolle gespielt.
Gast
#7316314
Die Risc/v Architektur scheint aber nicht das Gelbe vom Ei zu sein:
Hatte ich die Flags schon erwähnt ????????
Nichtmal die Möglichkeit, im Speicher atomic ein Bit zu setzen.
Es gibt eine ganze Menge, was dieses Ding nicht kann.
Es ist nicht besser, weil es neuer ist.
Keine Flags: https://gmplib.org/list-archives/gmp-devel/2021-September/006013.html
Das haben wir hier schon endlos hoch und runter gebetet. Es gibt hier viele Leute die meinen, dass sie das Thema aus dem Gefühl heraus besser beherrschen als das Entwickerteam um den Alpha Prozessor oder die vielen Leute die am RISC V arbeiten. Nun denn...
Zu einfache Addressierungsarten, RAM-ineffizienter Code: https://lobste.rs/s/yqqhxu/llvm_for_m68k_completed_not_merged
Das ist ein Argument, bei den Adressierungsarten schwächelt der RISC V. Nach Messungen aus dem RISC V Umfeld benötigt er ca. 4% mehr Codespeicher.
Keine 2 Operanden Operationen: https://stackoverflow.com/questions/65006052/how-do-i-write-not-operation-for-the-risc-v-assembly-language
Wenn Du nicht nur die Überschrift gelesen hättest, dann wüsstest Du auch, dass es diese Befehle gibt - nur haben Sie keinen eigenen OP-Code, da sie aus anderen bereits vorhandenen Befehlen gebildet werden können. In dem Beitrag ist eine lange Liste mit den pseudo-Assembler Befehlen dazu.
Keine vernünftigen Bit Operationen, keine Rotation, kein NOT: https://stackoverflow.com/questions/57949406/rotating-bits-in-risc-v
Wenn ich das richtig sehe, dann sind die Bit Operationen (welche rotates beinhalten) im Augenblick noch in "public review" - werden also in nächster Zeit kommen: https://five-embeddev.com/riscv-bitmanip/draft/bitmanip.html
Nun, die Schöpfer von RISC/V haben ganz offensichtlich komplett vergessen, dich mit einzubeziehen. Bei deiner Kompetenz ist ihnen da wirklich was entgangen.
Vieleicht haben die ja komplett vergessen dich einzuladen.
Ich maße mir zumindest nicht an zu behaupten, Kompetenz in der Richtung zu besitzen.
Gast
#7316361
oder die vielen Leute die am RISC V arbeiten.
Stell dir vor: Es gibt auch Leute, die an CISC arbeiten.
dann sind die Bit Operationen...
...nichts, was auf den Speicher wirkt
Gast
#7316363
Keine 2 Operanden Operationen:
Wenn Du nicht nur die Überschrift gelesen hättest, dann wüsstest Du auch, dass es diese Befehle gibt - nur haben Sie keinen eigenen OP-Code,
Der Assembler kann natürlich alle möglichen Befehle vortäuschen. Nur effizient wird es damit nicht.
Keine vernünftigen Bit Operationen, keine Rotation, kein NOT: https://stackoverflow.com/questions/57949406/rotating-bits-in-risc-v
Wenn ich das richtig sehe, dann sind die Bit Operationen (welche rotates beinhalten) im Augenblick noch in "public review" - werden also in nächster Zeit kommen: https://five-embeddev.com/riscv-bitmanip/draft/bitmanip.html
Jeder 8-Bit uC aus den 80'ern kann solche einfachen Dinge von Haus aus. Risc/V braucht ein Komitee dazu. Der Programmierer hat dann die Auswahl zwischen einem Duzend Varianten und allen möglichen inoffiziellen Versionen.
Wenn Du nicht nur die Überschrift gelesen hättest, dann wüsstest Du auch, dass es diese Befehle gibt - nur haben Sie keinen eigenen OP-Code,
Der Assembler kann natürlich alle möglichen Befehle vortäuschen. Nur effizient wird es damit nicht.
Lese doch bitte den Beitrag mal durch. Das ist kein vortäuschen, sondern es wird genau diese Funktion ausgeführt. Ein XOR mit -1 ist ein NOT und wird in genau der gleichen Zeit durchgeführt.
Risc/V braucht ein Komitee dazu.
Es ist sicherlich ein Kritikpunkt, dass beim RISC V alles mögliche erst mal in großer Runde diskutiert wird und deshalb einiges länger dauert. Aber das vermindert auch das Risiko, dass an irgendeiner Stelle Entscheidungen getroffen werden, die einem später Ärger bereiten. Als Beispiel würde ich z.B. das Chaos bei X86 mit dem ganzen MME/MMX Kram anführen, der vier oder fünfmal (inkompatibel) nachgebessert werden musste und eigentlich immer noch nicht wirklich gut ist.
Die Risc/v Architektur scheint aber nicht das Gelbe vom Ei zu sein:
Was in den Links steht, läuft teils weniger auf spezifische Eigenschaften von RISC-V raus, auf vielmehr die alte RISC vs CISC Diskussion.
Wenn man eine bestimmte Befehls-Feature einer bestimmten Architektur in einer anderen Architektur vermisst, ist das zunächst nur ein Thema für Assembler-Programmierer. Entscheidender ist, ob man sie ersetzen kann, und wie häufig sie tatsächlich benötigt wird.
Atomare Operationen bei Multiprocessing kann man über entsprechende Buszyklen implementieren, oder über nicht-atomar arbeitende Ersatzbefehle. Atomare Operationen bezüglich Peripherie sind ein ziemlich µC-spezifisches Thema. Kein Grund, in zig Cores einer CPU eine Funktion einzubauen, die man auch im I/O-Port selber implementieren kann.
Die ganze Diskussion um die Flags ist akademisch.
Grundlage von "akademischen" Diskussionen sind nicht selten Untersuchungen zum realen Verhalten realer Programme. Schon seit geraumer Zeit kann man dafür nicht nur statische Codeanalysen nutzen, oder dynamische Analysen in Simulationen, sondern auch eine hohe Anzahl von Performance-Countern, die sich seit zig Jahren in Prozessoren befinden.
Nach Messungen aus dem RISC V Umfeld benötigt er ca. 4% mehr Codespeicher.
Nur? Ist in dieser Dimension ein Thema, wenn der Flash-Speicher eines Mikrocontrollers dann nicht mehr ausreicht. Sonst eher nicht, denn jenseits der Cortex M Klasse sind die Hitrates von Caches entscheidend, nicht die Anzahl Bytes des Images auf Disk. Und an dieser Stelle ist das nur dynamische Verhalten wichtig, keine statischen Zahlen.
https://lobste.rs/s/yqqhxu/llvm_for_m68k_completed_not_merged
Das ist ein Argument, bei den Adressierungsarten schwächelt der RISC V.
Wenn das "68k" in diesem Kontext kein Zufall ist, denn verwundert diese Kritik nicht. Allerdings sind die 68k an ihrer Komplexität gescheitert, in mehrerlei Hinsicht. Adressierungsarten inklusive. Kein Grund, deren Fehler zu wiederholen.
Das haben wir hier schon endlos hoch und runter gebetet. Es gibt hier viele Leute die meinen, dass sie das Thema aus dem Gefühl heraus besser beherrschen als das Entwickerteam um den Alpha Prozessor oder die vielen Leute die am RISC V arbeiten. Nun denn...
Nicht nur dabei. Respekt vor Kompetenz ist ein schwieriges Thema. Ist der Respekt zu hoch, wird er zur Verhinderung von sinnvoller Kritik. Ist er zu gering, ist es reflexartige Ablehnung, behindert dieses Verhalten eher. Die Balance zu finden ist nicht einfach, aber in heutiger Zeit neigen viele zu Letzterem.
Nicht nur dabei. Respekt vor Kompetenz ist ein schwieriges Thema. Ist der Respekt zu hoch, wird er zur Verhinderung von sinnvoller Kritik. Ist er zu gering, ist es reflexartige Ablehnung, behindert er eher. Die Balance zu finden ist nicht einfach, aber in heutiger Zeit neigen viele zu Letzterem.
Ja, das ist ein Problem - wie erkenne ich tatsächliche Kompetenz und unterscheide sie von vorgetäuschter Kompetenz.
Für mich ein wichtiger Entscheidungspunkt: kann man über die Themen diskutieren oder werden einem nur platte Behauptungen um die Ohren gehauen.
Und noch einer: geht mein Gegenüber auf meine Argumente ein - vielleicht auch indem er sie widerlegt - oder ignoriert er sie einfach.
Nach Messungen aus dem RISC V Umfeld benötigt er ca. 4% mehr Codespeicher.
Nur? Ist in dieser Dimension ein Thema, wenn der Flash-Speicher eines Mikrocontrollers dann nicht mehr ausreicht. Sonst eher nicht, denn
Die Zahl stammt aus dem Buch von Patterson & Watermen - das wird nicht jeder als Referenz akzeptieren.
Ich denke, dass der RISC V ein Teil des umfangreicheren Codes dadurch wieder los wird, dass dort normaler Code mit compressed Code beliebig gemischt werden kann. Das kann ARM meines Wissens nicht so flexibel.
Gast
#7316501
Das kann ARM meines Wissens nicht so flexibel.
Da, wo es überhaupt auf Code-Dichte ankommt, also Cortex-M, hat ARM mit Thumb-2 genau dieses Thema gelöst. ARM-Code (Instruktionen mit 32 bit) war schnell, aber brauchte viel Platz. Thumb-Code (Instruktionen mit 16 bit) war dicht, aber langsam, weil zuviel in zwei Instruktionen aufgesplittet werden mußte. Thumb-2 mit 16/32 bit gemischt löst beides, kehrt sich aber von der reinen RISC-Lehre mit festen Befehlslängen ab.
Gast
#7316692
Und wenn die Ablaufsteuerung für sich gesehen noch so leistungsfähig ist, ist diese CPU - ohne diese Flags - insgesamt weniger leistungsfähig.
Das ist -- ich wiederhole mich -- Blödsinn, und ich will auch begründen, warum:
Die "Leistungsfähigkeit" einer CPU bemisst sich ganz allgemein gesprochen danach, wie schnell sie eine gegebene komplexe Aufgabe der Datenverarbeitung erledigen kann. (Unterschiedliche Aufgaben können also zu unterschiedlichen Antworten führen.)
Diese "komplexen Aufgaben" (=Programme) bestehen technisch aus (relativ) einfachen Aktionen (Befehlen bzw. µOps), die teils parallel ausgeführt werden können, teils aber auch nicht.
Eine komplexe Zusammenstellung von Vorgängen, die voneinander abhängen und teils parallel aus geführt werden können, teils aber auch nicht, nennt man einen --> Netzplan.
Die kürzeste Zeitdauer, in der ein solcher Netzplan durchlaufen werden kann, hängt vom sogenannten --> kritischen Weg (kritischen Pfad) ab; er diktiert die minimale Durchlaufzeit, und jede zusätzliche Verzögerung eines Vorganges im kritischen Weg führt sofort zu einer globalen Verzögerung.
Das bedeutet im Umkehrschluss: Es gibt unkritische Aktionen, bei denen eine (geringe) Verzögerung NICHT dazu führt, dass die gesamte Durchlaufzeit länger wird.
Oder noch anders formuliert: Es hat keinen Sinn, Abläufe zu beschleunigen, die nicht im kritischen Weg liegen, weil das Gesamtziel trotzdem nicht schneller erreicht wird.
Bedeutet: Wenn die Abfrage der Flags prozessorintern statistisch in der Regel nicht im kritischen Weg liegt, dann bewirkt es KEINE Verlangsamung der Verarbeitung, auf die Flags zu verzichten und die Bedingungen erst dann zu prüfen, wenn man die Aussage wirklich braucht.
Kleiner Seitenhieb: Schlechte Chefs neigen dazu, ALLE Mitarbeiter anzutreiben, wenn die Zeit knapp wird. Das hat den großen "Vorteil", dass man all die Leute, deren Arbeit gar nicht im kritischen Weg liegt, sinnlos verschleißt und erschöpft -- ihre vermehrte Anstrengung trägt nämlich gar nichts zur Beschleunigung des Projektes bei, verhindert aber, dass sie den TATSÄCHLICH belasteten Kollegen sinnvoll helfen können...
Gast
#7316695
Oder noch anders formuliert: Es hat keinen Sinn, Abläufe zu beschleunigen, die nicht im kritischen Weg liegen, weil das Gesamtziel trotzdem nicht schneller erreicht wird.
Es ist sogar noch schlimmer: "unnötige" Berechnungen, die ständig durchgeführt werden führen zu mehr Gateumladungen und somit zu mehr Energiebedarf. Aktuelle Prozessoren sind meist TPD-limitiert.
Gast
#7316711
Grummler schrieb:
Die Leistungsfähigkeit der Prozessoren hängt seit ungefähr 30 Jahren nicht an der nackten Rechenleistung der ALU, sondern an der Cleverness der Ablaufsteuerung.
So blöd sind dann die Chipdesigner dann doch nicht.
???
Ich weiss leider nicht, wie der Teil der Prozessorhardware heutzutage auf Denglisch heißt, den man früher "Steuerwerk" nannte. (Wahrscheinlich hätte ich "Kontrollwerk" schreiben müssen, um verstanden zu werden.)
Die Geschwindigkeit wird in der Praxis entweder von der ALU in einer kritischen Schleife bestimmt, oder wenn die ALU nicht die Geschwindigkeitsbreme ist, dann ist es der Speicherzugriff (heute häufiger).
Das ist die Sicht des Programmieres -- um die geht es hier aber nicht.
Aus Sicht des Chipdesigners wird in der Regel schon die Floskel "...die ALU..." falsch sein -- es gibt nämlich pro Chip mehr als eine...
Die nackte ALU-Leistung zu steigern ist recht einfach mit roher Gewalt machbar (und WURDE ja anfangs auch genau so gemacht): Mehr Parallelität auf allen Etagen, mehr Transistoren, mehr Gatter, kürzere Durchlaufpfade. Nur hilft das nur sehr bedingt, weil die ALU auch mit Daten versorgt werden muss -- und zu allem Überfluss hängt die Frage, welche Daten man als nächstes anschauen muss, häufig davon ab, welches Ergebnis die bisherigen Operationen geliefert haben...
Hier wird dann die Forderung wichtig, dass man tatsächlich DIE Teilschritte beschleunigt, die im --> "kritischen Weg" liegen...
Die ganze Diskussion um die Flags ist akademisch.
Ja -- aber aus einem völlig anderen Grund, als Du denkst.
Denn ungewollte Abhängigkeiten von den Flags spielen selten eine Rolle
Das mag die Sicht des Programmierers sein; um die geht es hier aber nur am Rande.
Mir ist der Gedanke auch neu, aber die Flags sind ein Relikt aus längst vergangenen Zeiten, als die CPU tatsächlich noch eine sequentielle Maschine war, die die Instruktionen in der Reihenfolge ausgeführt hat, in der sie der Programmierer hingeschrieben hat.
Carry braucht man überwiegend dann, wenn Arithmetik mit hoher Wortbreite mit Instruktionen geringer Breite implementiert werden muss. Das betrifft bei 64Bit- Prozessoren überwiegend Zahlentheorie und Kryptographie. Letztere ist wichtig; dafür braucht man eine Lösung. Für Schleifenzähler und ähnlichen Kleinkram ist eine 64Bit-Variable in vielen Fällen sicher ausreichend (mit DER Schleife ist auch ein aktueller Prozessor mehrere Wochen beschäftigt).
Null/NichtNull/Größer/Kleiner/Positiv/Negativ ist trivial durch Kombinatorik bestimmbar; das muss man also nicht vom vorherigen Arithmetik-Befehl übernehmen, sondern das kann der Sprungbefehl selbst ausrechnen, wenn er die Information braucht.
Was bleibt an Flags noch? So für den Alltag des Anwendungsprogrammierers?
Die Randbedingungen haben sich seit den 90'ern fundamental geändert. Damals waren Transistoren relative teuer, heute kosten sie nichts.
Ach so?!
Und warum integriert man dann nicht 64GByte SRAM auf den Prozessorchip, auf den mit vollem Takt zugegriffen werden kann?
Damals war RAM im Vergleich zu CPU viel schneller als heute.
Nur hinsichtlich der Zugriffszeit . Die Transferrate hat m.E. ungefähr Schritt gehalten.
Damals haben parallele Recheneinheiten keine grosse Rolle gespielt.
Richtig.
Trotzdem beharren die Programmierer mit Inbrunst darauf, dass der Sprung, der "nach" dem Arithmetikbefehl ausgeführt wird, ja einfach die Information benutzen kann, die "vorher" in den Flags gespeichert wurde...
Die Leistungsfähigkeit der Prozessoren hängt seit ungefähr 30 Jahren nicht an der nackten Rechenleistung der ALU, sondern an der Cleverness der Ablaufsteuerung.
Schönes Beispiel ist der Pentium 4, dessen Standard-ALUs in der 32 Bit Version eine Latenz von 0,5 Takten hatten. In Verbindung mit dem erheblich höherem Takt lag also die reine Rechenleistung turmhoch über der AMD Konkurrenz.
Das Ganze muss natürlich "Arduinofiziert" werden.
Der RiscV ist auf dem Arduino Nano tatsächlich ein wenig langsam :-p
time for 1000 steps [us]:39256 micro seconds per step:39
Auf einem ESP32 läuts ein wenig schneller:
RiscV on Arduino time for 1000 steps [us]:472
Gast
#7316742
Wegen Regens bin ich heute nicht in die Kirche gegangen, sondern habe die Beiträge hier gelesen. Was soll denn der Nutzen von RISC/V für einen Mikrocontroller sein? 5 cent weniger Kosten? Die Prozessorleistung selbst ist eher zweitrangig, eine leistungsfähige Peripherie doch viel wichtiger.
Aber ich habe nichts dagegen, auch mal über den Tellerrand zu schauen.
Was soll denn der Nutzen von RISC/V für einen Mikrocontroller sein?
Der Nutzen kann hauptsächlich für den Hersteller entstehen.
Der Nutzen kann hauptsächlich für den Hersteller entstehen.
Nicht nur. Der Nutzen könnte auch "Binärcode-Kompatibilität" wie im obigen Beispiel des RiscV Simulators auf dem Arduino-Nano. Außerdem gibt es zu Hauf RiscV Implementierungen in VHDL oder Verilog. Nimmt man diese, ist man vom Vendor-Lockin wie bei PicoBlace o.ä.
https://en.wikipedia.org/wiki/PicoBlaze
geschützt und kann frei verfügbare Compiler verwenden.
Gast
#7316753
Carry braucht man überwiegend dann, wenn Arithmetik mit hoher Wortbreite mit Instruktionen geringer Breite implementiert werden muss
Oder zur Bitausgabe mit Rotation und ADC ("ADD Carry"). In diesem Fall ist das Carryflag auf jeden Fall im "Takt" ;)
( https://stackoverflow.com/questions/4153852/assembly-adc-add-with-carry-to-c )
Gast
#7316827
Was soll denn der Nutzen von RISC/V für einen Mikrocontroller sein? 5 cent weniger Kosten?
Ja sicher. Die werden in Massenprodukten wie SSDs benutzt [1], wo sich das läppert. Dann ist da noch die Preisstabilität für die Lizenz, denn die kostet nichts und wird auch nichts kosten.
Zudem können Hersteller RISC-V-Kerne maßgenau auf ihre Einsatzzwecke schneidern, was bei ARM eine "große" Lizenz erfordern würde, wie z.B. Apple sie hat, und die kostet erheblich.
Dann ist man bei ARM offenbar einem erheblichen Risiko ausgesetzt, nämlich daß die Firma freidreht und Royalties pro Chip verlangt und bestimmte Chip-Designs untersagen möchte [2], und auch so eine Abhängigkeit hat man mit RISC-V nicht.
Scheint erstmal "nur" Cortex-A zu treffen, aber je nachdem, von welcher Heuschrecke ARM mal aufgekauft wird, kann das noch richtig übel werden, und so ein Risiko möchte man sich nicht unnötig ans Bein binden.
In Smartphones ist ARM schwieriger zu ersetzen, weil die nativen Anwendungen recompiliert werden müßten, was einem Henne-Ei-Problem unterliegt, an dem schon Intel mit x86-Androiden gescheitert ist. Aber bei embedded-Controllern wie SSDs gibt's dieses Problem nicht.
[1] https://www.golem.de/news/seagate-und-western-digital-die-risc-v-basierten-ssd-controller-kommen-2012-152690.html [2] https://www.heise.de/news/Qualcomm-CPU-Schmiede-ARM-aendert-Geschaeftsmodell-fuer-hoehere-Einnahmen-7323782.html
Die Leistungsfähigkeit der Prozessoren hängt seit ungefähr 30 Jahren nicht an der nackten Rechenleistung der ALU, sondern an der Cleverness der Ablaufsteuerung.
Schönes Beispiel ist der Pentium 4, dessen Standard-ALUs in der 32 Bit Version eine Latenz von 0,5 Takten hatten. In Verbindung mit dem erheblich höherem Takt lag also die reine Rechenleistung turmhoch über der AMD Konkurrenz.
Blöd nur, dass das am Ende nicht geholfen hat (ich denke darauf wollte Du hinaus..). Die Designphilosophie beim P4 (Netburst) bestand darin, die Logiktiefe pro Pipelinestufe zu minimieren um den Takt zu maximieren. Damit war die Pipeline extrem lang und es gab hohe misprediction Penalties. Architekturen mit kurzerer Pipeline waren am Ende doch effektiver. Dummerweise hat im gleichen Zeitraum auch das "free scaling" aufgehört (Der letzte Knoten, der dem Dennard-Scaling folgte war 130 nm), und der Leistungsverbrauch der Gatter sank nicht mehr im gleichen Maße. Damit waren Register zwischen Pipelinestufen plötzlich ein Problem...
Blöd nur, dass das am Ende nicht geholfen hat (ich denke darauf wollte Du hinaus..).
Natürlich.
Die Designphilosophie beim P4 (Netburst) bestand darin, die Logiktiefe pro Pipelinestufe zu minimieren um den Takt zu maximieren. Damit war die Pipeline extrem lang und es gab hohe misprediction Penalties.
Wobei der Golden Cove Core Intels aktueller 12er Prozessoren mit 17 Takten mispredict penalty von den 19 des ersten P4 nicht mehr so arg weit weg ist. AMD Zen liegt auch in dieser Region. Aber die Vorhersagen werden immer besser.
Tim . schrieb:
Blöd nur, dass das am Ende nicht geholfen hat (ich denke darauf wollte Du hinaus..).
Natürlich.
Die Designphilosophie beim P4 (Netburst) bestand darin, die Logiktiefe pro Pipelinestufe zu minimieren um den Takt zu maximieren. Damit war die Pipeline extrem lang und es gab hohe misprediction Penalties.
Wobei der Golden Cove Core Intels aktueller 12er Prozessoren mit 17 Takten mispredict penalty von den 19 des ersten P4 nicht mehr so arg weit weg ist. AMD Zen liegt auch in dieser Region. Aber die Vorhersagen werden immer besser.
Naja, das versteckt man heutzutage durch mehr Parallelität und mehr Cache.
Spannend ist aber, dass anscheinend jetzt das Ende des SRAM scalings erreicht wurde*. Das heisst das man wieder etwas sorgsamer mit der Speicherhierarchie umgehen muss.
*https://www.tomshardware.com/news/no-sram-scaling-implies-on-more-expensive-cpus-and-gpus
Gast
#7317284
Dann ist man bei ARM offenbar einem erheblichen Risiko ausgesetzt, nämlich daß die Firma freidreht und Royalties pro Chip verlangt und bestimmte Chip-Designs untersagen möchte [2], und auch so eine Abhängigkeit hat man mit RISC-V nicht.
Man fühlt sich an Jazelle (Java ME) erinnert.
("The great thing about RISC-V is that it is a modern and simple instruction-set designed for modern hardware realities such as slow main memory, use of branch predictors, super scalar out of order execution units etc.")
https://medium.com/swlh/risc-v-assembly-for-beginners-387c6cd02c49 https://debugger.medium.com/why-is-apples-m1-chip-so-fast-3262b158cba2
In Smartphones ist ARM schwieriger zu ersetzen, weil die nativen Anwendungen recompiliert werden müßten, was einem Henne-Ei-Problem unterliegt, an dem schon Intel mit x86-Androiden gescheitert ist.
Das ist ungefähr vergleichbar mit dem Übergang von 32-Bit auf 64-Bit Android, nur dass es kein in beiden Modi sehr schnelles bimodales System für nativen Code geben kann, allenfalls Emulation (wie bei Intel).
Beim Pixel 7 hat Google ursprünglich ein reines 64-Bit System vor, in letzter Minute aber noch einen Rückzieher gemacht. Mindestens die Option auf ein reines 64-Bit Android ist für dieses Quartal vorgesehen. Ich fand auch keine App mehr, die damit Probleme hätte, denn seit einer Weile waren für Apps mit nativem Code ggf doppelte Binaries Pflicht.
Gast
#7317369
Das ist direkt vergleichbar mit dem Übergang von 32-Bit auf 64-Bit Android.
Nicht wirklich, denn daß 64 bit kommen würde, war klar. Bei RISC-V ist das alles andere als klar, weswegen es keine Pflicht für fat binaries geben dürfte, zumal es auch schon keine Pflicht zu fat binaries mit inkludiertem x86-Build gab.
Nicht wirklich, denn daß 64 bit kommen würde, war klar. Bei RISC-V ist das alles andere als klar, weswegen es keine Pflicht für fat binaries geben dürfte, zumal es auch schon keine Pflicht zu fat binaries mit inkludiertem x86-Build gab.
Das hängt m.E. davon ab, ob oder wie lange die Chinesen Zugang zu guten ARM-Implementierungen haben. Bei Intel gab es keinen Druck, keine Notwendigkeit. Bei RISC-V kann es das je nach politischer Entwicklung geben.
China ist der weltweit grösste Markt für Android. Entscheidungen dort haben dementsprechende Auswirkungen.
Gast
#7317441
Das hängt m.E. davon ab, ob oder wie lange die Chinesen Zugang zu guten ARM-Implementierungen haben.
Unwahrscheinlich, denn genau diese Entwicklungen würden auch dazu führen, daß die Chinesen gar nicht erst in Googles Playstore kämen - siehe Huawei, die eben deswegen einen eigenen Store machen mußten. Wenn also z.B. Huawei auf RISC-V setzen würde, gäbe es wieder keinen Grund, wieso man das im Google-Playstore mit fat binaries berücksichtigen sollte.
Mindestens die Option auf ein reines 64-Bit Android ist für dieses Quartal vorgesehen. Ich fand auch keine App mehr, die damit Probleme hätte
Ich schon. Für Eagle-Layouts gibts eine schöne App die wohl nicht mehr funktionieren würde. Für einen harten Schnitt zu 64Bit hab ich Null Verständnis wenn das viele ältere Apps ausschließt.
Gast
#7318729
Das ist -- ich wiederhole mich -- Blödsinn, und ich will auch begründen, warum:...
Aber von einer CPU-Innen-Beschaltung hast du schonmal was gehört?
Null/NichtNull/Größer/Kleiner/Positiv/Negativ ist trivial durch Kombinatorik bestimmbar;
Gut bemerkt.
Gast
#7318745
und zu allem Überfluss hängt die Frage, welche Daten man als nächstes anschauen muss, häufig davon ab, welches Ergebnis die bisherigen Operationen geliefert haben...
Da haben wir es doch schon wieder.
("The great thing about RISC-V is that it is a modern ...
Das ist ein Gerücht.
Gast
#7320101
Hier ein weiterer Schritt:
https://www.youtube.com/watch?v=L9Wrv7nW-S8
Die genannten Preise von 10ct sind natuerlich sicher bei grossen Stueckzahlen, sagen wir mal >1000Stk. Gut vergleichen kann man das Teil vermutlich mit einem STM32F030F4P6TR. Dafuer will Mouser 1Euro bei 2500stk. Das sind natuerlich Fantasiepreise. ICh schaetze mal das man den in Stueckzahlen dann fuer 30ct bekommt. Aber vielleicht bringt ja RISC/V auch einfach etwas Schwung in den Markt und die Preise von ARM Controllern werden bald deutlich sinken damit sie ueberleben. .-)
Interessant ist auch das die Programmierumgebung wohl STARK STM32-Kompatibel designt wurde....
Und das deren Programmierer noch keiner beigebracht hat das ein "?" kein guter Programmstil ist. :)
Olaf
Interessant ist auch das die Programmierumgebung wohl STARK STM32-Kompatibel designt wurde....
Auch ST kauft IP zu. Z.B. der USB Core scheint von Synopsys zu sein. Damit ist es nicht ungewöhnlich, sehr ähnliche Peripherie zu finden.
Man kauft einfach die gleiche IP und schwupps, ist man schon sehr "kompatibel".
CPU, Clock-Tree, NVIC sind von ARM vorgegeben. CMSIS genauso. Da bleibt dann nicht mehr wirklich viel um einen Customer-Lock-In zu erzwingen...
73
und die Preise von ARM Controllern werden bald deutlich sinken damit sie ueberleben. .-)
Mein Gott, wie gierig muss man sein, um bei den HEUTIGEN Preisen nach NOCH BILLIGER zu schreien? Elektronik ist heute schon SPOTTBILLIG! In fast allen Ebenen, sei es Konsumerkram oder HighTec!
Gast
#7320262
Mein Gott, wie gierig muss man sein, um bei den HEUTIGEN Preisen nach NOCH BILLIGER zu schreien?
Ich schreie nicht. Ich hoere nur das Echo von Kunden, also euch! :D
Olaf
Gast
#7320288
Gut vergleichen kann man das Teil vermutlich mit einem STM32F030F4P6TR.
Allerdings ist der CH32V003 offenbar als pinkompatibler Ersatz für den STM8S003 gedacht.
In Smartphones ist ARM schwieriger zu ersetzen, weil die nativen Anwendungen recompiliert werden müßten, was einem Henne-Ei-Problem unterliegt, an dem schon Intel mit x86-Androiden gescheitert ist.
Das betrifft nur Apps, die Bibliotheken mit native code einsetzen, der Rest wird sowieso entweder bei der Installation oder während der Ausführung nochmal durchkompiliert.
Google hat vor einiger Zeit den Druck auf App-Entwickler erhöht, auf modernere Android-Versionen zu zielen. Dazu gehörte die Pflicht, auch Binaries für ARM64 auszuliefern.
Mich würde ARMs Reaktion interessieren, wenn Google eine ARM-Emulation für RISC-V-Geräte anbieten würde...
Für Eagle-Layouts gibts eine schöne App die wohl nicht mehr funktionieren würde. Für einen harten Schnitt zu 64Bit hab ich Null Verständnis wenn das viele ältere Apps ausschließt.
Dann wird es wohl Zeit für den Entwickler, den C/C++-Code dadrin neu zu kompilieren. Die Zahl der tatsächlich ausgeschlossenen Apps (im Play Store) ist insgesamt winzig.
Ich habe mir vor ein paar Monaten eine ältere Open Source-App (inklusive in C geschriebener Bibliothek, also NDK-Abhängigkeit) vorgenommen und mal durchmodernisiert.
Der Code ist fast unverändert. Den File-Picker konnte ich rausschmeißen, weil Android das selbst kann (reduziert die Berechtigungsliste), und das Ergebnis startet jetzt ohne Kompatiblitätswarnung. Außerdem gibt es auf Geräten ohne 16:9-Bildschirm keine Darstellungsfehler mehr.
Die Hauptarbeit war das komplett neue Buildsystem - der Wechsel von irgendwelchen Eclipse-Plugins zu Android Studio und knapp 10 Versionen im NDK. Für einen Umstieg auf RISC-V oder ARM64 ist das irrelevant.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.