Zitat Zitat von Ineluki
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.

Zitat Zitat
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.

Zitat Zitat
Man koennte als die ganze Arbeit des CISC Befehles durch schon vorgefertigte betriebssystemnahe und optimiere Hochsprachenfunktionen ersetzen. Effektiv sollte das also schneller sein.
Zitat Zitat
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.