Thema: RISC CPU

[LeChuck]

Nachdem sich Apple nun offiziell von dieser Architektur trennen wird gibt es ja nicht so viele im Desktop Bereich. Ich hab allerdings zu meiner grossen Überraschung erfahren, dass der gute alte Amiga einen offiziellen (AmigaOne/AmigaOS) und inoffiziellen (Pegasos/MorphOS) Nachfolger hat, wobei es sich um einen PowerPC handelt, was ja weniger überraschend ist. Leider sind sie nur abwärtskompatibel (im Kernel wird der m68k Code emuliert und ich glaub AmigaOS 3.9 läuft auf beiden nativ), jedoch nicht untereinander.

Der Pegasos würde allerdings als allgemeiner PowerPC designed, auf dem deshalb relativ viele Betriebssysteme nativ laufen. Er wird übrigens auch offiziell von Gentoo, einer sehr gute Linux Distribution, supported und mit einer eignen Workstation vertrieben.

Leider ist das beim AmigaOne ganz anders. Bei seinem Design wurde sich ausschliesslich auf AmigaOS konzentriert, und tatsächlich sollen auch wenige OSes auf der Maschine laufen, sogar mit Linux soll es Probleme geben.

Beide System haben allerdings doch noch etwas gemeinsam: sie bestehen mittlerweile wieder aus bereits veralteter Hardware (um 2002/03 erschienen) und sind keine Schnäppchen. Bei beiden System handelt es sich wahlweise um einen G3 oder G4 bis maximal 1,1 GHz (glaub ich).

Naja, gehört halt Herzblut dazu, sind beides keine Vernunftsysteme. Für einen Linux User könnte es aber interessant sein, wenn er einen PPC programmieren will. Und ganz nebenbei (oder gerade deswegen) hat man noch einen neuen Amiga.

Ich überlege tatsächlich mir so ein System zuzulegen. Allerdings kann man nicht voraussagen, ob sie sich weiterentwickeln werden. Würde Apple nicht wechseln, hätte ich mir zum programmieren ein billiges G3 IBook mit orangen Case besorgt (mach ich bestimmt noch), aber vorerst ist Apple/MacOS für mich uninteressant.

Auf dem Amiga 500 hab ich früher mit dem DevPac Assembler ein wenig programmiert, aber so gut wie alles verlernt. Den Wechsel zu x86/TASM fand ich interessant und Asm kam mir auch leichter vor, lag aber bestimmt an der Erfahrung. Je mehr ich allerdings über Codeoptimierung gelernt habe (was ich eigentlich am coolsten finde), desto weniger bin ich vom x86 begeistert. Ausserdem hab ich festgestellt, dass ich selten einen Befehl verwende, den es bei DevPac in ähnlicher Form nicht gab. Natürlich sind die zusätzlichen Befehle cool, produzieren aber oft mehr Opcode, was sie für innere Schleifen uninteressant macht, und deswegen entberlich. Auch das Little Endian ist bei mir immer wieder ein zuverlässiger Grund für Bugs.

Übrigens gibt es einen PPC Emulator für x86, den PearPC, über dem man man sogar MacOS benutzen kann (ist ja bald unnötig).

Für Assembler Freaks und Hardwarebastler ist es bestimmt ein Abenteuer, RISC kennenzulerenen. Für Desktop User nur ein etwas teuereres Hobby.

[Roshl]

Aus der Sicht des Programmierers macht es wenig unterschied ob RISC oder CISC. Zumindest für gute(!) Programmierer dürfte es keine Schwierigkeit darstellen die etwas komplexeren CISC-Befehle in einige wenige RISC-Befehle zu zerstückeln.
Ob Little oder Big-Endian ist letztlich egal, man muss nur wissen was grade vorliegt.
Das die zusätzlichen Befehle wie du sie nennst mehr Opcode produzieren ist eigentlich nicht richtig, im Gegenteil sie reduzieren eher die Menge an Bytes weil nicht mehrere Befehle Codiert werden müssen, die z.b. die selben Register bearbeiten, so gibt man das Register nur einmal an, was letztlich Grössenreduzierend wirkt (wirken kann).
Allerdings ist bei Prozessores alles relativ und nur unter bestimmten Bedingungen richtig. Wer dämlich Programmiert produziert das 3-fache an Code wie ein guter Progger, das heisst aber nicht, dass kürzerer Code schneller ist, wenn der grössere für den Prozessor besser zu parallelisieren und zu verarbeiten ist.
x86 ist keine schlechte Architektur, ist allerdings Verbesserungswürdig, durch diese elende Abwärtskompatibilität die mitgeschleift werden musste (man hatte da eigentlich kaum eine Wahl) hat sich vieles Arg verkompliziert. Man könnte einiges an Transistoren und somit Kosten für Herstellung und Betrieb sparen, würde man den RealMode einfach wegtreten, der eh nicht mehr benutzt wird. Ähnlich die Deskriptoren die wegen dem 286er-PM ziemlich verkorkst und zerstückelt sind, sollten aufgeräumt werden->Transistorenabnahme.
Da gibt es viele Dinge die man weglassen könnte und aus Sicht der Programmierer wäre das einfach nötig.

[LeChuck]

Du hast natürlich recht, dass ein spezieller Befehl in der Regel weniger Opcode produziert, als dafür eine alternative zu programmieren. Der von ihnen produzierte Opcode ist dennoch oft grösser, als die prozessoreigenen viel benutzten Befehlen (ich mein damit jetzt mov, add, xor und so, die es ja auch bei RISC gibt).

In einer inneren Schleife, den am stärksten zu optimierenden Codeteilen, sollte der Code leicht zu verarbeiten und kurz sein. Leider trifft beides auf einige (viele) dieser Befehle nicht zu, weshalb man versuchen sollte sie aus der inneren Schleife zu halten. Wenn es aber nicht besser geht, dann sollte man sie benutzen - (mal mehr oder weniger) oft geht es halt besser, und deshalb sind sie für mich entberlich und eigentlich nur Luxus (aber nett). Naja, Codeoptimierung ist ein eigenes Buch und will es mal dabei sein lassen, wollte nur noch etwas genauer formulieren was ich eigentlich meine.

Ich möchte die Architektur des x86 nicht schlecht reden, sie hat eben ihre eigene Philosophie mit eigenen Vorteilen, sowie RISC, aber für eine radikale Überholung nach deinen Vorschlägen ist es wirklich Zeit, solange bleibt RISC eleganter. Welchen Typ man lieber programmiert muss jeder selbst herausfinden.

RISC findet man ausserdem überall, wo man es nicht erwartet. Wer also mehr als nur seinen PC programmieren will, sollte deshalb diese CPU zu programmieren lernen.

btw.: mit Big Endian zu arbeiten finde ich effizienter, vor allem beim debuggen.

[Legend]

Big Endian ist bei der Netzwerkprogrammierung effizienter, da zumindestens einige Sachen dort Big Endian sind, da sie interoperabel sein wollen (und man sich dann nicht auf Little Endian festgelegt hat).

[Roshl]

Bei RISC haben meistens OpCodes allerdings eine feste länge um das decoding zu erleichtern, meine ich mal irgendwo gelesen zu haben. und die muss so gross sein, um die maximale auslastung aufnehmen zu können, obwohl viele so viel nicht brauchen werden->Platzverschwendung

[LeChuck]

Die RISC-Decodierung überspringt damit den Schritt die Adresse des nächsten Befehls zu errechnen, und fäng sofort mit dem decoden an -> Geschwindigkeit.

[Roshl]

Genau deswegen sind auch kleine opcodes nicht möglich, braucht einer 15 Byte muss auch einer der eigentlich nur 1 benötigt auch auf 15 erweitert werden

[LeChuck]

Nun, 15 Byte sind übertrieben und falsch, alle PowerPC befehle sind 4 Bytes gross. Es gibt 60 Stück, sie sind mit der CPU hardwired, weshalb die Dekodierung so schnell ist. RISC besitzt auch mehr Register, was weitere Geschwindigkeitsboni bringen kann.

Hier kommt halt die ursprüngliche Philosophie zum vorschein: schnell und gross, oder kompakt und langsam.

Ich hab mit Assembler angefangen, weil ich schnellen, optimierten, hardwarenahen Code programmieren wollte, Spiele und Demos eben. Die Opcodegrösse ist mir dabei nicht so wichtig, da der Assember generierter Code selbst schon um ein vielfaches kleiner als Compilierter ist.

Aber heutzutage sollte man diese radikale Aufteilung von Speicher oder Geschwindigkeit sowieso neu überdenken; beides ist seit der Einführung der CPUs absolut utopisch geworden. Die zentrale Frage ist heute eine des Geldes. CISC ist billiger als RISC (nur wegern der Marktlage), aber verbraucht mehr Strom, weshalb sich RISC langfristig auszahlen kann.

Mal nebenbei: wenn in China sich Home-Computer so etablieren wie in Deutschland, haben sie mit CISC ein Versorgerproblem.

[Roshl]

4-Byte kann garnicht stimmen
mov R0,dword
da braucht das dword schon allein 4 byte dann 1 byte fürs register ein für den opcode.
Also es sind mit sicherheit mehr als 4 byte die ein befehl brauchen wird.
15 war nur ein Bsp, weil ich glaube auf x86 ist der längste Befehl 15 Byte gross ka welcher das war
(Zu einem Befehl zählt nicht nur der Opcode selbst, sondern auch die Ziel und Quelloperanden)

[LeChuck]

Jein,
... ein Befehl besteht immer aus 4 Byte, das ist beim PPC Fakt. Ist der eingelesen, werden zum PC (Program Counter) 4 (Byte) addiert, dann wird diese Adresse eingelesen, usw. Ein Befehl sagt dabei der CPU wie sie zu arbeiten hat. Ein Befehl wie add r2,r1,r0 ist hardwired (d.h. fest verlötet) und belegt demnach 4 Byte. Wird für die ordentliche Ausführung eines Befehls zusätzlich Daten benötigt wie bei li r0,666, dann sind die in den folgenden 4 Bytes des Datenbusses, und der PC wird nochmals um 4 erhöht.

[Roshl]

Wenn ein Befehl nur Register betrifft mags ja stimmen. Braucht er aber noch weitere Werte und die zähle ich eben mit dazu...

[Legend]

Okay, mal was ganz anderes, hier ein kleiner Denkansatz (ist eigentlich doch ziemlich verblüffend):

Angenommen ihr habt eine CPU die genau nur eine einzige Instruktion beherrscht, nennen wir sie Substract And Branch On Less Then Zero.
Die nimmt dann 4 Parameter,
Wert A, Wert B, Ergebnisregister und Branchoffset.

Die Werte A oder B können aber immerhin noch Register oder feste Werte sein.

Wie weit denkt ihr würdet ihr kommen so was zu programmieren?

[DDR-RAM]

Okay, mal was ganz anderes, hier ein kleiner Denkansatz (ist eigentlich doch ziemlich verblüffend):

Angenommen ihr habt eine CPU die genau nur eine einzige Instruktion beherrscht, nennen wir sie Substract And Branch On Less Then Zero.
Die nimmt dann 4 Parameter,
Wert A, Wert B, Ergebnisregister und Branchoffset.

Die Werte A oder B können aber immerhin noch Register oder feste Werte sein.

Wie weit denkt ihr würdet ihr kommen so was zu programmieren?

hm, mit dem befehl kann man ja nicht soviele sachen machen -_-
man müsste immer darauf achten, das jetzt nicht irgendwo hinspringt, man muss den vorhergehenden wert des registers/speicherstelle kennen, um einen neuen wert zuzuweisen, hardware kommunikation nur über speicher (ok, eigentlich kein echtes problem ^^)
keine unterscheidung zwischen signed und unsigned, bzw. immer signed
ich hatte schon angefangen, mir den kopf zu zerbrechen, damit was anzufangen, habe es aber wieder aufgegeben
(zu spät, keine lust, etc. )
wenn du damit nen simplen algorithmus formulieren kannst, dann schonmal RESPEKT

MfG
DDR-RAM

[Legend]

Code: [Auswählen]


int k = 0;

for (int i = 0;i < 200;i++) {
   k += i*i;
}

Sollte sich damit z.B. schon machen lassen!

Hier mal ein paar grobe Anmerkungen, falls jemand will kann ich auch mal probieren das in "Assembler" zu schreiben!

Wenn er nicht springen soll, springt er im Zweifelsfall zum nächsten Befehl.
Man kann auch 0 abziehen, um zuzuweisen.
Genausogut kann man von 0 abziehen und das Ergebnis dann von etwas anderem abziehen, effektiv also addieren.
Die Schleifenbedingung kann ich ja als 199 - i schreiben, das springt dann wenn i = 200 ist.
Das Goto wenn i < 200 ist, kann ich ja als 0-1 schreiben, das ist immer negativ - das muss ich leider nur in ein unbenutztes Register schreiben!

Und na ja, bei Integern kann ich ja statt "richtig" zu multiplizieren auch wiederholt in einer for schleife addieren!

Wohl nicht sehr effizient, aber damit kann man schon ziemlich viel machen!