Fetch und Execute Phase

[Klari (Gast)]

Angenommen ich habe einen Opcode:

sei;

Einschalten--> Fetch: Der PC zählt um 1 hoch. Dieser Adresswert wird am 
CPU internen Bus gelegt und über den Puffer in den Speicher befördert. 
Daraufhin bekomme ich meinen ersten Befehl (in dem Fall sei) ins 
Instruktionsregister(IR).
Dieser Befehlssatz besteht genau aus einem Wort. Also wird er von dem 
Steuerwerk als diesen erkannt, der PC wird um 1 erhöht und der Befehl 
wird ausgeführt (execute). Daraufhin beginnt die nächste Fetch Phase...

Was ist aber wenn ich einen Befehl habe:

add A, 56;

(A...Akku)
hier besteht der Befehl aus 2 weiteren Wörtern.
Also wird ein OP-Code generiert indem neben der Funktionalität steht, 
das die nächsten 2 Wörter noch zum Befehl gehören. Also kommt der Befehl 
in das IR und dort wird das nun erkannt.

Nun wird der PC um eins erhöht und holt das erste Wort, indem Fall "A" 
(Frage: Wo kommt das jetzt hin? In das Steuerwerk=? Muss ja da sonst 
nicht erkannt wird ob ein anderes Register addiert werden soll oder 
nicht oder?

Nun wird der PC wieder um eins erhöht und holt den Wert oder Adresse von 
der Zahl? (Ich bin mir da nicht sicher...)

Hier kommt das ZR Register ins Spiel. Am Ende steht dann die Adresse der 
zu Addierenden Zahl drinnen und diese wird dann auch auf den internen 
Adressbus gelegt. Dann kommt auch der Wert in den Datenbus zur ALU und 
der Wert von A zur ALU und die Addition wird ausgeführt und in A wieder 
ausgegeben.

Eins verstehe ich aber nicht: Wie genau ließt die CPU die 2 Worte ein? 
Sprich wann wird das ZR Register mit der Adresse des zweiten Wortes 
eingesetzt und wann wird der erste Summand erkannt?
Befinden sich die 2 Worte zu irgendeinem Zeitpunkt im Steuerwerk?
Wenn nicht, wie kann dann die Adresse von der zu addierenden Zahl 
automatisch ins ZR Register kommen? Das verstehe ich irgendwie nicht..

[Johann L. (gjlayde)]

Um welche CPU geht's denn überhaupt? x86?

Wie die Pipeline gefüllt und abgearbeitet wird, wo und wie es Injects 
gibt hängt von der Architektur ab und wie die Pipeline aurgebaut ist, 
z.B.

  fetch — decode — execute — writeback

Bei superskalaren CPUs sieht's nochmal komplizierter aus.

Auf jeden Fall darfst du nicht den Assembler-Code einer Instruktion mit 
ihrem Maschinencode verwechseln.

Wenn z.B. "SEI" codiert ist als 0xffff01ff und "add A, 56" als 
0x010aff0056 dann sind in beiden Fällen 4 Byte bzw. ein Word zu lesen.

[Klari (Gast)]

Es geht um den MC8, von Neumann.

Johann L. schrieb:
> Auf jeden Fall darfst du nicht den Assembler-Code einer Instruktion mit
> ihrem Maschinencode verwechseln.

Der Assemblercode wird doch 1:1 übersetzt oder?
(Ist das Instruktionsregister ein 16 Bit Register oder noch größer)?

Johann L. schrieb:
> Wenn z.B. "SEI" codiert ist als 0xffff01ff und "add A, 56" als
> 0x010aff0056 dann sind in beiden Fällen 4 Byte bzw. ein Word zu lesen.

Achsoooo, ich dachte ein OP_Code ist 8Bit Breit?????? Und danach kommen 
erst die Befehle. Das haut natürlich alles auf den Kopf.
Das bedeutet eine Zeile Assemblercode entsprechen immer 4 Byte?

[Johann L. (gjlayde)]

Das war nur ein Beispiel; du hattest ja noch nichma die Architektur 
genannt.

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Wenn dein
add A, 56;
in ein Wort passt ist alles hart codiert.
Die 56 ist ein sogenannter immediate Wert und steht im Befehl mit 
drinne.
Also die 56 us dem befehl und der Inhalt von A werden zur ALU geschalten 
die auf add eingestellt ist.
Das ERgebnis kommt dann wieder nach A.

Mit in ein Wort passt ist gemeint: in 16 oder 32bit und nicht was du 
meinst (getrennt durch Leerzeichen).
Der Befehl den du da deinem Compiler gibst wird ja noch in Maschinencode 
übersetzt.
mit add A, 56; kann der Prozessor sowas von ganix anfangen ;)

So wird der ARM Befehl:
LDR PC, [PC, #0x18]
In diesen Maschienencode übersetzt der dann binär als 1 Wort im ROM 
liegt:
0xE59FF018

[Klari (Gast)]

Martin Wende schrieb:
> Mit in ein Wort passt ist gemeint: in 16 oder 32bit und nicht was du
> meinst (getrennt durch Leerzeichen).

Aber woher weiß ich wie groß ein Wort ist? Ist das irgendwo definiert?
Dh 3 zeilen machen dann 3 Worte?

Wird dann immer eine gesamte zeile in das Instruktionsregister geladen? 
Dh sprich  Bit?
Laufen die Befehle die aus dem ROM ausgelesen werden nicht auf den CPU 
internen Bus in die IR? Der ist ja 8 bit breit, dh ein befehl würde 
zugriffe brauchen...

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

Klari schrieb:
> Es geht um den MC8, von Neumann.

Ein Prozessor namens MC8 ist mir nicht bekannt.

> Aber woher weiß ich wie groß ein Wort ist? Ist das irgendwo definiert?

Steht im Manual des bislang noch unbekannten Prozessors.

[Axel S. (a-za-z0-9)]

Klari schrieb:
> Es geht um den MC8, von Neumann.

Das scheint ein virtueller Prozessor zu sein, den die TU Wien in der 
Lehre einsetzt. Da wirst du wohl selber mal in die lokalen 
Veröffentlichungen schauen müssen.

> (Ist das Instruktionsregister ein 16 Bit Register oder noch größer)?

Das ist eine Architekturentscheidung (von vielen). Schau in die Doku.

> Achsoooo, ich dachte ein OP_Code ist 8Bit Breit?????? Und danach kommen
> erst die Befehle. Das haut natürlich alles auf den Kopf.
> Das bedeutet eine Zeile Assemblercode entsprechen immer 4 Byte?

Nein. Das ist eine Architekturentscheidung. Man hat früher mal mit 8-Bit 
Opcodes angefangen. Dann gab es mit neuen "breiteren" Prozessoren 
(welche mit neuem Befehlssatz, nicht aufgebohrte alte Designs) auch 
Opcodes mit 16 oder 32 Bit Breite. Und dann eine Modewelle VLIW (schlag 
das bei Wikipedia nach).

Es ist auch keineswegs so, daß jeder Operand (etwa das Register "A" in 
deinem Beispiel) als separates Byte/Wort signalisiert wird. Da die 
Anzahl der Register eher klein ist, reichen 3, 4 oder 5 Bits aus um ein 
Register zu adressieren. Prozessoren mit eher langen Opcodes (16 oder 32 
Bit) codieren dann Registeroperanden direkt im Opcode. Aber wie 
gesagt, das alles sind Architekturentscheidungen und nicht von einem 
Prozessor auf einen anderen übertragbar.


XL

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Axel Schwenke schrieb:
> Klari schrieb:
>> Es geht um den MC8, von Neumann.
>
> Das scheint ein virtueller Prozessor zu sein, den die TU Wien in der
> Lehre einsetzt. Da wirst du wohl selber mal in die lokalen
> Veröffentlichungen schauen müssen.

Lässt sich hier etwa grade mal wieder wer seine Hausaufgaben erklären?

[Reinhard Kern (Gast)]

Axel Schwenke schrieb:
> Das scheint ein virtueller Prozessor zu sein, den die TU Wien in der
> Lehre einsetzt.

Das mit der TU kann ja stimmen, aber so rein virtuell ist er nicht: wenn 
es sich nicht um eine zufällige Namensgleichheit handelt, war das ein in 
Musikgeräten (Synthesizer) verwendeter Microcomputer, der auf 8080 
beruht.

Gruss Reinhard

[Reinhard Kern (Gast)]

Axel Schwenke schrieb:
> Das scheint ein virtueller Prozessor zu sein, den die TU Wien in der
> Lehre einsetzt.

Das mit der TU kann ja stimmen, aber so rein virtuell ist er nicht: wenn 
es sich nicht um eine zufällige Namensgleichheit handelt, war das ein in 
Musikgeräten (Synthesizer) verwendeter Microcomputer, der auf 8080 
beruht.

Gruss Reinhard

Axel Schwenke schrieb:
> auch
> Opcodes mit 16 oder 32 Bit Breite.

Die Opcode-Breite ist keineswegs begrenzt auf 8/16/32/64, sondern kann 
jede beliebige Grösse haben. Insbesondere auch 10/11/12 bit. Bei 
Havard-Architekturen hat das auch mit der Datenbreite nichts zu tun. 
Richtig ist nur, dass es keine halben Opcodes gibt, es wird immer 1 oder 
mehrere davon gefetcht.

Gruss Reinhard

[Johann L. (gjlayde)]

Der da?

http://de.wikipedia.org/wiki/Motorola_88000er-Familie