[PCN] Der Prozessor - Sammel und Diskussionsthread

[Ineluki]

Man koentne auch ueber eine Gleitzahlenrepraesentation im Dezimalsystem, vorgeschlagen im IEEE854 bzw IEE754r, einfuehren. Wenn wir von einem 32bittigen System abweichen koennte das sogar eventuell fuer eine selbstgebaute FMU einfacher zu handhaben sein ...

Im Grunde kommen wir bei allen Bitbreiten ausser 32bit in Bedraengnis, da nicht jeder nativen 64bit support hat. Das heisst, man muesste die Rechenoperationen fuer Gleitkomma- und Ganzzahlen in jedem Fall selber schreiben, wenn wir nicht 32bit benutzen wollen. Trotzdem wuerde ich vorschlagen, von 32bit wegzugehen, einfach aus dem Grund, dass wir sonst ja auch einfach zum Prozessor durchschleifen koennten. Wenn wir allerdings alles selber implementieren, dann haben wir viel groessere Freiheiten.

Ich habe da eventuell (auch im Hinblick auf eventuelle Kompatibilitaet mit unserer spaeteren Graphikkarte) vielleicht an ein 96bit System gedacht. Das haette den Vorteil, das man sowohl in Zwei-, Drei-, Vier-, Sechs-, Acht- und Zwoelfbyteblöcken ohne Padding und Aligning arbeiten kann. Ausserdem gibt uns ein 96bit System Datentypen mit hohen genauigkeiten, Addressierung von nahezu unbegrenztem Speicher (so koennte man z.B. jedem Prozess muehelos seinen eigenen Speicherraum geben, indem man die Addressen mit der Prozessnummer padded, und diese dann auf den echten Ram mappt) und genuegend Variablilitaet auch fuer komplexe Machienencodebefehle.

Was mich auch zu dem Punkt RISC vs CISC bringt. Natuerlich haben RISC Prozessoren Geschwindigkeitsvorteile gegenueber CISC wenn es um die Hardwarerepraesentation geht. Andererseits stellt sich das Problem bei unserem Prozessor ja nicht, sondern kehrt sich fast ins gegenteil. Denn unser virtueller Prozessor verursacht bei jedem Befehl viele Befehle in unserem realen Rechner. Da sind Case Statements auszuwerten, Unterprogramme aufzurufen usw. Das heisst, mit einem (reinen) RISC Prozessor verursachen wir wahrscheinlich viel mehr Wartezeit, da viel mehr Operationen auszufuehren sind, die man bei einem CISC in einem Schritt kodieren kann.

Ein Beispiel. Nehmen wir einen ASM Befehl, der einen Speicherbereich (DX) auf einen anderen Speicherbereich kopieren soll (EX), und zwar so viele Byte, wie in CX gespeichert sind.

Mit einem RISC saehe das im Code im Prinzip so aus:

Code:

::label         ; Begin der Schleife
LOAD AX, DX    ; Lade in AX, was an der Addresse in DX steht
SAVE EX, AX    ; Schreibe an die Addresse aus EX, was in AX steht
INC DX          ; Ruecke DX ein Byte weiter
INC EX          ; Ruecke EX ein Byte weiter
DEC CX          ; Anzahl noch zu kopierender Bytes verkleinern
CMP CX, 0       ; Ist CX größer als Null ?
JGT label       ; Wenn ja, springe an den Anfang der Schleife

Unser Prozessor muesste also 7 Befehle parsen, 7 Mal in seiner Befehlstabelle nachschlagen, 11 Mal auf den RAM zugreifen (da unsere Register ja auch im RAM liegen, wenn wir nicht in ASM optimieren sondern mit einer Hochsprache arbeiten).

Bei einem CISC Befehlssatz koennte man das viel schneller und eleganter loesen:

Code:

CPY EX, DX

Und hinter dem ominoesen CPY Befehl verbirgt sich in unserem Interpreter dann folgende Zeile:

Code:

memcpy( (void*) Registers["EX"], (void*) Registers["DX"], Registers["CX"] );

Man koennte als die ganze Arbeit des CISC Befehles durch schon vorgefertigte betriebssystemnahe und optimiere Hochsprachenfunktionen ersetzen. Effektiv sollte das also schneller sein.

Was die Register angeht haben wir auch nicht die Probleme, die echte Prozessorenbauer haben. denn unsere Prozessoren koennten beliebig viele Register haben. Allerdings koennte man der Einfachheit halber wie bei den RISC Prozessoren statt einer variablen Befehlskettenlaenge eine mit fixierter Breite verwenden, und damit das Parsen erleichtern.

Ich wuerde also Vorschlagen, sich an der RISC Architektur mit ihren fixierten Befehlsbreiten und hohen Registerzahlen (teilweise ueber 256) zu orientieren, jedoch auch einen erweiterten CISC Befehlssatz mit komplexen Routinen anzubieten, die dann im Intgerpreter schnell und kompakt nativ durchgefuehrt werden koennen. Denn man sollte bedenken, in unserem Fall kann man einen CISC ohne Geschwindigkeitseinbusse als RISC betreiben, aber nicht umgekehrt.

[Jesus_666]

Ich habe da eventuell (auch im Hinblick auf eventuelle Kompatibilitaet mit unserer spaeteren Graphikkarte) vielleicht an ein 96bit System gedacht. Das haette den Vorteil, das man sowohl in Zwei-, Drei-, Vier-, Sechs-, Acht- und Zwoelfbyteblöcken ohne Padding und Aligning arbeiten kann. Ausserdem gibt uns ein 96bit System Datentypen mit hohen genauigkeiten, Addressierung von nahezu unbegrenztem Speicher (so koennte man z.B. jedem Prozess muehelos seinen eigenen Speicherraum geben, indem man die Addressen mit der Prozessnummer padded, und diese dann auf den echten Ram mappt) und genuegend Variablilitaet auch fuer komplexe Machienencodebefehle.

...

Okay... Allerdings ist natürlich zu bedenken, daß das mit den Speicherräumen sich relativiert - den privaten Specherraum haben Prozesse seit dem 80386 (virtuell) und physikalisch ist das natürlich alles illusionär.
Und natürlich brauchen wir dann wesentlich mehr LOAD- und STORE-Befehle: Für Bytes, 16 Bits, 32 Bits, 48 Bits, 64 Bits, 72 Bits, 96 Bits.

Was mich auch zu dem Punkt RISC vs CISC bringt. Natuerlich haben RISC Prozessoren Geschwindigkeitsvorteile gegenueber CISC wenn es um die Hardwarerepraesentation geht. Andererseits stellt sich das Problem bei unserem Prozessor ja nicht, sondern kehrt sich fast ins gegenteil. Denn unser virtueller Prozessor verursacht bei jedem Befehl viele Befehle in unserem realen Rechner. Da sind Case Statements auszuwerten, Unterprogramme aufzurufen usw. Das heisst, mit einem (reinen) RISC Prozessor verursachen wir wahrscheinlich viel mehr Wartezeit, da viel mehr Operationen auszufuehren sind, die man bei einem CISC in einem Schritt kodieren kann.

...

Allerdings muß der Prozessor im Anschluß diese Befehle wieder dekodieren, um sie auszuführen. Auch wenn man bei RISC mehr Kram mit weniger Befehlen erledigen kann wird der Kram deswegen nicht wirklich schneller - es sei denn wir entwickeln den Prozessor wirklich nur als Grundlage einer VM, in welchem Fall wir den Instruktionssatz komplett auf einer höheren Ebene ansiedeln sollten.
Ich plane den Prozessor so, daß wir ihn rein theoretisch physikalisch umsetzen könnten. Werden wir wahrscheinlich nicht, aber ich sehe das Ganze hier als eine Art Planspiel.

Man koennte als die ganze Arbeit des CISC Befehles durch schon vorgefertigte betriebssystemnahe und optimiere Hochsprachenfunktionen ersetzen. Effektiv sollte das also schneller sein.

...

Ich wuerde also Vorschlagen, sich an der RISC Architektur mit ihren fixierten Befehlsbreiten und hohen Registerzahlen (teilweise ueber 256) zu orientieren, jedoch auch einen erweiterten CISC Befehlssatz mit komplexen Routinen anzubieten, die dann im Intgerpreter schnell und kompakt nativ durchgefuehrt werden koennen. Denn man sollte bedenken, in unserem Fall kann man einen CISC ohne Geschwindigkeitseinbusse als RISC betreiben, aber nicht umgekehrt.

...

Naja, ich strebe ja eben an, daß der Kram auch in vivo realisierbar ist; da wären derartige Specs eher hinderlich.