Mein 8/16/24 Bit Prozessor

27 thoughts on “Mein 8/16/24 Bit Prozessor”

1. Sehr interessant. Als ich den Artikel gelesen habe, fiel mir das Buch „Prozessorbau“ von Christian Siemers ein, dass ich zwar nicht gelesen, aber schon öfter mal in der Unibibliothek gesehen habe.
   Beim Aufbau der Befehle und der Speicherstruktur kamen mir dann die AVR-Mikrocontroller in den Sinn, da die auch 16 Bit breite Instruktionen in einem separaten Speicherbereich für diese verwenden (Havard-Architektur), der Wortweise adressiert wird.
   Als nächstes stellte sich mir dann die Frage: Hast Du den Proessor auch mal praktisch getestet? – also eine Beschreibung davon in VHDL oder Verilog angefertigt? – Das wäre heutzutage ja der nächste Schritt beim Design eines neuen Prozessors. Wenn der Entwurf der Hardware steht, kann man einen Emulator anschmeissen, der heute auch gleich in der Entwicklungsumgebung der Hardwarebeschreibungssprache enthalten sein dürfte. Dann kann man auch schon mal ein paar Programme entwickeln, natürlich erst mal in dem definierten Assembler, die auf der entworfenen CPU laufen.
   Wenn dass auch alles funktioniert, kann man sich entweder über das vollbrachte Werk freuen, oder man macht den nächsten Schritt in die reale Hardware und schiebt die Beschreibung in einen FPGA-Chip, der vorläufig aber noch auf einer FPGA-Evaluations-Platine steckt, und lässt ihn für sich arbeiten… – Wenn auch das alles zufriedenstellend läuft, kann man einen Rechner mit der brandneuen BL-2015 CPU bauen! 😉

   Antworten

2. Nein von VHGL verstehe ich nichts. Ich halte es mit „Schuster bleib bei deinen Leisten“. Das beschränkt sich bei mir auf die makroskopische eben, nicht das Schaltungsdesign. Ich hinke sowieso was die Umsetzung anderer Projekte angeht hinterher. Immerhin: Die Bauteile für meine Meteologiestation habe ich inzwischen bestellt.

   Antworten

3. Nun ja, ich kann auch kein VHDL, aber so „ein bischen“ digitale Elektronik. In dem Zusammenhang fiel mir dann noch ein, dass eine ALU schaltungstechnisch eine recht aufwändige Angelegenheit ist, etwa im Vergleich zu einfachen Schieberegistern oder Addierern; – sie muss ja auch beides auch können. Möglicherweise war das ein Grund dafür, das bei vielen Prozessoren der 70er und frühen 80er Jahre nur das Akkumulator-Register direkt mit ALU verbunden war und alle anderen nicht. Ist jedenfalls so eine Vermutung, die ich hiermit mal in den Raum stelle.

   Mir kam übrigens später noch in den Sinn, dass man einen Prozessor ja auch erst einmal komplett in Software simulieren (modellieren?) kann. Dazu baut man ein Programm, das so tut, als wäre es der Prozessor. Dieses liesst die einzelnen Bytes oder Worte, die den Programmcode darstellen, analysiert sie und je nach Ergebnis dieser Analyse tut es das, was entsprechende Hardware in dem Fall auch tun soll(te). Wenn man so eine Simulation richtig aufzieht, kann man auch schon eine Menge über die Vor- und Nachteile heraus finden, die einem sonst erst einmal verborgen bleiben. Da stellt sich natürlich die Frage, wie „die Simulation richtig aufziehen“ zu verstehen ist. Aber die lass ich hier mal offen, weil ich die Antwort nicht weis.

   Antworten

4. Moin,

   > Da stellt sich natürlich die Frage, wie „die Simulation richtig aufziehen“ zu verstehen ist. Aber die lass ich hier mal offen, weil ich die Antwort nicht weis.

   eine Registermaschine schnell zu emulieren kann man sich im Lua Interpreter, dem Hercules Emulator und einigen anderen Byte-Code-Interpretern von anschauen. Auch der SIMH ist da sehr interessant, weil klassische Maschinen wie den H316, PDP oder Altair emuliert.

   Als Einstieg in die Theorie sollte vorher SICP durchgearbeitet werden. In diesem legendären Studienkurs wird am Anfang erklärt was eine Programmiersprache ist, und dann sehr schnell verschiedene Methoden diese zu implementieren, wie rekursives interpretieren (McEval), und auch Übersetzung in eine virtuelle CPU, die dann auch gleich interpretiert wird.

   ciao,Michael

   Antworten

5. Wenn man sich die Mühe macht eine komplett neue CPU zu entwerfen, ist es hilfreich ein paar Vorgaben zu machen bevor man anfängt. z.B.
   – eine grobe Anzahl von Transistoren oder Gates.
   – was hätte man in 19xx in Technologie Y machen können.
   – eine verbesserte Version von CPU Z.
   – eine CPU mit der Besonderheit A.
   – es soll auf ein FPGA B passen.
   – einen Einsatzzweck, für den keine vorhandene CPU passt (warum?).

   Es gibt eine große Auswahl verschiedener CPUs oder Modelle, aus denen man sich bedienen kann.
   – CPUs mit sehr kompaktem Befehlssatz siehe Bernd Paysans 4stack oder B16 http://bernd-paysan.de/4stack.html
   – 16 Bit RISC z.B. Siemens 80C166

   Ich komme aus der Software Ecke, und habe mit Embedded Systemen nie viel am Hut gehabt. Daher war für mich was kleineres als eine 32 Bit CPU eher uninteressant. (Ich habe den mc68k immer als verkrüppelte 32 Bit CPU betrachtet.)
   Daher würde ich bei einem neuen CPU Design mit einem mc68k/IBM360/MIPS32/arm anfangen, und versuchen die bekannten Probleme zu beheben.
   Ein interessantes alternatives Problem wäre eine möglichst kleine, aber noch hinreichend schnelle 32 Bit CPU zu entwerfen. (Da gibt es aber auch schon Vorschläge.)

   Echte Harvard Architekturen mit getrenntem RAM für Code und Daten gehören für mich zu den Spezialisten für Signalverarbeitung, wo das Code RAM auf dem CPU Chip integriert ist. Und da wäre dann auch 24 Bit breites RAM für die Daten hilfreich.

   Antworten

6. Betreffend Bernds Vorschlag für einen verbesserten Z80 (16 Bit CPU):
   1) 24 Bit Code Worte sind nicht erforderlich, und von der erforderlichen Speicherbandbreite nicht sonderlich effizient. Man kann darum herumkommen indem man:
   – variabel lange Befehle verwendet. Dazu ist es hilfreich die Länge des Befehls in den obersten 2-3 Bits zu kodieren.
   – einen kleinen Code Cache, oder zumindest Code Buffer implementiert, und den Code z.B. immer in 2 alignten 16 Worten lädt.
   Damit kann ein aktueller Arm mit nur 16 Bit breitem RAM noch effizient laufen.

   2) statt 2x 64k Worte oder 2x 64k Byte RAM zu ermöglichen, hat man mehr davon Banking oder Segmente zu implementieren. Das muß nicht so aussehen wie auf dem 8086. Damit hat ein Prozeß 64k Daten zur Verfügung, optional 64k Stack, optional 64k String und aus Software Sicht beliebig viel Code. (Auf der PDP11 gab es unter Modula2/RT11, hat sehr gut funktioniert. (Die Bank Umschaltung hat der Compiler gemacht, war nicht sichtbar für den User.))

   3) solange man einigermaßen ausreichend Register hat, sind komplizierte Addressmodi nicht erforderlich. Register Offset sollte aber dabei sein, das gibt kürzeren Code. ggf. alternativ Register | Offset (concat) wenn der zugehörige Addierer zu viel Platz braucht.

   Antworten

7. Moin,

   weils gerade zum Thema passt, und auf HN aktuell ist:

   https://en.wikipedia.org/wiki/Little_man_computer
   http://peterhigginson.co.uk/LMC/ <- LMC Simulator

   ciao,Michael

   Antworten

8. Sehr schön, dass hier auch noch ein paar andere Betrachtungen dazu gekommen sind. Dazu wahscheinlich heut Abend mehr.

   Jetzt mal kurz (mehr oder weniger jedenfalls) zu einem Detail bei Bernd’s Befehlssatz; ich hab da nämlich noch ein Problem: Und zwar kenn ich vom 6502-Befehlssatz so eine Tabelle, wo die Opcodes bitweise aufgeschlüsselt sind: Dazu wird ein Byte in zwei Hälften, den Nibblen, zerlegt. In den Zeilen stehen dann die Hi-Nibble in den Spalten die Lo-Nibble. Anhand dieser Tabelle lässt sich eine Systematik in die Bitmuster der Opcodes bringen oder daraus ablesen. Ein Beispiel dafür findet man in diesem Datenblatt eines 65C02s von WDC auf Seite 22. Die Frage, die sich mir jetzt stellt ist, ob es so eine Zusammenstellung auch für Z80-Opcodes oder andere Befehlssätze gibt, oder ob das ein Spezifikum in den Dokumetationen des 6502-Befehlssatzes ist?
   Und falls jemand fragt, Was ich davon habe oder mir davon verspreche? – Eine schnellere Übersicht für einen groben Vergleich der Befehlssätze.

   Antworten

9. Hans,
   Tabellen, die die Befehle einer CPU über die Codierung auflisten gibt es für verschiedene CPUs.
   Das muß nicht über Nibbles kodiert sein. IBM 360 und mc68k sind über Nibbles kodiert, RISC CPUs z.B. in der Regel nicht. Es gibt CPUs bei denen in einem 32 Bit Wort 3 Stück 10 Bit Befehle kodiert sind. Die anderen beiden Bits geben das Befehlsformat an, oder kodieren ein optionales Return (bei Forth CPUs).

   Für mich ist das erste, was mich an einer CPU interessiert das Registermodell, und wie viele Adressen ein Befehl hat. Dann erst welche Befehle und Adressmodi es im einzelnen gibt.

   Antworten

10. Moin,

    gerade der Z80 war mit seinen zum Vergleich einfacheren Memnonics, für die selben Befehle quasi wie Basic zu programmieren. Und die Z80 Op Code Tabelle ist quadratisch genug, dass nach einiger Übung die Codes im Kopf waren.

    http://z80-heaven.wikidot.com/opcode-reference-chart

    ciao,Michael

    Antworten

11. Michael K. schreibt:

    eine Registermaschine schnell zu emulieren …
    Als Einstieg in die Theorie sollte vorher SICP durchgearbeitet werden.

    Ah ja. SICP, also Structure and Interpretation of Computer Programs. Hab mir das Buch heut‘ Nachmittag in der Bib mal angesehen. Es macht einen brauchbaren Eindruck, ist mir momentan aber zu Umfangreich. Und dann hab ich derzeit auch nicht so grosse Lust, mich in Scheme rein zu knien, obwohl es am Anfang erklärt wird.
    „Rechnerorganisation und -entwurf“ von Patterson und Hennessy erscheint mir gerade sinnvoller, vor allem auch in Anbetracht der gesammten Serie über CPUs, die Bernd in letzter Zeit schreibt.

    —
    Andreas Buschmann schreibt:

    Ich komme aus der Software Ecke, und habe mit Embedded Systemen nie viel am Hut gehabt. Daher war für mich was kleineres als eine 32 Bit CPU eher uninteressant.

    Ich dagegen komme eher aus der Hardwareecke und beschäftige mich gerade mit Embedded Systems. Deshalb sind für mich gerade oder besser: immer noch auch 8 Bit CPUs interessant, obwohl man bei den eingebetteten Systemen ja besser von MCUs redet. (Denn neben der reinen CPU sind da ja noch diverse Perepherieschaltungen mit auf dem Chip.)

    (Ich habe den mc68k immer als verkrüppelte 32 Bit CPU betrachtet.)

    Interessant. 🙂

    Echte Harvard Architekturen mit getrenntem RAM für Code und Daten gehören für mich zu den Spezialisten für Signalverarbeitung,

    Nun ja, die Atmel AVR Controller verfügen auch über Harvard-Architektur, wobei der Befehlsspeicher in 16-Bit Worten organisiert ist. Aber deshalb sind es immer noch Microcontroller, die sich zum Teil zwar auch für DSP-Aufgaben eignen, aber keine speziellen DSP-Chips sind.

    Tabellen, die die Befehle einer CPU über die Codierung auflisten gibt es für verschiedene CPUs.

    Hm… – also entweder hab ich die dann noch nicht entdeckt, oder wir „reden“ hier gerade aneinander vorbei.

    Das muß nicht über Nibbles kodiert sein. IBM 360 und mc68k sind über Nibbles kodiert, RISC CPUs z.B. in der Regel nicht.

    Ah ja, nun gut. Mit IBM 360 usw. hatte ich nie zu tun und mc68k gibt es AFAIK ja mittlerweile nicht mehr. Jedenfalls, was die reinen CPUs angeht. Von der Controllerschiene, die inzwischen unter dem Label FreeScale firmiert, hab ich keine Ahnung.

    Aber ich glaube, ich sollte mich dann wohl mal selbst ans Werk machen, und mir diese Tabellen für Z80 und die 8 Bit AVRs selbst erstellen…

    Für mich ist das erste, was mich an einer CPU interessiert das Registermodell, und wie viele Adressen ein Befehl hat. Dann erst welche Befehle und Adressmodi es im einzelnen gibt.

    Was meinst Du mit „wie viele Adressen ein Befehl hat“ genau? Die Bitbreite der Befehlsworte oder was?

    Antworten

12. Na Bravo! – Da hab ich jetzt wieder so lange an dem Kommentar gewerkelt, dass er sich mit dem letzten von Michael K. überschnitten hat. Anyway danke für den Link. Dann brauch ich mir die Arbeit doch nicht mehr machen. – Bzw. nur noch für die AVRs…

    Antworten

13. zu FreeScale:
    die haben das selbe Registermodell wie der mc68k, und die selben Assemblerbefehle, aber eine andere Codierung der Assemblerbefehle. Also Ähnlich wie die Umstellung 8080 zu 8086. Ein Problem mit dem mc68k war, daß die Codierung der Befehle es sehr schwer gemacht hat die Länge eines Befehls zu erkennen, und daß man den mc68k deswegen nicht mehr schneller machen konnte.

    zu „wie viele Adressen ein Befehl hat“:
    so wie ich es gelernt habe gibt es:
    – 0-Adress Befehle, in denen ein Register impliziert ist oder keines benötigt wird
    z.B.: return, rti, halt, swap, pop
    werden sehr häufig bei Stackmaschienen verwendet
    – 1-Adress Befehle, die einen Parameter haben und alle weiteren ggf. benötigten Register implizit sind
    z.B.: call, jump, add to Akku, push
    – 2-Adress Befehle, bei denen zwei Operanden angegeben werden und einer davon überschrieben wird
    z.B. ein „add a b“ welches die Inhalte von Register A und B addiert, und das Ergebnis in B ablegt.
    Viele 16Bit CPUs sind 2-Adress Maschienen. z.B. mc68k, PDP11
    – 3-Adress Befehle
    z.B. ein „add a b c“ welches die Inhalte von Register A und B addiert, und das Ergebnis in C ablegt.
    Die Idee war, daß eine Operation keinen ihrer Operanden zerstören muß, um „move REG, REG“ einzusparen.
    Die VAX und die meisten 32 Bit RISC CPUs sind 3-Adress Maschinen
    Die IBM 360 hat 2-Adress und 3-Adress Befehle, aber auch die 3-Adress Befehle zerstören einen Operanden. Es gibt da Adressierungen mit REG REG Offset.
    – 4-Adress Befehle
    z.B.: Bit extract, insert und mask Befehle, sowie die 32 Bit x 32 Bit -> 64 Bit Multiplikation welche 2 Register für das Ergebnis benötigt.

    Die IBM 360 hat 16 Integer Register von 32 Bit.
    Es gibt dort z.B. 16 Bit Befehle
    8 Bit Opcode, 4 Bit Zielregister, 4 Bit Register
    sowie 32 Bit Befehle
    8 Bit Opcode, 4 Bit Zielregister, 4 Bit Register, 4 Bit Register, 4 Bit Offset
    Die Codierung ist sehr schön regelmäßig (Implementierung über Microcode)

    Der mc68k hat 8 8 Integer Register von 32 Bit.
    Es gibt dort z.B. 16 Bit Befehle
    8 Bit Opcode, 3 1 Bit Zielregister, 3 1 Bit Register
    Den CPU Designern war 4 Bit pro Register im Befehl zu verschwenderisch, deshalb wurde der Registersatz in zwei Hälften geteilt. (Adressen/Daten)
    Der mc68k hat auch 32 Bit und 48 Bit Befehle um z.B. Konstanten zu laden, oder für einen JUMP.

    Die klassischen RISC CPUs (Berkley, MIPS, Sparc, HP-PA, Alpha) haben alle 32 Register, ein 32 Bit Befehlswort und 3-Adress Befehle. Dabei werden dann in jedem Befehl für die Adressierung der Register 15 Bit benötigt. Um alle Befehle unterzubringen, und auch Platz für Konstanten im Befehl zu haben, hat jede der CPUs mehrere unterschiedliche Befehlsformate.

    Die ARM CPU hat 16 Register statt 32, um Adressbits für die Adressierung der Register zu sparen. (3-Adress mode) Im Thumb mode sind sogar nur 8 Register erreichbar, und es wird ein 2-Adress mode verwendet.

    Antworten

14. @Andreas Buschmann:
    Ah. Danke für die Erklärungen; wieder was dazu gelernt. Nach dieser Adressordnung der Befehle hat der 6502 dann nur 0- und 1-Adressbefehle. So Sachen wie MOV a,b gibt’s da nicht; sondern das muss man dann in 2 Befehle auftrennen: LDA a; STA b;

    Hab mir jetzt auch mal ein paar Datenblätter der 68HCxxx-Controller von FreeScale herunter geladen und angesehen. Deren CPU hat ja eine grosse Ähnlichkeit mit dem 6502 und der Befehlssatz scheint in weiten Teilen auch identisch zu sein. (Wenn man dann mal ein bischen auf die Geschichte der Prozessoren guckt, verwundert das auch nicht.)

    Dann wäre noch festzustellen, dass die 8-Bit AVRs wohl 2-Adress-Befehle haben, soweit ich das bisher verstehe.

    Antworten

15. 32 Bit Vergleiche sind bei einem 8/16 Bitprozessor nicht so passend ähnlich wie Lua das es als die 8 Bitter in waren noch gar nicht gab.

    Für alle die zwar mitreden aber nicht mal die verschiedenen Adressierungsarten kennen ganz neu ein Aufsatz mit den Grundlagen dazu auf der Webseite:
    http://www.bernd-leitenberger.de/adressierung.shtml

    Antworten

16. Was es aber zu 8bit Zeiten schon gab war Sweet16 von Steve Wozniak. Eine 16 Bit CPU die auf dem 6502 emuliert wurde. Der Vergleich von Lua die als moderne Registermaschine kleiner und schneller ist als vergleichbare Stackmaschinen von Perl, Python oder Ruby, ist damit durchaus gegeben. Der Sweet16 Interpreter war erheblich schneller und mit nur 300 Byte auch sehr viel kleiner als die sonst üblichen Stanford und San Diego P-Code Interpreter. Selbst minimale Forth Systeme waren in dieser Zeit meist größer.

    Antworten

17. Als Beispiel für eine extravagante 16 Bit Architektur möchte ich mal das folgende vorschlagen:

    Ziel 16 Bit Architektur deren erste Implementierung relativ klein sein kann, und die Reserven für den späteren Ausbau hat.

    Ich nehme mir den 6502 als Vorbild, plus Superakkumulator
    Registermodell:
    A: Superakkumulator, besteht aus mindestens 4 St. 16 Bit Worten, ggf. in späteren Implementierungen mehr.
    C: 24 Bit Register zum Zusammenbauen von Konstanten (optional, wie beim Transputer)
    X: 24 Bit Adressregister, ggf. in späteren Implementierungen 32 Bit
    Y: 24 Bit Adressregister, ggf. in späteren Implementierungen 32 Bit
    PC: 24 Bit Adressregister
    SP: 8-12 Bit Stackpointer

    Zeropage: Die 16 Bit Worte an den Adressen 0-255
    Stack: Die 16 Bit Worte an den Adressen 256-511 (ggf. müssen das 24 Bit Einheiten sein)
    Hier wäre noch zu klären ob Byteadressierung besser wäre, und ob man jeden Bereich auf z.B. 1024 Bytes vergrößern sollte.
    Dann wären die meisten Befehle 6Bit Code 10 Bit Data,
    Der C Befehl 2Bit Code 14 Bit Data.
    48 Befehle kann aber knapp werden.

    Befehlsformate:
    a) ALU Operationen
    Ein Operand ist in A, der zweite Operand ist in der Zeropage oder eine Konstante oder eine Konstante /- C. Ergebnis wird nach A geschrieben, dabei wird das oberste Element in A überschrieben.
    b) Laden und Speichern von A/X/Y/PC/SP/C aus bzw. in Zeropage.
    c) 12 Bit Konstante in die obere Hälfte von C laden. ggf. 14 Bit?
    d) Laden und Speichern von A an die Adressen X, Y, C, jeweils auch mit festem Offset. Bedingte und unbedingte Sprünge an diese Adressen und an A. Call.
    e) Befehle ohne Parameter wie return, pop, halt, debug
    f) Befehle, die mehr als 1 16 Bit Wort von A verwenden wie:
    Multiplikation: 1 Wort von A (destruktiv), 1 Wort aus Zeropage oder C Konstante, Ergebnis sind 2 Worte auf A.
    MAC: 1 Wort von A (destruktiv), 1 Wort aus Zeropage oder C Konstante, das Produkt wird zu den obersten 3 Worten auf A addiert.
    Bit insert und extrakt auf 2 16 Bit Worten
    g) Addressoperationen: X/Y /-= Wort aus Zeropage oder C Konstante oder Konstante
    h) Stack Befehle ohne Parameter (ähnlich wie e) da ansonsten die Anzahl der möglichen Befehle doch knapp sein kann.

    Keine Division, keine Wurzel.
    zu I/O habe ich noch keine Idee.
    zu einer MMU habe ich noch keine Idee.

    Die Befehle sollen alle 16 Bit lang sein, große Konstanten werden in C zusammengebaut.

    Die wichtigsten Optimierungen wenn mehr Transistoren zur Verfügung stehen sind:
    – Zeropage auf dem Chip
    – Stack auf dem Chip
    – 256 Worte Code Cache.
    – ggf. später noch ein B Register

    p.s. gibt es einen vernünftigen Begriff für eine 16 Bit Einheit? Für mich ist das normalerweise ein Halbwort, aber in diesem Zusammenhang passt das überhaupt nicht.

    Antworten

18. Moin,

    wenn ich eine CPU für Bernd designen würde, dann würde da erstmal ganz kleine 8bit oder gar 4bit Alus die Arbeit machen, oben drüber befindet sich ein horizontaler Microcode, da drüber dann der vertikale Microcode. In diesem ist eine BL-P-Maschine implementiert. Ein Control Program Feature übersetzt dann Stanford-P-Code und UCSD-P-Code in BL-P-Code und stellt die Stanford und UCSD Laufzeitumgebungen zur Verfügung, so dass alle echten Pascal Programme laufen.

    ciao,Michael

    Antworten

19. @Andreas Buschmann:
    Das klingt nach einem interessanten Design. 🙂
    Aber ich hab da neben ein paar Vorschlägen auch noch Fragen:
    Zum Superakkumulator: Du schreibst, der soll „aus mindestens 4 St. 16 Bit Worten“ bestehen. Was soll das „St.“ in dem Fall bedeuten? – Stück, Stapel oder was?
    Bei dem C-Register frag ich mich gerade, ob man dafür nicht auch die Zeropage benutzen kann, oder den unteren Bereich des Stack? (Für alle, die den 6502 nicht kennen: Da liegt der Stack fest an den Adressen 256 bis 511; er ist also nicht verschiebbar, wie bei anderen Prozessoren.
    Die Zeropage ist, wie ihr Name schon sagt, die nullte Seite im Speicher, zu deren Adressierung nur die unteren 8 Bit, (also das LoByte) der Speicheradresse heran gezogen werden. Sie lässt sich dadurch schneller ansprechen und dient bei bestimmten Adressierungsarten auch als „Zeigerbank“, da man dort Zeiger unterbringt (bringen kann), über die sich andere Speicherbereiche adressieren lassen.)

    Adressregister: Ich nehme an, Du willst die Register so breit machen, um einige der „interessanten Adressierungsarten“ über die Zeropage (LDA ($nn),Y) einzusparen, um den Speicherzugriff zu beschleunigen, richtig? Dazu hab ich erst geschrieben: „Dazu würde ich die Register erst mal 16 Bit breit machen und später dann gleich von 16 auf 32 Bit erweitern.“ – Aber 16 Bit Adressregister sind bei einem 24 Bit breiten Adressbus Unsinn, wenn nicht wieder so ein Quark wie bei Intel’s x86er dabei heraus kommen soll. Wahrscheinlich wäre es in Anbetracht zukünftiger Erweiterungen des Adressraums eher sinnig, sie gleich 32 Bit breit zu machen.

    Dann würde ich darüber nachdenken, ob es sich lohnt, die Register ebenfalls an die ALU anzuschliessen. – Wie breit soll die eigentlich sein? – 16 Bit oder mehr? (Nach Deinem Kommentar vom 22.6. zu schliessen, wahrscheinlich schon 16 Bit. Könnte aber auch mehr sein.)
    Was soll ein 12 Bit Stackpointer? – Soll der durch den Stack belegte (belegbare) Adressbereich 2^12 Worte umfassen, wie breit sie auch immer sein mögen? – Oder wie soll man das verstehen?

    Der C Befehl 2Bit Code 14 Bit Data.

    Ein spezieller Befehl zum Zugriff auf das C-Register, oder was soll das sein?

    Die weiteren Vorschläge zum Befehlssatz entsprechen in etwa dem des Originals, wenn man von der Multiplikation und den Bit Insert/-Extract Befehlen absieht. – Aber was soll MAC sein?

    Division und Wurzel, evtl. Logarithmus-/Exponentialfunktion sowie trigonometriesche Funktionen in einer FPU? – Hätte ich nix dagegen. 🙂

    Zu I/O und MMU: Vielleicht enthält ja mein Aufsatz über die Speicherverwaltung von C64/C128 eine Inspiration dazu. – Hab ja keine Ahnung, ob Du eines der Geräte hattest oder noch hast.

    Die Zeropage und den Stack auf dem Chip klingt interessant, aber wie willst Du dann mit dem RAM-Speicher verfahren, der sich ebenfalls an diesen Adressen befindet?

    Bei einem 24 Bit breiten Adressbus stellt sich mir auch die Frage, was die MMU da eigentlich leisten soll? – Mir fallen dazu nur Speicherschutzmechanismen ein, weil ich Bankswitching in einem 24 Bit breiten Adressbus, also 16 MB erst mal nicht für nötig halte. – Andrerseits, wenn man an heutige Speicherausstattungen denkt… – Aber das soll ja ein 16-Bit System sein, und kein 32-Bit System.

    Etwas später kam ich für das I/O-System auf die Idee, es wie beim Original als Memory Mapped I/O System auszulegen. Dann hätte die MMU die Aufgabe, je nach Zugriffberechtigung entweder die Register der Perepheriebausteine oder aber den an dieser Stelle befindlichen Speicher einzublenden. Betriebssystem und LoLevel Treiber dürften darauf zugreifen, andere Software bekommt in diesem Bereich nur RAM zu sehen. Das BS müsste also so gestaltet werden, dass Anwendersoftware diesen Bereich nicht ohne besonderen Aufwand verwenden kann.

    p.s. gibt es einen vernünftigen Begriff für eine 16 Bit Einheit? Für mich ist das normalerweise ein Halbwort, aber in diesem Zusammenhang passt das überhaupt nicht.

    Also in Turbo Pascal war ein WORD 16 Bit breit und ein 32 Bit breites Datum ein DWORD. Das würde bei dem vorgeschlagenen CPU Design mMn auch einen Sinn ergeben.

    Und zuletzt kam nach mehmaligem Korrekturlesen noch die Frage auf, ob die CPU Multiprozessorfähig sein soll oder nicht? Also soll sie ähnlich wie der Transputer auch gleich dafür ausgelegt sein, neben anderen CPUs arbeiten zu können, oder eher nicht? (Begriffe wie SIMD bzw. MIMD schwirren mir dazu durch den Kopf.)

    Antworten

20. @Hans:
    Der Superakkumulator ist ein Register, welches deutlich breiter ist als ein normales Register.
    Man braucht ein doppelt breites Register für das Ergebnis einer Multiplikation;
    und auch für Bit insert/extract und shift/rotate über mehr als die einfache Wortbreite.
    Man braucht ein dreifach breites Register für das Ergebnis einer Multiplikation Addition (MAC).
    (Ist ein Spezialbefehl für Vektor- und Matrixmultiplikationen. A = m*n)

    Um Spezialbefehle für das Lesen und Schreiben des Superakkumulators zu vermeiden würde ich den als einen Stack von mindestens vier Elementen implementieren. (MAC braucht ein drei Worte breites Register auf dem akkumuliert wird, und einen der Multiplikanden auf dem Stack, da die Befehle alle nur einen Parameter haben sollen. Das St. steht dann für Stück.

    Das C Register ist zum Zusammenbauen von Konstanten gedacht, so daß für alle Befehle 16 Bit ausreichen.
    Für eine 24 Bit Adresse wird dann mit einem c) Befehl die obersten 14 Bit des C Registers geladen. Der Rest bleibt 0. Ich kenne den 6502 und seine Adressierungsarten nicht gut genug um erkennen zu können, ob man ohne C Register auskommt.

    X und Y sollten immer mindestens 24 Bit breit seine, und bei einer 32 Bit Erweiterung dann auch 32 Bit breit. X und Y sollen immer den vollen Adressbereich abdecken können. (Eine Ausnahme wäre wenn durch Banking oder einer MMU mehr Speicher im Rechner sein kann als adressierbar ist.)

    Mit ist nicht klar, ob X und Y an die normale ALU angeschlossen sein müssen, oder ob die einen eigenen 24 Bit breiten Addierer brauchen. Dazu müßte man eine Simulation machen.

    Der 8 bzw. 12 Bit Stackpointer verweist in Page 1 für call und return. Kann man das anders oder besser machen?

    Wenn die Zeropage und der Stack auf der CPU implementiert sind wird das RAM an den zugehörigen Adressen nicht benutzt.

    Eine optionale MMU hat drei mögliche Aufgaben:
    a) Zugriffsschutz
    b) mehr RAM verfügbar machen als die CPU adressieren kann
    c) virtueller Adressraum
    Bei einer 16Bit CPU macht aus meiner Sicht pageing keinen Sinn.
    Eine einfache segmentierte MMU reicht völlig aus:
    Es gibt z.B. vier MMU Register, welche jeweils einen Adressrange definieren.
    jedes besteht aus drei Elementen: virtual base V, length L, physical base P.
    Eine virtuelle Adresse ist nur zugreifbar, wenn wie in einem Bereich [Vn .. Vn Ln) liegt.
    Eine Adressumsetzung wäre dann physikalische Adresse = virtuelle Adresse – Vn Pn.

    Meine Idee war für eine kleine CPU. Die muß nicht mehrprozessorfähig sein. Ein relativ eng angebundenes Ethernet oder serieller Bus würden vielleicht Sinn machen, aber ich dachte an eine erste Implementierung, die kleiner als ein mc68k oder 8086 ist.
    Aus meiner Sicht lohnt sich ein eng verbundenes multiprozessorfähiges System erst wenn die CPU schon 32 oder 64 Bit ist, Cache hat und ggf. eine FPU on chip ist.

    Antworten

21. @Andreas Buschmann:
    Ah, danke für die Info. Das ist wirklich eine exotische bzw. extravagante Architektur. Aber gut, das kann man ja mal durchspielen… – wenn man es kann.

    Der Superakku ist echt ein Unikum, soweit ich das beurteilen kann. Als Stack organisiert würde er mMn aber wirklich nur für besondere Operationen der Mathematik taugen. Also für Ergebnisse von Multiplikationen von Skalaren oder Vekor- / Matritzenelementen.

    Das C-Register würde wahrscheinlich sinnvoll werden, weil spezielle Konstanten sonst im Akku zusammen gebaut werden müssten. Zu den Adressierungsarten des 6502 komme ich weiter unten noch.

    Ich vermute, dass es sinnvoll ist, X und Y auch an die ALU anzuschliessen, wenn man die (berüchtigte) Zeigerarithmetik von C/Cpp effektiv in Assembler umsetzen will, so dass für die Adressberechnungen möglichst wenig Overhead entsteht.

    Wenn der Stackpointer nur für call und return genutzt wird, ist das okay. Und da wir schon mit unterschiedlichen Wortbreiten operieren, halte ich es für sinnvoll, dass der Stack auch Wortweise organisiert wird, wobei ein Wort 16 Bit breit sein sollte. Dann kommt man auch bei späteren Erweiterungen auf 32 Bit mit 2 Worten für die Rücksprungadresse aus. Bei 12 Bit breite wären es 3 Worte und bei 8 Bit eben 4 Worte.
    Ein weiteres Problem ergibt sich auch bei Hochsprachen, die die Parameterübergabe über den Stack organisieren. Das ist beim klassischen 6502 nicht sinnvoll, weil der eben nur 256 Byte gross ist. Entsprechende Hochsprachen (etwa C und Pascal) müssen ihren Parameterstack da per Software realisieren, weil der CPU-Stack schlicht zu klein ist. Man denke etwa an den Quicksortalgorithmus, der ein grosses Array sortieren soll. Rekursiv implementiert bricht der irgendwann wegen Speichermangel auf dem Stack ab, wenn er nur den CPU-Stack nutzt.

    Das RAM unter Zeropage und Stackpointer unbenutzt zu lassen, wenn sie in der CPU selbst sitzen, ist okay. Da dürften die 512 Worte bei Speicherkapazitäten im MB-Bereich nicht sonderlich ins Gewicht fallen. Die MMU wäre auch okay und Multiprozessorfähigkeiten braucht man ja auch nicht unbedingt.

    Jetzt noch zu den Adressierungsarten des 6502:
    Da ist zunächst einmal die unmittelbare Adressierung, d.h. ein auf den Befehl folgendes Byte wird als Konstante betrachtet, die in eines der Register A, X oder Y zu laden ist oder als Operand für Arithmetik oder Logikbefehle dient.
    Manche Befehle beziehen sich auch direkt auf den Akku oder ein anderes Register, das wird als „Implied Adressing Mode“ bezeichnet.
    Dann gibt es die absolute Adressierung, wobei die nachfolgenden Bytes als Adresse aufgefasst werden. Dabei spielt jetzt auch die Zeropage eine Rolle, denn je nach Opcode wird entweder nur das folgende Byte als Adresse verwendet, dann erfolgt der Zugriff auf die Zeropage. Oder das nachfolgende Wort, womit jede Adresse im Speicher angesprochen werden kann.
    Dazu gibt es die Möglichkeit, die Register X oder Y als Index zu verwenden, der zur absoluten Adresse dazu addiert wird. Das nennt sich dann indizierte Adressierung.

    Als letztes wären da noch die indirekt indizierten Adressierungsarten, die immer über die Zeropage laufen. Da ist zum einen die indirekte X-Adressierung, mit der man eine Adresstabelle in der Zeropage ansprechen kann. Der Operand des Befehls gibt die Basisadresse der Tabelle in der Zeropage an, der Index X wird zu dieser Basis dazu addiert. Das Ergebnis dieser Operation ist eine Adresse in der Zeorpage, die einen Zeiger auf jene Adresse im Speicher enthält, auf die man zugreifen will.
    Zum anderen gibt es die indirekte Y-Adressierung. Der Operand gibt eine Adresse in der Zeropage an, die einen Zeiger auf eine Adresse im Speicher enthält. Zu dieser Adresse wird der Wert des Y-Registers addiert, womit man die Zieladresse erhält, auf die mit der Operation zugegriffen wird.
    Und falls das irgendwer jetzt nicht sofort verstanden hat, ist das nicht tragisch. Ich hab auch eine Weile gebraucht, bis ich es verstanden hatte.
    Der Vollständigkeit halber sei noch auf die relative Adressierung hingewiesen, die nur bei den Verzweigungs-Befehlen (Branch-Befehlen) verwendet wird. Hier wird der Abstand relativ zum Programmcounter angegeben, der von -128 bis 127 reicht.

    Antworten

22. @Hans:
    Den Superakku hatte ich mir ursprünglich für eine 32 Bit CPU ausgedacht, weil ich mir nicht gefallen hat, wie vorhandenen CPUs eine 32b x 32b -> 64b Multiplikation organisiert ist. Da ist das Umladen des Ergebnisses aus As = A1 | A2 | A3 in normale Register auch kein Problem (2 Adress Befehl).

    Bei einer kleinen 16 Bit CPU mit 1 Adress Operationen wollte ich aber nicht so viele von den möglichen Befehlen für das Lesen des Superakkus verschwenden, deshalb die Organisation als Stack (für normale Befehle, die auf 16 Bit Worten arbeiten).
    As besteht dann aus den Worten A1, A2, A3, A4, und man kann direkt nur auf A1 zugreifen.
    Eine Multiplikation ist dann:
    ( A2 | A3 ) := Operand x A1, und A1 wird gepopped
    Ein MAC (MultiplyAdd) ist dann
    ( A2 | A3 | A4 ) = Operand * A1, und A1 wird gepopped.

    Da man den Stack nun mal hat, kann man auch alle seltenen Befehle als 0 Adress Befehle implementieren, das spart Platz im Opcode Space.
    A2 := A2 OP A1, und A1 wird gepopped.
    In späteren Implementierungen kann man z.B. 32 Bit Operationen nachrüsten wie:
    ( A3 | A4 ) OP= ( A1 | A2 ), und A1 und A2 werden gepopped.

    Eine Festkomma Multiplikation wäre z.B.
    Push Operand A1 := Operand, alle anderen Ax Inhalte 1x weiterschieben
    MUL Operand ( A1 | A2 ) := A1 * Operand, alle anderen Ax Inhalte 1x weiterschieben
    Shift32 Const ( A1 | A2 ) >>= Const
    Pop A1 := A2, alle anderen Ax Inhalte 1x zurückschieben

    Ich hatte überlegt, für die Zeropage 10 Bit Adresse in jedem Befehl zu verwenden.
    Dann hätte man entweder 1024 Bytes oder 1024 Worte. (Ich weis nicht was besser ist.)
    Der Stack sollte 1024 24 Bit Adressen groß sein.

    Antworten

23. @Andreas Buschmann:
    Hast Du zu dem Prozessorentwurf eigentlich auch schon mal eine Befehlsliste erstellt, wie Bernd sie hier für seinen Prozessor entworfen hat?
    Da ich nur 6502-Assembler kann, der aber keine Multiplikationen kennt, hab ich damit bisher auch keine Erfahrungen, und kann Deine Idee deshalb leider nicht so sachgerecht bewerten, wie ich es mir selbst wünschen würde. Bin jetzt zwar dabei, daran was zu ändern, aber das wird trotzdem noch eine Weile dauern.

    Vielleicht kann Michael K. ja zwischenzeitlich noch den einen oder anderen qualifizierten Kommentar abgeben…

    Antworten

24. Noch mal zu:

    p.s. gibt es einen vernünftigen Begriff für eine 16 Bit Einheit? Für mich ist das normalerweise ein Halbwort, aber in diesem Zusammenhang passt das überhaupt nicht.

    Ich sitze gerade an einem Rechner mit Windows 7 und hab da den mitgelieferten Taschenrechner geöffnet. Der bietet in dieser Version u.a. eine spezielle Ansicht und Oberfläche für Programmierer an. Da hat man links am Rand zwei Auswahlfelder mit (Push)Buttons, wo man zwischen Byte, Word, Dword und Qword wählen kann, wobei die Zuordnug so ist:
    Byte: 8 Bit,
    Word: 16 Bit
    Dword: 32 Bit
    Qword: 64 Bit

    Im zweiten Feld kann man das Zahlensystem auswählen, in welchem man die Zahlen angezeigt haben möchte. Zur Auswahl stehen die 4 üblichen Verdächtigen: Binär, Oktal, Dezimal und Hexadezimal.

    Dazu gibt es unter der Zahlenanzeige noch ein Feld, wo einem immer die Bitmuster der Zahlen angezeigt werden, jeweils zu 4 Bits gruppiert. Das alles aber nur für ganze Zahlen. – Wäre ja auch zu schön, wenn er da auch noch die Bitmuster von Fliesspunktzahlen anzeigen würde. – Aber andrerseits braucht man die auch nicht so oft. Oder falls doch, dann gibt es ja noch andere Programme, die sie einem anzeigen. – Oder man schreibt sich selbst eines.

    Soviel noch mal dazu, obwohl das für viele hier sicher auch ein alter Hut ist. Aber egal.

    Antworten

25. p.s. gibt es einen vernünftigen Begriff für eine 16 Bit Einheit? Für mich ist das normalerweise ein Halbwort, aber in diesem Zusammenhang passt das überhaupt nicht.

    …Windows 7…
    Byte: 8 Bit,
    Word: 16 Bit
    …Soviel noch mal dazu, obwohl das für viele hier sicher auch ein alter Hut ist. …

    Das Problem ist, das ist die x86 spezifische bzw. Windows spezifische Definition von Byte und Wort. In anderen Umgebungen haben diese Begriffe eine andere Bedeutung.

    In der Datenübertragung wird Octet für ein 8Bit Wort verwendet, und wie ich jetzt gefunden habe gibt es den Begriff Hextet für ein 16Bit Wort. (Wird inoffiziell für die Darstellung von IPv6 Adressen verwendet.) Ich erinnere mich vage an einen anderen Begriff aus einem der Bücher über Computerarchitektur. Ich kann mich aber nicht erinnern in welchem das vorkam. (Einer der Bände von „The Art of Computer Programming“ oder einer der Hennessy Patterson.)

    Antworten

26. Ja, dass die Begriffe je nach Umgebung eine andere Bedeutung haben, ist mir auch schon aufgefallen. Insbesondere, wenn man in der englischen Wikipedia nachschlägt. Hab mir deshalb mal erlaubt, die Frage weiter zu geben, und zwar nach dort, denn dort sind auch einige Informatiker unterwegs.

    Antworten

27. So, nachdem die Diskussion der Frage im anderen Blog im wesentlichen gelaufen ist, würde ich sagen, dass man hier am Besten von 16-Bit-Worten spricht, u.a. weil das eben die „natürliche Breite“ der Arbeitsregister dieser CPU (von Andreas Buschmann) ist. Alles andere ergibt sich dann daraus.

    Antworten

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.