www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik RISC oder CISC - Was ist besser?


Autor: Lenny (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

Kann man generell sagen das entweder RISC oder CISC - Architektur besser 
ist?

Oder haben beide ihre Einsatzgebiete?

Was muss man beim programmieren beachten wenn man RISC oder CISC hat?


Gruss
Lenny

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nichts ist besser und alles ist besser, sowohl bei der einen als auch 
bei der anderen Architektur. Informiere Dich über Vor- und Nachteile der 
Architekturen und entscheide, welche für Deine Anwendung in Frage kommt.

>Was muss man beim programmieren beachten wenn man RISC oder CISC hat?

Daß das Programm den Anforderungen entsprechend läuft vielleicht?

Autor: jack (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fragen, die so einfach ins Blaue hinein gehen, haben wenig Sinn.

Sammle ein wenig Programmiererfahrung, dann weißt du wenigstens,
worüber du redest.

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
www.gidf.de gibt dir die Antwort. Einfach "RISC CISC" eingeben.

Autor: Lenny (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Fragen, die so einfach ins Blaue hinein gehen, haben wenig Sinn.

Was heisst da ins blaue hinein??

Ich hab noch nie gehört, dass jemand seien uP nach RISC oder CISC 
ausgesucht hat. Deshalb frag ich obs überhaupt draufan kommt!

Autor: Lothar Lehmann (lole)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Beim Programmieren musst Du gar nichts beachte, solange Du eine höhere 
Programmiersprache benutzt. RISC hat eben einen Reduzierten Istruction 
Set, arbeitet dafür Befehe meist in einem Takt ab. CISC hat mächtigere 
Befehle, die dafür öfter gerne einige Takte brauchen. Ich hoffe das 
reicht erst mal. Wikipedia hat sicher mehr dazu zu sagen.
Grüsse

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schaut man sich die 2Mrd. Transistoren bei x86 an, scheint CISC recht 
erfolgreich zu sein. Zumindest bei MS-Maustreibern.

Autor: Lenny (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Beim Programmieren musst Du gar nichts beachte, solange Du eine höhere
>Programmiersprache benutzt. RISC hat eben einen Reduzierten Istruction
>Set, arbeitet dafür Befehe meist in einem Takt ab. CISC hat mächtigere
>Befehle, die dafür öfter gerne einige Takte brauchen. Ich hoffe das
>reicht erst mal. Wikipedia hat sicher mehr dazu zu sagen.

Ja danke, ich weiss schon was RISC und CISC ist. Ich frag mich nur was 
unter dem Strich besser ist.


>Schaut man sich die 2Mrd. Transistoren bei x86 an, scheint CISC recht
>erfolgreich zu sein.

Das x86 erfolgreich ist muss doch überhaupt nichts damit zu tun haben ob 
RISC oder CISC besser ist. Hat ich einfach als Standard durchgesetzt.

Autor: jack (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Was heisst da ins blaue hinein??

Auf diese Frage gibts eine gute Antwort:

>Schaut man sich die 2Mrd. Transistoren bei x86 an, scheint CISC recht
>erfolgreich zu sein. Zumindest bei MS-Maustreibern.

Hier kommt das "ins Blaue hinein" sehr deutlich zum Ausdruck.

Autor: Karl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Schaut man sich die 2Mrd. Transistoren bei x86 an, scheint CISC recht
>erfolgreich zu sein. Zumindest bei MS-Maustreibern.

Erstens ist ein großer Teil der Transistoren Cache, hat also mit 
CISC/RISC erstmal nichts zu tun. Zweitens kann man heutige x86er nicht 
genau einordnen, weil sie nur noch die ISA (Instruction Set 
Architecture) mit ihren CISC Vorfahren gemeinsam haben. Intern läuft es 
dann doch wieder RISC-artig ab. Wie so oft sind die Übergänge fließend.

Autor: Lothar Lehmann (lole)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn Du weißt, was Du erschlagen willst, wirst Du auch wissen, was Du 
einsetzen musst.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lenny wrote:
>>Beim Programmieren musst Du gar nichts beachte, solange Du eine höhere
>>Programmiersprache benutzt. RISC hat eben einen Reduzierten Istruction
>>Set, arbeitet dafür Befehe meist in einem Takt ab. CISC hat mächtigere
>>Befehle, die dafür öfter gerne einige Takte brauchen. Ich hoffe das
>>reicht erst mal. Wikipedia hat sicher mehr dazu zu sagen.
>
> Ja danke, ich weiss schon was RISC und CISC ist. Ich frag mich nur was
> unter dem Strich besser ist.

Oh gott.

do
{
    Lese von Beginn;
} while (DuStellstDirImmernochDieseFrage);

Autor: Stefan Helmert (Firma: dm2sh) (stefan_helmert)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich bin mal mutig und sage RISC ist besser. Bei CISC-CPUs werden 
entweder µCode verwendet oder die CISC-Befehle direkt RISC umgeformt. 
RISC ist schneller, flexibler, sparsamer da sehr oft nur einfache 
Befehle gebraucht werden. Möglicherweise sind bei CISC-Systemen die 
Programme kleiner und es werden weniger Programmspeichrzugriffe 
erforderlich, weil nur ein Befehl geholt werden muss der viel bewirkt 
anstatt mehrere die wenig bewirken, doch heute ist Speicher billig und 
die statische Verlustleistung größer als die dynamische, weshalb ein 
paar Speicherzgriffe mehr auch nicht schaden. Der deutlich einfacher 
aufgebaute RISC aber weniger statische Verlutleistung.
Da man gemerkt hat, dass RISC ein paar Nachteile hat, hat man einfach 
später noch bestimmte CISC-Befehle in RISC integriert, jedoch nicht 
irgendwelche, sondern nur die wichtigsten. Man merkte, das man oft 
Datentransportbefehle braucht, also hat man welche übernommen die 
mehrere Register in den Speicher kopieren. Das ist bei ARM der Fall.
Der RISC verdrängt den CISC in vielen Bereichen. Man denke an die 
mobilen Anwendungen (Handy, PDA, Navi,...). Auch in Spielekonsolen 
findet er Einsatz.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Stefan Helmert (stefan_helmert)

>ich bin mal mutig und sage RISC ist besser. Bei CISC-CPUs werden
>entweder µCode verwendet oder die CISC-Befehle direkt RISC umgeformt.

Was Pentium Und Athlon seit Jahren machen, kann also nicht so falsch 
sein.

>paar Speicherzgriffe mehr auch nicht schaden. Der deutlich einfacher

Naja, damit wäre ich vorsichitg. Ohne Caches geht da heute fast nix 
mehr.

>aufgebaute RISC aber weniger statische Verlutleistung.

???
Bei CMOS? Wir reden hier glaub ich auch nicht über die Tuning Tricks von 
Intel, die massive Leckströme in Kauf nehmen um ein paar hundert MHz 
mehr Takt in Kauf zu nehmen. Die schnellsten Intel-CPUs sollen bis zu 
50% ihres Stroms als Leckstrom dadurch verbrauchen :-0

>Datentransportbefehle braucht, also hat man welche übernommen die

SIMD, Singe Instruction, Multiple Data, also MMX, 3D NOW etc.)

>mehrere Register in den Speicher kopieren. Das ist bei ARM der Fall.

Das ist aber schon eher DMA.

MFG
Falk

Autor: David (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
der trend geht klar richtung risc... somit dürfte die frage wohl 
beantwortet sein...

--> der x86 stammt ursprünglich von einem cisc ab und wurde richtung 
risc vergewaltigt... sprich sie haben gebastelt, weil sie die kosten für 
eine kommplete risc neuentwicklung scheuten...

Autor: mr.chip (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kann man so wirklich nicht sagen. Nur schon die Definition von 'besser' 
ist schwer. Rechenleistung? Stromverbrauch? Leichter Vorteil
Einfachheit beim Design? Einfachheit in der Produktion? Flexibilität?

Und definiere mir dann mal RISC* und CISC* präziser. Wie vergangene 
Diskussionen zeigen, kann man hier nach verschiedenen Gesichtspunkten 
die Grenze ziehen, moderne PC-Prozessoren sind teilweise kaum 
einzuordnen.

Grundsätzlich ist jedes CISC* auch ein bisschen RISC*, wobei halt noch 
der Mikrocode dazwischen steht.


* Ich definiere für mich RISC und CISC rein nur über die 
Hardware-Implementierung, nicht über den Instruktionssatz. RISC: Daten 
rutschen nach einem vorgegebenen Schema durch die CPU, insbesondere sind 
die einzelnen Komponenten direkt und eigenständig verdrahtet, so dass 
Pipelining möglich wird. CISC: Daten werden vom Mikrocode Schritt für 
Schritt an die verschiedenen Komponenten angelegt, wobei insbesondere 
allgemeine Bus-Strukturen vorkommen können und erst der Mikrocode 
bestimmt, welche Prozessorkomponente ihre Daten anlegt bzw. übernimmt.

Autor: I_ H. (i_h)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die meisten Befehle werden auf x86ern aber in Hardware dekodiert, nicht 
vom Mikrocode ;).

Es ist schwer zu sagen was "besser" ist. Es ist auf jeden Fall 
schwieriger CISC performant umzusetzen. Andererseits hat man bei einer 
performanten Umsetzung diverse Vorteile, zB. ist CISC Code deutlich 
kompakter als RISC. Und CISC erlaubt flexiblere Implementierungen, weil 
komplexere Befehle nicht so stark an die Hardware angelehnt sind.

Im Endeffekt ist beides gut. Schau dich mal um, x86 CPUs sind mit die 
schnellsten CPUs auf dem Markt, und vor allem die vielseitigsten. 
Reinrassige RISCs wie der Power oder auch Designs die extra auf 
paralleles Rechnen ausgelegt wurden (zB. EPIC im Itani(c)um) sind nicht 
viel besser, und fertigungstechnisch der absolute Albtraum ('n Itanium 
ist ca. 10mal so groß wie ein Opteron...).

Autor: Michael König (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
> Kann man generell sagen das entweder RISC oder CISC - Architektur besser
> ist?

Hängt von der Anwendung ab. Bei CISC hat man meist bessere Codedichte, 
RISC ist üblicherweise schneller, da die Decoder- und 
Ausführungseinheiten einfacher zu realisieren sind.

Im Mikrocontrollerbereich sind echte RISCs selten, da die meisten immer 
noch die Möglichkeit haben irgendwie direkt die Portpins zu 
manipulieren, was dem RISC-Konzept komplett widerspricht.

Es ist aber klar, daß alle heutigen Prozessoren, wenn sie auch nur 
annähernd in der Geschwindigkeit mithalten, intern immer eine 
RISC-ähnliche Implementierung haben, ganz gleich wie CISC-mäßig die 
Architekur sein mag. Das gilt vor allem für die CPUs von Intel und AMD, 
denn wenn die nicht RISC-Know-How für ihre Prozessorkerne übernommen 
hätten (und etwas später noch sehr viel Optimierungswissen in Form von 
ehemaligen Alpha-Designern eingekauft hätten), wären sie schon vor 
Jahren im Desktop- und Server-Bereich von den RISC-Prozessoren abgehängt 
worden.
Da sich x86 aber aufgrund der etablierten Architektur sehr gut verkauft, 
war wohl genug Geld für Investitionen und den Aufwand der Übersetzung 
einer verkorksten ISA in RISC-ähnliche Code für den Kern vorhanden.

Da der Begriff RISC gerne nicht vollkommen korrekt ausgelegt wird, hier 
noch eine genauere Definition:
"RISC" steht zwar für "Reduced Instruction Set Computer", aber ganz so 
wörtlich darf man dieses Akronym von David Patterson doch nicht 
auslegen, da seine Definition doch deutlich anders aussieht.
(In einem Buch habe ich die alternative Interpretation "Reduced 
Instruction Set Complexity" gefunden.)

* Load/Store-Architektur, d.h. nur spezielle Load/Store-Instruktionen 
sind für den Datenaustausch zuständig. Alle Datenmanipulationen finden 
ausschließlich auf Registern statt. Hier unterscheiden sich einige 
Embedded-RISC (beispielsweise SuperH kann Bitoperationen auf 
Speicherstellen durchführen), damit man direkt auf Ports zugreifen kann.

* Eine große Zahl an Universalregistern. Groß ist dabei relativ, 
üblicherweise aber ab 16 aufwärts, die meisten Desktop-RISCs haben 32 
Register, von denen aber häufig eines immer Null ist. Universalregister 
heißt dabei, daß sie gleichermaßen für Daten und Adressen und von allen 
Instruktionen verwendet werden können. Zugunsten der Codedichte machen 
einige Embedded-RISC hier auch Eingeständnisse.

* Uniforme und einfache Instruktionscodierung. D.h. alle Instruktionen 
haben die gleiche Länge und es gibt nur sehr wenige Instruktionsformate. 
Ein "typischer" RISC käme beispielsweise mit drei Formaten aus: Opcode 
mit drei Registern, Opcode mit zwei Registern und einer Konstante, 
Opcode und Adresse.
In der Praxis sieht das gelegentlich auch etwas anders aus. ARM hat 
erstaunlich viele unterschiedliche Formate und bei der Länge ist man 
auch nicht immer einheitlich. ARM schaltet zumindest zwischen Modi mit 
unterschiedlichen Längen um (32-Bit ARM / 16-Bit Thumb), andere wie 
TriCore können auch verschieden lange Instruktionen mischen.

* Die meisten Instruktionen sind primitiv genug, daß mittels Pipelining 
eine Instruktion pro Zyklus fertiggestellt werden kann. Aus diesem Grund 
hatte der erste SPARC übrigens auch keine Multiplikation und Division, 
was aber später aus Performanzgründen nachgeflickt wurde.
Hierbei ist wichtig, daß keine CPU eine Instruktion in einem Taktzyklus 
ausführen kann; es sind immer mehrere Schritte nötig. Wenn man aber 
nicht alle Instruktionen nacheinander ausführt, sondern die einzelnen 
Schritte jeder Instruktion um eins versetzt in einer Art Fließband 
(Fachausdruck "Pipeline") berabeiten, kann man im Idealfall eine 
Instruktion pro Taktzyklus abschließen. Das setzt allerdings voraus, daß 
die Instruktionen alle eine ähnliche Anzahl an Einzelschritten haben, 
weswegen sie möglichst primitiv sein sollten.
Ein typisches Gegenbeispiel hierfür ist der PowerPC, der für RISC einige 
viel zu komplexe Instruktionen hat. Das Laden und Speichern von mehr als 
einem Register in einer Instruktion ist allerdings auch in ARM 
vorhanden. Aus diesem Grund arbeitet übrigens die Implementierung des 
PPC970, der im Vergleich zu den anderen PowerPCs eine deutlich tiefere 
Pipeline hat, intern mir "cracked instructions", d.h. komplexe 
Instruktionen werden in zwei oder mehr primitivere zerlegt. Das Konzept 
erinnert natürlich sehr stark an die Micro-Ops von Intel.

* In der Originaldefinition von David Patterson war auch noch die 
Implementierung von sog. Registerfenstern vorhanden, aber abgesehen von 
SPARC, die von diesem Berkeley-RISC-Projekt abgeleitet wurde, hat das 
eigentlich keine andere Architektur übernommen.

Es handelt sich also hierbei im rein architektonische Vorgaben, die eine 
möglichst effiziente Implementierung erleichtern sollen. Ein Verzicht 
auf Mikrocode wird in keinster Form gefordert, mir ist aber auch kein 
RISC bekannt, der nicht überwiegend hardcodiert wäre.

Ein x86 fällt aus architektonischer Sicht definitiv nicht ins 
RISC-Raster. Instruktionslängen die zwischen 1 und 16 Byte schwanken und 
teilweise äußerst komplex codiert sind. Immer noch keine echten 
Universalregister, da EAX als ehemaliger Akkumulator codierungstechnisch 
bevorzugt wird, variable Shiftweiten nur in CL stehen dürfen, 
Multiplikation/Division implizit EAX/EDX verwenden, etc. pp.
Beim Pentium werden die 8 Pseudo-Universalregister intern auf 40 
Register umverteilt und die Instruktionen in Micro-Ops zerlegt, damit 
sie einigermaßen effizient in einer Pipeline ausgeführt werden können.

Rein von der Geschwindigkeit hat RISC aus meiner Sicht deutliche 
Vorteile gegenüber einem reinen CISC, was sich alleine daran zeigt, daß 
die wirklich schnellen Prozessoren intern alle auf eine Form von RISC 
zurückgreifen.
Für den Embedded-Bereich ergeben sich Nachteile bezüglich der Codedichte 
oder dem direkten Zugriff auf Ports, weswegen hier meist gewisse 
Abweichungen von der originalen RISC-Definition finden lassen.

Autor: Ernie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was ist besser - Apfel oder Birne?

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Pflaume!

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...ist besser.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.