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
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?
Fragen, die so einfach ins Blaue hinein gehen, haben wenig Sinn. Sammle ein wenig Programmiererfahrung, dann weißt du wenigstens, worüber du redest.
www.gidf.de gibt dir die Antwort. Einfach "RISC CISC" eingeben.
>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!
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
Schaut man sich die 2Mrd. Transistoren bei x86 an, scheint CISC recht erfolgreich zu sein. Zumindest bei MS-Maustreibern.
>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.
>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.
>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.
Wenn Du weißt, was Du erschlagen willst, wirst Du auch wissen, was Du einsetzen musst.
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);
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.
@ 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
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...
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.
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...).
> 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.
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.