Autor Thema: RISC CPU  (Gelesen 34689 mal)

mysticforce

  • Beiträge: 56
    • Profil anzeigen
Gespeichert
« am: 25. May 2005, 12:10 »
hi wollte mal fragen was ihr allgemein von dieser cpu architektur haltet. ich habe mal gelesen es soll eine "echte" 64 bit architektur sein. weiss jemand was das zu bedeuten hat (ausser das sie nicht abwärts kompatibel ist. wie z.b. die opterons). ich hab mich ausserdem mal nach einem solchen prozessor umgesehen und nur die sun server, workstations und die macs gefunden. kennt ihr sonst welche die erschwinglich sind?
die architektur selbst scheint genial und allen derzeitig aktuellen cpus überlegen zu sein.

also postet meinungen bitte.


edit:
hab hier noch nen netten link gefunden der die beiden prozessortypen anhand ihrer entwicklung im laufe der zeit erklärt.

http://www.bernd-leitenberger.de/cisc-risc.html
Unix ist was du daraus machst.

Linuxuser aus Leidenschaft!

Die Grenzen deiner Sprache sind die Grenzen deiner Welt.

Golum

  • Beiträge: 96
    • Profil anzeigen
Gespeichert
« Antwort #1 am: 25. May 2005, 14:10 »
Da hast du ne ziemlich genaue erklärung was RISC-CPU's sind.
Athlon oder sonstige Prozessoren sind im Kern auch nur RISC-Prozessoren nur mit ein paar extras ^^

http://de.wikipedia.org/wiki/Reduced_Instruction_Set_Computing
http://en.wikipedia.org/wiki/RISC

Netmaster

  • Beiträge: 41
    • Profil anzeigen
Gespeichert
« Antwort #2 am: 25. May 2005, 14:44 »
Aber er hat Recht, die Riscs sind meistens schneller, haben dafür aber keine komplizierten Befehle (Stringoperationen z.B.), die RISC's sind auch energiesparender und in der Regel bissel schneller, z.B. 900MHZ RISC CPU von Apple ist ca. so schnell wie 2GHz von Intel. Und bei kleinen Aufgaben und Geräten, die keine komplizierten arithmetischen oder logischen Operationen ausführen sollen, sind RISC-CPU ein Muss.
Chaos ist die höchste Form der Ordnung ;)

mysticforce

  • Beiträge: 56
    • Profil anzeigen
Gespeichert
« Antwort #3 am: 25. May 2005, 14:44 »
danke aber die kenn ich schon. mich würden vorallem meinungen mit begründung interessieren. auch eine erklärung was es mit dem "echten" 64 bit aufsich hat.

heißt das das sie für komplizierte arithmetische oder logische Operationen schlechter geignet sind?
Unix ist was du daraus machst.

Linuxuser aus Leidenschaft!

Die Grenzen deiner Sprache sind die Grenzen deiner Welt.

Legend

  • Beiträge: 635
    • Profil anzeigen
    • http://os.joachimnock.de
Gespeichert
« Antwort #4 am: 25. May 2005, 17:48 »
Eigentlich finde ich die Bezeichnung mehr als problematisch, weil schon einige das wohl verwechseln. ;)
Ich kann auch eine 16 Bit RISC CPU machen, in der Weise das diese CPU dann ein reduziertes Instruktionsset hat.

Vielleicht meinst du mehr HP's PA-RISC Architektur? http://www.computerbase.de/lexikon/PA-RISC

Und Apple verbaut ja generell CPUs der PowerPC Reihe, was eine RISC-CPU ist.
*post*

Svenska

  • Beiträge: 1 792
    • Profil anzeigen
Gespeichert
« Antwort #5 am: 25. May 2005, 19:17 »
RISC = kennt wenig Befehle, ist schnell
CISC = kennt viele u./o. komplexe Befehle, ist langsamer

Sämtliche neueren CPUs sind im Kern RISC-Prozessoren, aber durch die Kompatiblität zur CISCigsten aller CPUs, dem 486er ^^, muessen die neueren CPUs auch den kompletten Befehlssatz des 486ers abbilden können. Das kostet ungemein viel Leistung... und sorgt dafuer, dass m68k oder die G's bei gleicher Taktfrequenz ziemlich schnell wegrennen.

RISC hat mit 64-Bit nichts zu tun. Wenn du sämtliche Daten- und Adressleitungen samt den Befehlen auf 64 Bit erweiterst, hast du echte 64 Bit. Machst du es nur mit 8 Bit breiten Leitungen/Befehlen, hast du ne echte 8-Bit-RISC-Architektur. Die Aussage "echte 64 Bit" ist irrefuehrend und nicht relevant.
64 Bit heisst, dass du enorm viel RAM verwalten kannst, 2^64 Bytes, und eben darum auch mit solchen Adressen arbeiten kannst. Ausserdem kannst du mit Zahlen bis zu dieser Grössenordnung (unsigned 2^64, signed -2^32 < x < 2^32-1) intern arbeiten, ohne grossartig umrechnen zu muessen; auch kannst du solche Zahlen ungeteilt in den Registern abspeichern. Gleitkommazahlen werden von den NPX'en schon seit jeher mit bis zu 80 Bit dargestellt...

Abwärtskompatiblität ist uebrigens durch RISC nicht abgeschafft; ich glaube auch ein neuer m68k'ler kann m6800er Code ausfuehren.

Die Architektur ist nicht den aktuellen CPUs ueberlegen, aber die x86-Architektur ist schon 1987 gegen die Wand gefahren, dadurch, dass sie so extrem aufgebläht ist (der 8086 kann ueber 110 Befehle, ein m6800 nur 35 oder so; PMode & Co fordern auch ihren Tribut an komplexen, microcodegesteuerten und langsamen Befehlen). Aber da alle an der Kompatiblität festhalten, muss eben sowas emuliert werden.

Reine RISC-CPUs arbeiten in der Regel in Servern, teilweise Workstations und Macs. Viel mehr Anwendungen fallen mir da auch nicht ein... Macs sind dafuer bekannt (=> Marktnische, wenn ich es mal so sagen darf) und bei riesigen Firmenservern ist es eigentlich ein Muss, auch wenn x86 dafuer verwendet wird.

Man kann nicht x86 mit CISC oder RISC vergleichen, da sie inzwischen Elemente beider Ideologien enthält (einen OnChip-Emulator auf ner RISC-CPU), die Architektur wurde nur mit der Zeit und der Kompatiblität wegen versaut. Ist aber leider Standard ;)

Eine gute RISC-Architektur läuft allem anderen davon, aber CISC ist schon lange tot. Oder?

Svenska

mysticforce

  • Beiträge: 56
    • Profil anzeigen
Gespeichert
« Antwort #6 am: 26. May 2005, 00:03 »
danke für die infos hab es jetzt verstanden.

trotzdem würden mich noch meinungen zur cpu interessieren.
Unix ist was du daraus machst.

Linuxuser aus Leidenschaft!

Die Grenzen deiner Sprache sind die Grenzen deiner Welt.

TeeJay

  • Beiträge: 630
    • Profil anzeigen
    • http://www.jay-code.de
Gespeichert
« Antwort #7 am: 26. May 2005, 00:52 »
Im grunde sind die neuen CPUs alle RISC. Pentium und Co haben aber sog. Mikroprogramm in sich drin. Diese erkennen die x86 Befehle und führen die nötigen RISC Befehle aus um den Effekt zu erreichen. Da dies nazürlich eine Art der Emulation ist geht da natürlich einiges an Speed verloren.

RISC selber hat den gewissen nachteil, das es nur sehr wenige Befehle gibt und es daher recht umständlich ist dafür Code zu erzeugen, erst recht wenn man in ASM programmieren möchte.
----------------------
Redakteur bei LowLevel

Legend

  • Beiträge: 635
    • Profil anzeigen
    • http://os.joachimnock.de
Gespeichert
« Antwort #8 am: 26. May 2005, 02:22 »
Wobei man bedenken muss das der PowerPC, welcher als RISC CPU gilt soweit ich weiss, auch hunderte von Befehlen kennt. In dieser Liste (http://pds.twi.tudelft.nl/vakken/in1200/labcourse/instruction-set/) wurde schon gespart und 107 sind noch übrig ...

Für optimales Tempo muss man wohl eine Balance finden, aber das sollte den OS Entwickler weniger kümmern - das ist eine Aufgabe die auch eine ganze Horde von Ingenieuren komplett auslasten kann.
*post*

Dante

  • Beiträge: 5
    • Profil anzeigen
Gespeichert
« Antwort #9 am: 26. May 2005, 12:16 »
Zitat von: Svenska
RISC = kennt wenig Befehle, ist schnell
CISC = kennt viele u./o. komplexe Befehle, ist langsamer


So würde ich das aber nicht sagen, schließlich kommt es immer darauf an, was man macht.
Im Großen und Ganzen ist de Unterschied ja, das meine Logische Einheit mehr Rechenwerke vor den MUX gespannt hat, wie bereits gesagt. (-> Größerer Befehlssatz)

Allerdings sagt das nichts über die Geschwindigkeit aus:
Wenn ich jetzt z.B. zwei Prozessoren habe, und ich will eine beliebige Zahl mit 10 multiplizieren:

Der erste Prozessor hat ein komplettes Multiplizierwerk in der ALU integriert, und der zweite tut sein Werk über einen Addierer, und einen Shifter.
Wenn wir jetzt die beiden gegenüberstellen,  dann ist höchstwahrscheinlich der zweite trotzdem schneller, als der erste, obwohl er etwas primitiver aufgebaut ist.
Wenn ich jetzt aber dieselbe Zahl mit z.B. 11 multipliziere, wird mein Addierwerk sicher schneller das Ergebnis ermittelt haben.

Was ich damit sagen will: Man kann niemals sagen, welcher Prozessortyp schneller ist, es kommt immer darauf an, mit welchen mathematischen Problemen ich diesen füttere. Sind es einfache Additionen, und die Grundrechnungsarten, rennt mir mein RISC sicher davon - wenn ich jetzt aber z.B. ein Integral berechnen will, und ich bereits eine Schaltung dafür in meiner logischen Einheit habe, dann wird mir ein RISC sicherlich ein paar Takte mehr brauchen, da er diese Rechnung erst mit den Grundrechnungsarten, die er kann simulieren muss.

\topic:

Der primitivste RISC ist mir sicher zu wenig.... da beherrscht die ALU ja gerade einmal das Addieren zweier Zahlen, log. UND, und log. Negation - da kann sich ja wohl jeder vorstellen, wie schnell der Prozessor getaktet sein muss, damit in diesem Jahrhundert noch ein Ergebnis zu Stande kommt. - Aber bei einem gängigen RISC ist das ja kein Problem, der hat ja schon einen ordentlichen Befehlssatz, und kann alles was man oft braucht schnell ... und somit bin ich auch zu frieden damit.
Wenn ich jetzt komplexere Sachen berechnen muss, dann bin ich sowieso meistens mit C dabei, und da nehmen mir die Bibliotheken die Arbeit ab, und somit habe ich nicht die Scherereien etwas Hochkompliziertes in Assembler zu coden. (Ich kann ohnehin nur ein bisschen PIC-Assembler, und das ist ja kein Vergleich zu x86)
Ich bin also eher ein RISC-Freund, als CISC, nicht das ich persönlich den Unterschied als Programmierer überhaupt merken würde. ^^;
Im Entwurf zeigt sich das Talent,
In der Ausfuerung die Kunst.

n3Ro

  • Beiträge: 288
    • Profil anzeigen
Gespeichert
« Antwort #10 am: 26. May 2005, 12:41 »
Also ich würde schon sagen das RISC schneller als CISC ist, vielleicht nicht von der MHz Zahl, aber von der Leistung die eine RISC CPU einer CISC CPU bei gleicher Taktung voraus hat. ISt genauso wie wenn du zwei Autos hast und das eine hat doppelt so viel PS wie das andere und kommt trotzdem nicht schneller voran, welches ist dann wohl besser ;-)?
Agieren statt Konsumieren!

Legend

  • Beiträge: 635
    • Profil anzeigen
    • http://os.joachimnock.de
Gespeichert
« Antwort #11 am: 26. May 2005, 12:44 »
Bei gleicher MHz Zahl wäre eine RISC CPU einer CISC CPU wahrscheinlich sogar unterlegen. Wobei man dann beachten muss, welche Befehle wieviele Takte brauchen.

Ausser du meinst PA-RISC und x86 ...
*post*

n3Ro

  • Beiträge: 288
    • Profil anzeigen
Gespeichert
« Antwort #12 am: 26. May 2005, 12:55 »
Schau mal hier nach: http://www.spec.org/

Kleines Bsp von aus dem CFP2000:
FSC PRIMNEPOWER 900  (SPARC64 2160Mhhz)   1800-2150 Punkte
HP ProLiant DL360 G4p (XEON 3,6 GHz)             1800-1825 Punkte

CINT2000:
FSC PRIMNEPOWER 900  (SPARC64 2160Mhhz)    1456-1594 Punkte
HP ProLiant DL360 G4p (XEON 3,6 GHz)             1675-1712 Punkte

Liegen ganz schön nah bei einander dafür dass der XEON eine 1,5 GHz höhere Taktung hat.
Agieren statt Konsumieren!

mysticforce

  • Beiträge: 56
    • Profil anzeigen
Gespeichert
« Antwort #13 am: 26. May 2005, 13:50 »
Zitat
Wenn ich jetzt komplexere Sachen berechnen muss, dann bin ich sowieso meistens mit C dabei, und da nehmen mir die Bibliotheken die Arbeit ab, und somit habe ich nicht die Scherereien etwas Hochkompliziertes in Assembler zu coden.


ist es so viel schwieriger assambler code für die riscs zu schreiben?
Unix ist was du daraus machst.

Linuxuser aus Leidenschaft!

Die Grenzen deiner Sprache sind die Grenzen deiner Welt.

Dante

  • Beiträge: 5
    • Profil anzeigen
Gespeichert
« Antwort #14 am: 26. May 2005, 14:38 »
Na ja, es kommt immer darauf an, was man machen will ...

Es wird nicht wirklich komplizierter, nur laenger. Waerend du in CISC manche Sachen mit einem einzigen Befehl geschrieben hast, musst du bei RISC halt eine ganze Befehlskette schreiben, die das selbe, wie dieser Befehl macht - wenn man also weis was man tut, sollte es nicht wirklich schwieriger sein, sondern einfach kuerzer, und schneller zum programmieren.

(In meinen fall ist es halt komplizierter, weil ich erst vor einer Woche etwas mehr in x86-assembler hineingeschnuppert habe - der Satz war also eher auf mich bezogen, allgemein gemeint.)
Im Entwurf zeigt sich das Talent,
In der Ausfuerung die Kunst.

Roshl

  • Beiträge: 1 128
    • Profil anzeigen
    • http://www.lowlevel.net.tc
Gespeichert
« Antwort #15 am: 26. May 2005, 17:59 »
Gleich getaktete RISC's sind um ein vielfaches schneller als CISC's, weil die Befehle fest verdrahtet werden und nicht durch einen Microcode aufgelöst werden müssen. Weiterhin sind beim RISC's mehr Register vorhanden 32-128 sind Standard, also letztlich weniger Speicherzugriff was die Geschwindigkeit auch arg erhöht.
Nachteile sind eben, dass der Code sehr viel länger wird, also mehr Befehle um den selben Effekt wie bei CISC's zu haben, was wiederum heisst mehr Speicherzugriffe die den Code laden müssen. SIMD (wie MMX/SSE/3Dnow!) gibt es defacto auch nicht, müssen auch durch längere Befehlsketter ersetzt werden.
Da aber fast jeder Befehl in einem Takt ausgeführt werden kann läuft ein echter RISC einem CISC trotzdem davon. Vergleicht bloss mal die Taktraten von PowerPC(Mac) und Intel CPU's und die Leistung. PPC weniger MHZ als Intel, aber die Leistung ist definitv ebenbürtig wenn nicht gar besser.
[schild=1]Wieder ein wertvoller(?) Beitrag von Roshl[/schild]

DDR-RAM

  • Beiträge: 184
    • Profil anzeigen
Gespeichert
« Antwort #16 am: 26. May 2005, 18:17 »
Das mit den mehr Registern, gehört eigentlich nicht zur RISC-Architektur dazu, es die RISC's sind nur neuer und haben deshalb mehr Register. ;-)

die x86er sind ja abwärtskompatibel und viele weitere Register passen da nicht so richtig mit den Opcodes zusammen.

MfG
DDR-RAM

n3Ro

  • Beiträge: 288
    • Profil anzeigen
Gespeichert
« Antwort #17 am: 26. May 2005, 18:38 »
Das RISC Architektur CPUs mehr Register haben ist schon Teil des RISC Designs, da man Speicherzugriffe ja minimieren will und alle Befehle nur mit Registern arbeiten. Nur wieviele das letztendlich sind, ist nicht definiert.
Zum Thema mehr Register bei x86 CPUs, es gibt jetzt mehr Register, seit dem Opteron/Athlon64 stehen dem Programmierer 16 statt nur 8 General Purpose Register und 16 statt 8 XMM (SSE1/2/3) Register zur Verfügung, und es ist trotzdem noch mit altem Code Kompatibel! Ich würde mal sagen dass sich x86 immer mehr Dinge von RISC abschaut um schneller und schneller zu werden. Und es klappt! :D
Agieren statt Konsumieren!

DDR-RAM

  • Beiträge: 184
    • Profil anzeigen
Gespeichert
« Antwort #18 am: 26. May 2005, 18:54 »
naja, nein, es nicht wirklich kompatibel, man ist ja in einem anderen Modus, 32-bit code funktioniert nicht mit 16 registern, weder legacy mode noch compatibility mode unterstützen die 8 neuen.
Nur der longmode eben.

Und das mit den, das es nicht zum eigentlichen RISC dazugehört, hab ich von wikipedia :oops:

MfG
DDR-RAM

n3Ro

  • Beiträge: 288
    • Profil anzeigen
Gespeichert
« Antwort #19 am: 26. May 2005, 19:14 »
Oh, stimmt, naja zumindest der neue Modus unterstützt es (wie du schon gesagt hast der LongMode eben). Jetzt müssen eigentlich nur noch Real und Protected Mode wegfallen und die CPU würde günstiger und schneller werden ;-). Und wenn man nen 64bit Modus hat braucht man den Rest ja auch nicht mehr :D
Agieren statt Konsumieren!

 

Einloggen