Schau mal hier: https://www.espressif.com/en/news/ESP32-P4 So langsam merkt man das ARM bald in Schwitzen kommen wird. :) Olaf
olaf schrieb: > So langsam merkt man das ARM bald in Schwitzen kommen wird. :) Und morgen, liebe Kinder, erzählt euch Olaf einen neues Märchen.
Jochen schrieb: > 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
olaf schrieb: > 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.
Harry L. schrieb: > 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.
:
Bearbeitet durch User
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(
Guido Körber schrieb: > 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.
:
Bearbeitet durch User
Guido Körber schrieb: > 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.
(prx) A. K. schrieb: > 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.
Guido Körber schrieb: > 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
:
Bearbeitet durch User
Beitrag #7315388 wurde von einem Moderator gelöscht.
Beitrag #7315401 wurde von einem Moderator gelöscht.
Beitrag #7315407 wurde von einem Moderator gelöscht.
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.
MCUA schrieb: > 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.
:
Bearbeitet durch User
Beitrag #7315442 wurde von einem Moderator gelöscht.
Jörg W. schrieb: > 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?
Harry L. schrieb: > 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.
Falk B. schrieb: > 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...
> 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
olaf schrieb: > Es gab ein Handbuch in Deutsch! Das waren eben andere Zeiten. Ich besitze ein deutsches Handbuch zur 68000, von Motorola höchstselbst.
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.
Guido Körber schrieb: > 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?
Matthias T. schrieb: > 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.
:
Bearbeitet durch User
Falk B. schrieb: > Jörg W. schrieb: >> 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.
> 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.
MCUA schrieb: > 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.
(prx) A. K. schrieb: > Das waren eben andere Zeiten. Ich besitze ein deutsches Handbuch zur > 68000, von Motorola höchstselbst. Vom Chefdesigner signiert? ;-)
>> 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.
Falk B. schrieb: > 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.
MCUA schrieb: > 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.
Es ist mehr Aufwand einen 'CompareAndJump'-Befehl zu implementieren, als einen 'Branch'-Befehl (der lediglich ein Flag auswertet (das sowiso schon da ist)).
MCUA schrieb: > 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
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.
MCUA schrieb: > 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.
:
Bearbeitet durch User
MCUA schrieb: > 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 …
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.
Jörg W. schrieb: > 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 | l1: ADC eax, [esi,edx*4] |
2 | DEC edx |
3 | JNS l1 |
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 | mem(EDX) => r / 4 Takte |
2 | r => ADC => C-Flag / 1 Takt |
3 | C-Flag => DEC => EDX,C-Flag / 1 Takt |
4 | mem(EDX) => r |
5 | r => ADC => C-Flag |
6 | edx,C-Flag => DEC => EDX,C-Flag |
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.
:
Bearbeitet durch User
Maxe schrieb: > 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 ;-).
:
Bearbeitet durch User
MCUA schrieb: > 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.
> 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.
MCUA schrieb: > 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.
>> 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.
> 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 | int64_t add64 (int64_t a, int64_t b) |
2 | {
|
3 | return a + b; |
4 | } |
1 | add64: |
2 | add a1, a1, a3 |
3 | add a0, a0, a2 |
4 | sltu a2, a0, a2 |
5 | add a1, a1, a2 |
6 | ret |
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.
:
Bearbeitet durch User
> 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.
Johann L. schrieb: > 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.
:
Bearbeitet durch User
> 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.
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?
rbx schrieb: > 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.
:
Bearbeitet durch User
MCUA schrieb: >> 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.
>> 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.
MCUA schrieb: > 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.)
Jörg W. schrieb: > Bei deiner Kompetenz ist ihnen da > wirklich was entgangen. Eine Diskussion mit MCUA ist ebenso sinnvoll wie mit Josef-Mr Hedaxdezimal . . .
> Eine Diskussion mit MCUA ist ebenso sinnvoll wie mit Josef-Mr > Hedaxdezimal . . . Vor all Dingen sagt du das
> 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.
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. 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.
:
Bearbeitet durch User
> 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.
Udo K. schrieb: > 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
MCUA schrieb: >> 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.
> 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
Matthias T. schrieb: >> >> 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, 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.
Udo K. schrieb: >> 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.
Udo K. schrieb: > 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. Udo K. schrieb: > 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. Matthias T. schrieb: > 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.
:
Bearbeitet durch User
Matthias T. schrieb: > 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.
:
Bearbeitet durch User
(prx) A. K. schrieb: > 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.
(prx) A. K. schrieb: >> 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.
Matthias T. schrieb: > 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.
MCUA schrieb: > 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...
Grummler schrieb: > 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.
Udo K. schrieb: > 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...
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. 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.
:
Bearbeitet durch User
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
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.
Sonntags immer schrieb: > 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.
Grummler schrieb: > 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 )
Sonntags immer schrieb: > 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
(prx) A. K. schrieb: > 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. > > 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...
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
(prx) A. K. schrieb: > 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
Nop schrieb: > 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
Nop schrieb: > 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.
:
Bearbeitet durch User
(prx) A. K. schrieb: > 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.
Nop schrieb: > 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.
:
Bearbeitet durch User
(prx) A. K. schrieb: > 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.
(prx) A. K. schrieb: > 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.
> 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.
> 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.
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
olaf schrieb: > 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
:
Bearbeitet durch User
olaf schrieb: > 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!
> 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
olaf schrieb: > Gut vergleichen kann man das Teil > vermutlich mit einem STM32F030F4P6TR. Allerdings ist der CH32V003 offenbar als pinkompatibler Ersatz für den STM8S003 gedacht.
Nop schrieb: > 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... Jan V. schrieb: > 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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.