Forum: Offtopic Risc-V gut ?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Ne Frage (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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 Moderator
von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
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
von Christopher J. (christopher_j23)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Axel S. (a-za-z0-9)


Bewertung
-2 lesenswert
nicht lesenswert
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.

von chris (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Diese RISC V Hardware ist auf jeden Fall für die Freitagsfrage gut:

https://www.sifive.com/products/hifive1/

von Isso (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Johnny B. (johnnyb)


Bewertung
-5 lesenswert
nicht lesenswert
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.

von turn (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von Cyblord -. (cyblord)


Bewertung
-3 lesenswert
nicht lesenswert
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.

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
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
von Nop (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
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.

von (prx) A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
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
von Vancouver (Gast)


Bewertung
0 lesenswert
nicht lesenswert
@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.

von Nop (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
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.

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
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
von Nop (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Cyblord -. (cyblord)


Bewertung
-3 lesenswert
nicht lesenswert
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
von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
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
von Nop (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von John Doe (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Nop (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Schreiber (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Cyblord -. (cyblord)


Bewertung
-1 lesenswert
nicht lesenswert
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
von Lars R. (lrs)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Cyblord -. (cyblord)


Bewertung
-5 lesenswert
nicht lesenswert
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?

von Lars R. (lrs)


Bewertung
0 lesenswert
nicht lesenswert
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
von Mw E. (Firma: fritzler-avr.de) (fritzler)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Johann L. (gjlayde) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
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.

von Georg A. (georga)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Philipp Klaus K. (Firma: Albert-Ludwigs-Universität) (pkk)


Bewertung
1 lesenswert
nicht lesenswert
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

von Johnny B. (johnnyb)


Bewertung
0 lesenswert
nicht lesenswert
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
von Joerg W. (joergwolfram)


Bewertung
3 lesenswert
nicht lesenswert
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

von Mutluit M. (mutluit)


Bewertung
-1 lesenswert
nicht lesenswert
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
von Mac G. (macgyver0815)


Bewertung
2 lesenswert
nicht lesenswert
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.

von Mutluit M. (mutluit)


Bewertung
-1 lesenswert
nicht lesenswert
Kann jemand ein RISC-V Board empfehlen für den Einstieg und zum Lernen?
Sollte Linux drauf laufen.

von H-G S. (haenschen)


Bewertung
0 lesenswert
nicht lesenswert
In dieser Nano-Drohne läuft scheinbar ein Risc-V-Prozessor mit sehr 
wenig Leistungsaufnahme:

https://www.youtube.com/watch?v=JKY03NV3C2s

von Andreas R. (daybyter)


Bewertung
1 lesenswert
nicht lesenswert
https://github.com/darklife/darkriscv

300 Zeilen Verilog und gerade mal 1000 LE...beeindruckend...

von Axel L. (axel_5)


Bewertung
0 lesenswert
nicht lesenswert
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

von Bernd K. (prof7bit)


Bewertung
3 lesenswert
nicht lesenswert
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.

von Axel L. (axel_5)


Bewertung
0 lesenswert
nicht lesenswert
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

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail, Yahoo oder Facebook? Keine Anmeldung erforderlich!
Mit Google-Account einloggen | Mit Facebook-Account einloggen
Noch kein Account? Hier anmelden.