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 ?
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.
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.
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".
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.
@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.
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?
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.
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.
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"
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.
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.
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
