Prozessorarchitektur

[student (Gast)]

Hallo,

ich versuche gerade die im Anhang befindliche Prozessorarchitektur zu 
verstehen, die unser Prof angefertigt hat.

Leider bin ich halbwegs genormte, technische Skizzen gewohnt, 
vorzugsweise mit Beschriftung und irgend einer kleinen Beschreibung 
dazu. Deshalb gestaltet sich mein Unterfangen als ein bisschen 
schwierig.

Die Nummern 1 - 19 hab ich nachträglich in die Folie hinzugefügt, der 
Rest ist original.

Ich schreib mal auf, was ich mir dazu so Denke:

01 - ALU Steuereingang, selbsterklärend
02 -
03 -
04 -
05 -
06 - Eine Bitfolge die in Kombination mit dem "?" Kästchen den
     Mikroprogramm-Counter passend verändert um zum Beispiel Speicher
     im ROM zu sparen o.ä
07 - die Adresse im ROM an der sich der nächste Mikrobefehl befindet, 
das
     ist dann wohl "verkettete Liste"-mäßig realisiert
09 - "hat die Racecondition gegen die 8 gewonnen ;)"
     das Mikroprogramm-Counter-Register. was das Rote Kästchen
     darunter darstellen soll, weiß ich nicht
10 -
11 -
13 - ich vermute mal das ist die Register-Write Steuerleitung
14 - Der Datenbus
15 - Memory Data Register
16 - Memory Address Register
17 - Operand A der ALU
18 - Operand B der ALU
19 -
*/** nur Gezeichne, ohne Funktion

Irgendwie vermisse ich bei den Registern die Anbindung an den Datenbus 
um irgendetwas in diese zu Speichern. Sollte 13 den Registern das 
Schreiben befehlen, wird wohl 10 oder 11 den Registern das Lesen 
befehlen. Nur da blicke ich nicht wirklich durch.

Soll 10 und 11 vllt Datenbus(ähnliche) Strukturen darstellen, und 2 und 
3 die Register schreiben lassen?

Dabke für eure Mühe

[student (Gast)]

das Bild

[Heinz V. (heinz_v)]

student schrieb:
> was das Rote Kästchen
>      darunter darstellen soll, weiß ich nicht

Da es mit der ALU in direkter Verbindung steht, dürfte es das Carry Flag 
sein.

[(prx) A. K. (prx)]

student schrieb:
> Irgendwie vermisse ich bei den Registern die Anbindung an den Datenbus
> um irgendetwas in diese zu Speichern.

Ich nicht. Wenn die Pfeile die Richtung anzeigen, dann geht der Weg aus 
dem Speicher geladener Daten indirekt über die ALU in die Register. Das 
machen ältere ARMs auch so.

[(prx) A. K. (prx)]

Apropos: Auf solcher Detailebene gibt es so etwas "den Datenbus" 
üblicherweise nicht. Sondern einen Rattenschwanz verschiedener Busse mit 
irgendwelchen Aufgaben. 14 ist also nicht "der Datenbus" sondern der 
result bus.

[(prx) A. K. (prx)]

Heinz V. schrieb:
> Da es mit der ALU in direkter Verbindung steht, dürfte es das Carry Flag
> sein.

Steht eher für mehrere Statusinformationen, wie die verbreiteten 
Zero/Sign/Overflow/Carry Bits, die in Verbindung mit Microcode(6) einen 
bedingten Microcode-Sprung bestimmen. Ein persistentes Carry kommt hier 
im Bild nicht vor.

9 ist der Mikroprogrammzähler, darunter der von der eben erwähnten 
Flag-Logik gesteuerte Muxer, d.h. für die Folgeadresse im Microcode-

[Heinz V. (heinz_v)]

A. K. schrieb:
> Steht eher für mehrere Statusinformationen, wie die verbreiteten
> Zero/Sign/Overflow/Carry Bits,

Axo das Programmstatusword

[student (Gast)]

Resultbus ist sicher ein besseres Wort, dennoch muss dieser doch an die 
Register angebunden sein, oder?

[Heinz V. (heinz_v)]

student schrieb:
> Resultbus ist sicher ein besseres Wort, dennoch muss dieser doch an die
> Register angebunden sein, oder?

Das ist er doch, über 13 und über 15 kann das Ergebnissunmittelbar als 
Operand A in die ALU gesendet werden.

[(prx) A. K. (prx)]

Heinz V. schrieb:
> Axo das Programmstatusword

Nicht ganz. Ein gespeichertes auslesbares PSW gibts hier nicht.

Aus der ALU kommen die Statusbits. Aus dem Microcode(6) kommen ein paar 
Bits, die diese Statusbits auswerten und daraus das Steuersignal für den 
Micro-PC-Muxer erzeugen.

[Heinz V. (heinz_v)]

Interressant, der Vorteil wäre quasi ein geringer 
Geschwindigkeitsgewinn, oder?

[(prx) A. K. (prx)]

Heinz V. schrieb:
>> Resultbus ist sicher ein besseres Wort, dennoch muss dieser doch an die
>> Register angebunden sein, oder?
>
> Das ist er doch,

Yep, ...

> über 13 und über 15 kann das Ergebnissunmittelbar als
> Operand A in die ALU gesendet werden.

... aber der Weg aus der ALU geht über 14 und den Muxer 13 in die 
Register. Muxer 13 ist der Adressdekoder für die Register.

[(prx) A. K. (prx)]

Heinz V. schrieb:
> Interressant, der Vorteil wäre quasi ein geringer
> Geschwindigkeitsgewinn, oder?

Nö. Minimalismus. Bild wird sonst komplizierter. Ein PSW ist prinzipiell 
verzichtbar, als lässt man es bei einfachen Lehrbeispielen evtl. weg.

[(prx) A. K. (prx)]

A. K. schrieb:
> ... aber der Weg aus der ALU geht über 14 und den Muxer 13 in die
> Register. Muxer 13 ist der Adressdekoder für die Register.

... weshalb das trotz den gleichen Symbols eher ein Demuxer ist. Die 
Symbolik ist nicht sonderlich genau und man darf kreativ mitdenken.

[student (Gast)]

fungiert 15 sowohl als Ergebnisregister der ALU als auch als MDR? Und 
wird es dann über 19 (was ich jetzt mal als Multiplexer oder so annehme) 
in die Register abgelegt werden?

[(prx) A. K. (prx)]

student schrieb:
> fungiert 15 sowohl als Ergebnisregister der ALU als auch als MDR?

Ich tippe eher darauf, dass es hier kein implizites Ergebnisregister 
gibt. Der Weg vom Resultat geht also stets durch das Registerfile in die 
ALU.

[student (Gast)]

kennst du zufällig ein Mikroprozessor der genau so oder zumindest stark 
ähnlich dieser Architektur arbeitet?

[(prx) A. K. (prx)]

Nein.