Hallo! Weiss jemand was genau dieses Risc-V ist bzw. warum es so sehnlichst erwartet wird ? Es soll ja "lizenzfrei" sein, was auch immer das genau bedeutet. Was ist mit der Hardware-Seite ? Ist der Microcode effizient oder wird da krampfhaft um die ausgereiften Platzhirschen-Patente herum gebastelt ? Wieso ist da überhaupt eine Patent-Lücke in der Leute etwas lizenzfrei (?) entwickeln können ? Müsste nicht schon alles patentiert sein was irgendwie Geld abwerfen könnte ?
:
Verschoben durch User
Ne Frage schrieb: > Was ist mit der Hardware-Seite ? Ist der Microcode effizient RISC und Microcode findet man nicht allzu oft zusammen. > Müsste nicht schon alles patentiert sein was > irgendwie Geld abwerfen könnte ? Nicht alles ist patentierbar und Patente laufen auch mal aus. Immerhin gibts Rechner nicht erst seit gestern und auch Zuse konnte schon addieren.
:
Bearbeitet durch User
Ne Frage schrieb: > Weiss jemand was genau dieses Risc-V ist bzw. warum es so sehnlichst > erwartet wird ? RISC-V ist eine ISA und die wird nicht sehnlichst erwartet, sondern ist schon da: https://riscv.org/specifications/ Ne Frage schrieb: > Es soll ja "lizenzfrei" sein, was auch immer das genau > bedeutet. Jeder darf Prozessoren mit RISC-V ISA bauen, ohne von irgendjemandem irgendwelche Klagen befürchten zu müssen. Bei ARM oder Intel ISAs sieht das ganz anders aus. Ne Frage schrieb: > Was ist mit der Hardware-Seite ? Das kommt auf die Implementierung an.
Ne Frage schrieb: > Weiss jemand was genau dieses Risc-V ist bzw. warum es so sehnlichst > erwartet wird ? Es soll ja "lizenzfrei" sein, was auch immer das genau > bedeutet. <Blick auf den Kalender werf> Ach, es ist ja schon wieder Freitag. Höchste Zeit für einen Troll-Thread. Alle genannten Fragen beantworten die Initiatoren höchstselbst und ausführlich auf diversen Webseiten. Außer vielleicht der Frage danach, warum es "sehnlich erwartet" wird. Da dürfte wohl jeder, der das wirklich tut, seine eigenen Gründe haben.
Diese RISC V Hardware ist auf jeden Fall für die Freitagsfrage gut: https://www.sifive.com/products/hifive1/
Ne Frage schrieb: > Weiss jemand was genau dieses Risc-V ist bzw. warum es so sehnlichst > erwartet wird ? Es soll ja "lizenzfrei" sein, was auch immer das genau > bedeutet. Eine moderne und durchdachte ISA für die jeder Hersteller CPUs entwickeln kann wird sicherlich positive Effekte auf den Markt haben.
A. K. schrieb: > Ne Frage schrieb: >> Was ist mit der Hardware-Seite ? Ist der Microcode effizient > > RISC und Microcode findet man nicht allzu oft zusammen. Ganz im Gegenteil; das ist sogar sehr verbreitet wie z.B. in den ganzen Core-i Prozessoren von Intel.
Johnny B. schrieb: > A. K. schrieb: > Ne Frage schrieb: > Was ist mit der Hardware-Seite ? Ist der Microcode effizient > > RISC und Microcode findet man nicht allzu oft zusammen. > > Ganz im Gegenteil; das ist sogar sehr verbreitet wie z.B. in den ganzen > Core-i Prozessoren von Intel. Sind die Intels RISC? Dachte das wären CISCs?
Christopher J. schrieb: > Jeder darf Prozessoren mit RISC-V ISA bauen Jaja, alles kann nichts muss. Jeder darf, aber kaum einer tuts. F: Warum sind Programme in Haskell sicher frei von Nebeneffekten? A: Weil sie nie einer ausführt. Daran erinnert mich dieses Pseudo-Hype um RISC-V. Wenn es dann mal wirklich konkurrenzfähige Controller zu kaufen gibt, inklusive der ganzen Toolchain, DANN sehen wir mal ganz langsam ob es überhaupt eine CHANCE gegen die etablierten hat. Vorher ist das alles gezerre um ein nicht erlegtes Bärenfell.
Johnny B. schrieb: >> RISC und Microcode findet man nicht allzu oft zusammen. > > Ganz im Gegenteil; das ist sogar sehr verbreitet wie z.B. in den ganzen > Core-i Prozessoren von Intel. Das sind keine RISC Prozessoren, sondern CISC Prozessoren, in denen wie dabei üblich die Befehle in Teiloperationen zerlegt werden. Die gelegentliche Zuschreibung eines RISC Core führt in die Irre. RISC Prozessoren mit Microcode kenne ich nur von IBMs POWER. Da gab es mindestens bis zur PowerPC Definition aufgrund der Komplexität mancher Befehle auch etwas Microcode. IBM hatte damals das C vorsorglich auch als "Cycles" bezeichnet, nicht als "Complexity".
:
Bearbeitet durch User
turn schrieb: > Sind die Intels RISC? Dachte das wären CISCs? Nach außen ja, intern schon seit Ewigkeiten nicht mehr. Der Befehlssatz ist CISC, aber das bewirkt praktisch nur eine Kompression. Das ist allerdings sehr willkommen, weil die Geschwindigkeit der CPUs wesentlich mehr gestiegen ist als die des RAM, so daß jeder Cache Miss hart reinhaut. Die Kompression verbessert die effektive Ausnutzung des Speicher-Interfaces. Der aufgeblähte Binärcode bei klassischem RISC, also mit festen Befehlslängen, ist in der Hinsicht heute nicht mehr tragbar. Er ist auch Blödsinn, weil der Decoder keinen relevanten Aufwand darstellt, nichtmal bei x86. Folglich ist ARM da auch schon von abgekommen. ARM-Code ist 32-bittig und aufgebläht, Thumb-1 16-bittig und lahm. Thumb-2 ist gemischt 16/32, mit der Code-Dichte etwa wie x86 und Performance wie ARM.
Nop schrieb: > weil die Geschwindigkeit der CPUs wesentlich > mehr gestiegen ist als die des RAM, so daß jeder Cache Miss hart > reinhaut. Die Kompression verbessert die effektive Ausnutzung des > Speicher-Interfaces. Es ist leichter, den Durchsatz vom Speicherinterface zu erhöhen als die Zugriffszeit zu verringern. Bezogen auf Code spielt die Zugriffszeit aufgrund der Sprungdichte üblichen Codes jedoch die grössere Rolle. Die Einsparung an Cache wiederum wird durch die grössere Komplexität der Dekodierung ausgeglichen. Folglich spielt in der Oberklasse die Codedichte für die Performance eine untergeordnete Rolle. > Der aufgeblähte Binärcode bei klassischem RISC, also mit festen > Befehlslängen, ist in der Hinsicht heute nicht mehr tragbar. Er ist auch > Blödsinn, weil der Decoder keinen relevanten Aufwand darstellt, nichtmal > bei x86. Man kann bei Prozessoren für PCs und Server die höhere Komplexität mit Aufwand erschlagen, der heute in Chipfläche nur noch wenig in Erscheinung tritt. Auf der Ebene von Controllern der Cortex M Klasse wäre es jedoch nach wie vor nicht vernachlässigbar. > Folglich ist ARM da auch schon von abgekommen. ARM-Code ist 32-bittig > und aufgebläht, Thumb-1 16-bittig und lahm. Thumb-2 ist gemischt 16/32, > mit der Code-Dichte etwa wie x86 und Performance wie ARM. Wobei die 64-Bit ARM Architektur weiterhin mit 32 Bit breiten Befehlen arbeitet. Thumb gibts nur in der 32-Bit Architektur.
Nop schrieb: >> Sind die Intels RISC? Dachte das wären CISCs? > > Nach außen ja, intern schon seit Ewigkeiten nicht mehr. Die Technik der Zerlegung der Befehle in Microcode-Operationen hat sich verändert. Fand dies dies früher stets per Microcode-ROM statt, werden die meisten Befehle heute direkt in Microcode-Operationen übersetzt, wenn man die Häufigkeit dynamisch im Befehlsfluss zählt. Klassisches Microcode-ROM wird nur vergleichsweise selten verwendet. Am Prinzip der Zerlegung von CISC Befehlen in eine oder mehrere Microcode-Operationen hat sich aber nichts geändert. Auch heute werden viele Befehle in mehrere Microcode-Operationen übersetzt, nur eben direkt durch die Dekoder, nicht über ROM. Die Begriffe CISC und RISC beziehen sich nicht auf die Implementierung eines Befehlssatzes, sondern auf die Struktur des Befehlssatzes selbst. Und die hat sich nicht vereinfacht.
:
Bearbeitet durch User
@Cyblord Es gibt ein paar sehr prominente Projekte, die auf RISC-V aufbauen, z.B. https://www.pulp-platform.org/ http://primeurmagazine.com/weekly/AE-PR-03-18-87.html "Jaja, alles kann nichts muss. Jeder darf, aber kaum einer tuts." "Daran erinnert mich dieses Pseudo-Hype um RISC-V. Wenn es dann mal wirklich konkurrenzfähige Controller zu kaufen gibt, inklusive der ganzen Toolchain, DANN sehen wir mal ganz langsam ob es überhaupt eine CHANCE gegen die etablierten hat. Vorher ist das alles gezerre um ein nicht erlegtes Bärenfell." Und genau wegen dieser Einstellung haben wir verschnarchten Europäer jahrzehntelang den Amerikanern und Chinesen das Feld überlassen und stellen nun ein wenig erstaunt fest, dass wir uns in einer heillosen Abhängigkeit befinden. Wir warten mal in aller Ruhe auf eine konkurrenzfähige Prozessorarchitektur, und wenn sie auf dem Markt ist, kaufen wir sie vielleicht. Dumm nur, dass niemand eine solche Architektur gebaut hat. Na macht nix, dann rücken wir halt unsere Schlafmützen zurecht und bleiben bei Intel, die funktionieren ja meistens ganz gut.
A. K. schrieb: > Der Begriff CISC bezieht sich nicht auf die Implementierung eines > Befehlssatzes, sondern auf die Struktur des Befehlssatzes selbst. Der aber eben nur ein Kompressionsschema für den dahinterliegenden RISC-Kern darstellt. Die ganze Unterscheidung RISC/CISC ist seit über 10 Jahren weitgehend obsolet geworden.
Nop schrieb: > Die ganze Unterscheidung RISC/CISC ist seit über 10 > Jahren weitgehend obsolet geworden. Nur in den oberen Sphären. Oder wieviele aktuelle x86 Mikrocontroller der Grössenordnung Cortex M kennst du? Unter den 16-Bittern gibts einige CISC ISAs, aber bei den 32-Bittern fällt mir nur Coldfire ein.
:
Bearbeitet durch User
A. K. schrieb: > Nur in den oberen Sphären. Also da, wo man CISC üblicherweise heute verortet, wenn man diesen Begriff überhaupt noch nutzt. > Oder wieviele aktuelle x86 Mikrocontroller der Grössenordnung Cortex M > kennst du? In dem Bereich spielt x86 gar nicht mit. Aber selbst Cortex-M ist, wie ich schon schrieb, kein klassisches RISC mehr und löst den Begriff dann von unten her auf.
Vancouver schrieb: > Und genau wegen dieser Einstellung haben wir verschnarchten Europäer > jahrzehntelang den Amerikanern und Chinesen das Feld überlassen und > stellen nun ein wenig erstaunt fest, dass wir uns in einer heillosen > Abhängigkeit befinden. Nun bin ich aber kein Chiphersteller. Sondern Anwender eines solchen Chips. Also ist es nicht meine Aufgabe um eine solche ISA einen Controller zu bauen. Und deshalb nehme ich es mir auch nicht heraus (im Gegensatz zu dir, denn du bist sicher auch kein Chiphersteller) anderen vorschreiben zu wollen, was sie gefälligst gut finden und verkaufen sollen. Hätten die Hersteller wirklich händeringend auf eine freie ISA wie RISC-V gewartet, gäbe es schon längst echte HW zu kaufen. Anstatt nur Proof-Of-Concept und Prototypen und Bastelbudenzeug. Warum zahlt ST gerne für ARM, wenn sie doch mit RISC-V kostenlos Reibach machen könnten? Außerdem kommt doch ARM ursprünglich aus Europa. RISC-V hingegen aus den USA. Wie genau soll uns jetzt RISC-V helfen aus der Abhängikeit von den USA zu entkommen?
:
Bearbeitet durch User
Nop schrieb: >> Nur in den oberen Sphären. > > Also da, wo man CISC üblicherweise heute verortet, wenn man diesen > Begriff überhaupt noch nutzt. MSP430 gefällig? Und Renesas R8C/M16C/M32C sind aber sowas von CISC. > In dem Bereich spielt x86 gar nicht mit. Eben. Warum wohl? Das war nicht immer so. 80188/186 adressierten den gehobenen Controller-Sektor, keine PCs. Auch später gab es noch 386EX und dergleichen. > Aber selbst Cortex-M ist, wie > ich schon schrieb, kein klassisches RISC mehr und löst den Begriff dann > von unten her auf. Thumb2 löst sich von der festen Länge, nicht aber von einem weiteren Kern der RISC Philosophie, nämlich der Trennung von Load/Store-Operationen von Rechenoperationen, in Verbindung mit einem grossen Registersatz.
:
Bearbeitet durch User
A. K. schrieb: > Ähm... Renesas R8C/M16C/M32C sind aber sowas von CISC. Aber auch TI > lässt sich nicht lumpen, mit den MSP430. Gut, mit denen hatte ich noch nie was. > Eben. Warum wohl? Das war nicht immer so. Vermutlich, weil die x86-Evolution auf Performance ging und nicht auf Energieverbrauch. Deswegen sind die lahmsten heutigen x86 gleichauf mit den schnellsten ARM, sowohl von der Geschwindigkeit als auch vom Energiebedarf. Das Lustige daran ist allerdings, daß RISC eigentlich mal angetreten war, um auch Geschwindigkeit zu bieten. Das war aber zu Zeiten, wo CISC noch richtiges CISC war und kein komprimierter externer Befehlssatz für einen internen RISC-Chip. > der Trennung von Load/Store-Operationen von Rechenoperationen, in > Verbindung mit einem grossen Registersatz. Ja, der Begriff wird eben aufgeweicht. Trotzdem sehe ich die Diskussion RISC/CISC als längst obsolet an.
Cyblord -. schrieb: > Hätten die Hersteller wirklich händeringend auf eine freie ISA wie > RISC-V gewartet, gäbe es schon längst echte HW zu kaufen. Anstatt nur > Proof-Of-Concept und Prototypen und Bastelbudenzeug. So ein Blödsinn. Schau Dir einfach mal die Geschichte von RISC-V an. Die Foundation, in der die Hersteller Mitglied werden können und in deren Board of Directors z.B. Nvidia und NXP vertreten sind, existiert erst seit August 2015. Das da vorher nix passiert ist, war doch klar. Jetzt sind die grossen Hersteller alle Mitglied der Foundation. Seit wann gibt es den Cortex-M23/M33? Seit Mitte 2016. Und wo ist Silizium? Richtig, nirgendwo. Nichtmal ne Ankündigung. Also wieso soll RISC-V Silizium nach Gründung der Foundation schneller auf den Markt kommen als die Controller vom lange etablierten Anbieter ARM? Im übrigen laufen RISC-V-Kerne schon bei den grossen Nutzern. Google hat bereits implementiert, ebenso NVidia und Western Digital. Ausser Dir bezeichnet diese Firmen wohl keiner als Bastelbuden. > Warum zahlt ST gerne für ARM, wenn sie doch mit RISC-V kostenlos Reibach > machen könnten? Wie kommst Du darauf, dass ST GERNE bezahlt? Und den Reibach werden sie machen, die entwickeln bereits Controller. > Außerdem kommt doch ARM ursprünglich aus Europa. RISC-V hingegen aus den > USA. Wie genau soll uns jetzt RISC-V helfen aus der Abhängikeit von den > USA zu entkommen? Weil RISC-V eine offene ISA ist. Die Mikroarchitektur muss von jedem selbst entwickelt werden. Das ist der entscheidende Vorteil.
Cyblord -. schrieb: > Anstatt nur > Proof-Of-Concept und Prototypen und Bastelbudenzeug. Und dann auch maßlos überteuert. ARM-Boards gibt's in ausgereift und leistungsfähig für 15 Euro, mit Cortex-M4, 168 MHz, 1 MB ROM und 200 kB RAM. Oh, und das, was es mit RISC-V gibt, hat nichtmal internes ROM, und die Architektur mit dem Harvard-Gehüsere macht zwar die Akademiker im Elfenbeinturm heiß, verspricht aber jede Menge Generve in der realen Entwicklung. Ich sag nur das Progmem-Gefrickel bei AVR.
Cyblord -. schrieb: > Warum zahlt ST gerne für ARM, wenn sie doch mit RISC-V kostenlos Reibach > machen könnten? Weil das jetzt schon fast der de-facto-Standard für viele Anwendungen ist? Da gibts gute Compiler, passende Bibliotheken, gutes Hardware-Angebot zu geringen Preisen und reichlich erfahrenes Personal auf dem Arbeitsmarkt. Bei den leistungsfähigeren Prozessoren gibts zusätzlich noch Linux-Distributionen mit gutem long term Support und guter Hardwareunterstützung. Bei einem exotischen Prozessor muss man sich den ganzen Kram selber zusammenbasteln. Das dauert und kostet.
John Doe schrieb: > Jetzt sind die grossen Hersteller alle Mitglied der Foundation. Oooh ach so. Die sind alle Mitglied. Ja wow. Das kostet nun auch nicht viel und man ist halt mal dabei. Mehr sagt das aber leider nicht aus. > Wie kommst Du darauf, dass ST GERNE bezahlt? Blöde Frage. Sie bezahlen obwohl es doch RISC-V gibt. > Und den Reibach werden sie machen, die entwickeln bereits Controller. Ja und dann schauen wir mal. Vielleicht werden die der Bringer schlechthin. Dann können alle Jubeln. Aber nicht VORHER. Sonst ist man nur Claqueur. > Weil das jetzt schon fast der de-facto-Standard für viele Anwendungen > ist? > Da gibts gute Compiler, passende Bibliotheken, gutes Hardware-Angebot zu > geringen Preisen und reichlich erfahrenes Personal auf dem Arbeitsmarkt. Na sieh an. Einer hats verstanden wie es läuft. Es soll ja immer noch Nerds geben (inzwischen gealtert) die können immernoch nicht verstehen wie VHS gewinnen konnte. Gegen ihre Betamax und Video2000 Systeme. Dann verdauen die grade noch, warum jeder Windows nutzt, und fast niemand ihr tolles offnes freies Linux. Geht ja gar nicht! Alle dumm. Die werden auch bald wieder dastehen, glotzen und rumheulen, warum jeder ARM nimmt, anstatt das super offene free-speech free-beer, free-sonstig RISC-V. Die kapieren das nie.
:
Bearbeitet durch User
Da sieht wohl jemand seine Fälle davon schwimmen? Warum ist ARM erfolgreich? Das ist doch total blöd, den Core extra einzubinden. Es gab doch schon Hersteller von Mikrocontrollern? Jetzt müssen wir bei Einplatinenrechnern, auf denen ein volles Linux laufen möge, aus einer Vielzahl von Prozessoren auswählen, die alle einem Standard folgen. Es wäre viel besser, alle Raspberries und Smartphones müssten Intel verwenden. Am besten noch mit closed-source compiler. Und warum gibt es gcc? Das ist doch total blöd. Es gab doch schon kommerzielle Compiler, die damals auch performanter waren als gcc. Und jetzt RISC-V. Das wäre doch total blöd, wenn (fast) alle uCs (und mehr) nur noch auf opensource ISAs basieren würden. Opensource ist der evil schlecht hin. Hat bisher nur Nachteile für die Nutzer gebracht. Der Grund, warum es das bisher nicht gab, ist folgender: Es gab es schon, aber der gemeinsame Nenner fehlte. RISC-V eignet sich für kleine uC genauso wie für Desktop-Linux und Supercomputer.
Lars R. schrieb: > RISC-V eignet sich für kleine uC genauso wie für Desktop-Linux und > Supercomputer. "Einer für alle" ist ja auch so ein tolles Konzept. Das hat doch bisher noch nie funktioniert. Warum will man das?
Cyblord -. schrieb: > Lars R. schrieb: >> RISC-V eignet sich für kleine uC genauso wie für Desktop-Linux und >> Supercomputer. > > "Einer für alle" ist ja auch so ein tolles Konzept. Das hat doch bisher > noch nie funktioniert. Warum will man das? Die RISC-V ISA spec hat mehr als eine Option und sogar bereits Versionsnummern. Schau sie Dir an. gcc: Einer für alle. Warum will man das? Wegen dem Standard und der Kompatibilität natürlich. Das hast Du doch selbst angesprochen, wenn auch bzgl. der Anwendung etwas eingegrenzter im Sinne von "ARM kann für vieles verwendet werden"
:
Bearbeitet durch User
Nop schrieb: > Oh, und das, was es mit RISC-V gibt, hat nichtmal internes ROM, und die > Architektur mit dem Harvard-Gehüsere macht zwar die Akademiker im > Elfenbeinturm heiß, verspricht aber jede Menge Generve in der realen > Entwicklung. Ich sag nur das Progmem-Gefrickel bei AVR. Hat da mal wieder jemand keine Ahnung? ARM Kerne haben auch getrennte Busse für Instruktionen und Daten. Diese gehen nur auf dieselbe Busmatrix. Somit kann der I-Bus Instruktionen aus dem Flash holen und der D-Bus im RAM rumspielen. Bei bedarf kann der I-Bus aber auch in den RAM wenn man da unbedingt Code haben will. Das nennt man dann "modified Harvard". So wird das bei den RISCV auch kommen. Warum macht man das? RISCV und ARM sind pipelined Kerne die holen sich also jeden Takt ne neue Instruktion, das würde aber mit Datenzugriffen kollidieren. ARM7 war der letzte Kern mit nem Singlebus. ARM9 hatte dann diese getrennt und der Speedup ist schon gewaltig. Nen Dozent meinte mal was von 30%. Beim AVR KÖNNTE! man da auch ne Busmatrix einbauen, aber 16Bit Adressraum sind dazu etwas zu klein.
Cyblord -. schrieb: > Daran erinnert mich dieses Pseudo-Hype um RISC-V. Wenn es dann mal > wirklich konkurrenzfähige Controller zu kaufen gibt, inklusive der > ganzen Toolchain, GCC:
1 | RISC-V support [2017-02-02] |
2 | Support for the RISC-V ISA was added, contributed by Palmer Dabbelt and Andrew Waterman. |
Ist also in der aktuellen v7 Release bereits verfügbar. Binutils: Ab v2.28. Newlib, GlibC und LLVM gibt's bereits mindestens auf github.
Toolchain ist mit gcc kein grosses Problem mehr, erst recht, wenn es was RISC-Verwandtes ist. Sonst hätte Xilinx für den Microblaze auch nichts zusammenbekommen, und die waren in SW-Sachen schon immer etwas "herausgefordert". Auch vor fast 20 Jahren hat die Popel-Firma Axis ihre Eigenbau-Etrax/CRIS-CPUs für die Webcams mit gcc und Linux versorgt.
Der Microblaze riecht ja auch recht nach MIPS. Offiziell basiert er auf dem DLX, aber der kommt von Hennesy und Petterson. Die beiden kenn wir doch schon von MIPS ;) Sogar .sbss und .sdata gibts. Man siehts auch sehr an den Registern und dem befehlsuafbau. Also "80%" des mblaze gcc waren quasi schon fertig.
Cyblord -. schrieb: > Warum zahlt ST gerne für ARM, wenn sie doch mit RISC-V kostenlos Reibach > machen könnten? Als der STM32 entwickelt wurde, gab es RISC-V noch nicht. Und jetzt haben sie wohl den Umstieg verschlafen (oder ruhen sich auf den Erfolgen des STM32 aus, ohne hinreichend an Morgen zu denken). Philipp
Philipp Klaus K. schrieb: > Cyblord -. schrieb: >> Warum zahlt ST gerne für ARM, wenn sie doch mit RISC-V kostenlos Reibach >> machen könnten? > > Als der STM32 entwickelt wurde, gab es RISC-V noch nicht. Und jetzt > haben sie wohl den Umstieg verschlafen (oder ruhen sich auf den Erfolgen > des STM32 aus, ohne hinreichend an Morgen zu denken). Ich denke sie ruhen sich schon nicht auf dem Erfolg aus, denn sie integrieren ja laufend neue Cores wie zuletzt den ARM Cortex-M7 in die STM32H7 Serie. Sie haben sich auch Softwaremässig gewappnet indem sie Atollic einverleibt haben und das TrueStudio verwendet den GCC Compiler, welcher gemäss Aussagen von weiter oben in diesem Thread schon Code für den RISC-V erzeugen kann. Von da her könnte ich mir vorstellen oder hoffe es zumindest, dass ST diesen Plan B fertig in der Schublade hat, sollte RISC-V einestages einschlagen wie eine Bombe.
:
Bearbeitet durch User
Nachdem Huawei von der ARM-Entwicklung "abgeschnitten" wurde https://www.theverge.com/2019/5/22/18635326/huawei-arm-chip-designs-business-suspension könnte sich die Verbreitung u.U. durchaus beschleunigen... Jörg
Joerg W. schrieb: > Nachdem Huawei von der ARM-Entwicklung "abgeschnitten" wurde > > https://www.theverge.com/2019/5/22/18635326/huawei-arm-chip-designs-business-suspension Das ist ja wirklich besorgniserregend! > könnte sich die Verbreitung u.U. durchaus beschleunigen... Zu begrüssen wäre es. RISC-V ist Open-Source für Hardware, hier für die CPU selbst :-)
:
Bearbeitet durch User
Die USA sind schon lustig. Erst fleißig jahrzehntelang Technologie Know-How kostenlos nach China exportieren und jetzt plötzlich doch die Zusammenarbeit "kündigen" und Verbote aussprechen weil sie zu gefährlich geworden sind. Nun.
Kann jemand ein RISC-V Board empfehlen für den Einstieg und zum Lernen? Sollte Linux drauf laufen.
In dieser Nano-Drohne läuft scheinbar ein Risc-V-Prozessor mit sehr wenig Leistungsaufnahme: https://www.youtube.com/watch?v=JKY03NV3C2s
Philipp Klaus K. schrieb: > Cyblord -. schrieb: >> Warum zahlt ST gerne für ARM, wenn sie doch mit RISC-V kostenlos Reibach >> machen könnten? > > Als der STM32 entwickelt wurde, gab es RISC-V noch nicht. Und jetzt > haben sie wohl den Umstieg verschlafen (oder ruhen sich auf den Erfolgen > des STM32 aus, ohne hinreichend an Morgen zu denken). > > Philipp Nein, sie liefern das, was die Kunden wollen. Leider läuft das nicht viel anders, als bei den Human Resource Managern. Die Einkäufer träumen davon, dass alle Hersteller untereinander kompatibel sind und man idealerweise Ausschreibungen machen kann, bei denen nur noch der Preis verglichen werden muss/kann. Deswegen ist ARM mal so groß geworden, alle proprietären Cores haben die Träume nicht befruchtet. Und als ARM groß wurde mit den ARM7 und ARM9 war das bei weitem nicht die schnellste oder sparsamste Technologie, aber schon damals diejenige, wo man am ehesten den Lieferanten wechseln konnte. Aus Sicht der Einkäufer ist ARM die perfekte Lösung, deswegen wird das in den grossen Firmen vorgeschrieben. Davon profitieren dann auch die HR-Manager, man muss nur noch nach ARM Entwicklern suchen. Heute einen Controller zu verkaufen, der nicht ARM ist, ist faktisch unmöglich. Da schickt einem der Einkäufer nicht mal die Ausschreibung. Gruß Axel
Axel L. schrieb: > man muss nur noch nach ARM Entwicklern suchen. Was ist denn ein "ARM-Entwickler"? Wodurch unterscheidet der sich von einem "RISC-V"-Entwickler? Ich kenn ein paar Entwickler und die entwickeln alle in C oder C++. Und bei jedem Wechsel von einem ARM-Controller auf den nächsten ARM-Controller eines anderen Herstellers müssen die wieder wochenlang Datenblätter von komplett anderen Timern, ADC, DAC, USART, DMA, SPI, I2C, etc. und komplett anderen Herstellerlibraries wälzen um Dinge die sie auf der alten Hardware gemacht haben auf der neuen ebenso hinzubekommen. Ob da nun allerdings ein ARM oder ein RISC-V oder uralter 8051 oder sonstwas als CPU drin werkelt hat darauf kaum mehr Einfluss als das Material des Fußbodens unter dem Schreibtischstuhl: Auf einem rollt er schneller, auf einem rollt er leiser, auf einem muß man absteigen und schieben, aber großartig umlernen muss man sicherlich nicht und seine Funktion erfüllt er überall. Und oberhalb der Sitzfläche verhält er sich ununterscheidbar identisch.
Bernd K. schrieb: > Axel L. schrieb: >> man muss nur noch nach ARM Entwicklern suchen. > > Was ist denn ein "ARM-Entwickler"? Wodurch unterscheidet der sich von > einem "RISC-V"-Entwickler? > Ich hatte schon einen Grund, warum ich "HR-Manager" geschrieben hatte. > Ich kenn ein paar Entwickler und die entwickeln alle in C oder C++. Und > bei jedem Wechsel von einem ARM-Controller auf den nächsten > ARM-Controller eines anderen Herstellers müssen die wieder wochenlang > Datenblätter von komplett anderen Timern, ADC, DAC, USART, DMA, SPI, > I2C, etc. und komplett anderen Herstellerlibraries wälzen um Dinge die > sie auf der alten Hardware gemacht haben auf der neuen ebenso > hinzubekommen. > > Ob da nun allerdings ein ARM oder ein RISC-V oder uralter 8051 oder > sonstwas als CPU drin werkelt hat darauf kaum mehr Einfluss als das > Material des Fußbodens unter dem Schreibtischstuhl: Auf einem rollt er > schneller, auf einem rollt er leiser, auf einem muß man absteigen und > schieben, aber großartig umlernen muss man sicherlich nicht und seine > Funktion erfüllt er überall. Und oberhalb der Sitzfläche verhält er sich > ununterscheidbar identisch. Ich hatte schon einen Grund, warum ich "Einkäufer" geschrieben hatte. Vielleicht hätte "Procurement Manager" meine Aussage besser verdeutlicht. Natürlich weiß jeder, der sich mit der Materie auskennt, dass das nicht so ist. Aber in den entscheidenden Etagen wissen die das eben oft nicht. Ich habe in der Zeit der ARM7 und ARM9 bei meiner damaligen Firma die Vertriebsleute unterstützt, bei den meisten Kunden musste es ARM sein, oder eben alternativ ARM, und wenn das nicht ging, konnte man auch einen ARM anbieten. Da ging es nicht um Performance oder Toolchain. Die war bei ARM damals noch nicht so toll. Aber ARM war das heisse Ding. Ganz wenige Kunden haben auch einen MIPS eingesetzt, aber die haben das mitlerweile bitter bereut. Ich glaube nicht, dass man ohne massive äussere Zwänge (wie bei Huawei) heute einen Kunden auf eine andere Technologie bringen würde. Gruß Axel
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.