Nachrichten

1

Lowlevel-Coding / RISC CPU

« am: 24. June 2005, 19:07 »

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.

2

Lowlevel-Coding / RISC CPU

« am: 23. June 2005, 18:32 »

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.

3

Lowlevel-Coding / RISC CPU

« am: 23. June 2005, 15:39 »

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

4

Lowlevel-Coding / RISC CPU

« am: 22. June 2005, 13:30 »

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.

5

Lowlevel-Coding / RISC CPU

« am: 22. June 2005, 02:20 »

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.