Thema: Logisim CPU

[erik.vikinger]

Hallo,

Dachte an Shift-Befehle so wie wikinger beschrieben hatte...

Okay, ich denke das Svenska auch an diesen Shifter-Operanden von ARM dachte den die speziellen PPC-Befehle haben 5 Operanden und sowas gibt es wimre beim klassischen ARM32 nicht (diese 5 Operanden würden bei ARM32 zusammen 23 Bit belegen).

Wofür braucht man eigentlich die Sprungbefehle JA,JAE,JB,JBE. Kann man da nicht für JA auch ein JE Befehl nehmen und für JB ein JL?

JA (>) und JE (==) sind zwei unterschiedliche Dinge und deswegen wirst Du auch beide brauchen. JL und JB sind auch unterschiedlich da ersteres für signed und letzteres für unsigned ist. Bitte beschäftige Dich mal mit der Zahlendarstellung im Zweierkomplement für signed und unsigned.
Das Zitat mit den Shift-Befehlen passt zu Deiner Frage nicht.

Mhh wenn ich jetzt schon 2 Quellregister hab könnte ich eigentlich ja auch 2 Zielregister einbauen

Solange Du nur bei Registern bleibst sollten in Deine 32Bit-Befehle locker 4 Operanden rein passen aber es gibt nur wenige Befehle die so viele Operanden wirklich benötigen und in Deiner Pipeline (also in der internen dekodierten Befehlsdarstellung) musst Du trotzdem immer 4 Operanden vorsehen (auch bei Befehlen die das nicht nutzen). Damit wäre ein R1 * R2 := R3:R4 möglich (R3 ist der High-Part des Produkts und R4 der Low-Part).
Bei der Division wird es aber noch schwieriger, eine vollwertige Division ist eigentlich ein 5 Operanden-Befehl: R1:R2 / R3 = R4,R5 (R1 ist der High-Part des Dividend und R2 der zugehörige Low-Part, R3 der Divisor, R4 der Quotient und R5 der Rest). Bei Deinen 32Bit-Befehlen sollten auch 5 Register problemlos kodierbar sein aber das macht Deine interne Darstellung sehr umfangreich. Hier kommst Du eben in das Problem das Du dafür eine fette interne Befehlsdarstellung brauchst die aber nur von sehr wenigen Befehlen wirklich ausgereizt wird.

was passiert eigentlich wenn man bei den 2. Zielregister das selbe Register angibt wie beim ersten Zielregister?

Das musst Du als CPU-Designer festlegen. Deswegen wolltest Du doch diesen Job, oder?
Auf meiner CPU ist das verboten, der Decoder wird solche Befehle als Undefined-OpCode verwerfen und es kommt eine Exception. Aber es macht auch den Decoder komplexer wenn er für jeden Befehl individuell prüfen muss ob die aktuelle Kombination aus Operanden gültig ist, hier ist es wichtig ein gutes Mittelmaß zu treffen damit der Decoder mindestens den kritischen Unfug abfängt aber auch nicht zu komplex wird. Dieses Problem existiert auch bei den Speicher-Lesebefehlen wenn das Zielregister mit dem Adressregister übereinstimmt, theoretisch sollte das funktionieren aber wenn Du das Adressregister Inkrementierst/Dekrementierst darf es nicht noch zusätzlich mit den gelesenen Daten überschrieben werden.


Grüße
Erik

[Tufelix]

JA (>) und JE (==) sind zwei unterschiedliche Dinge und deswegen wirst Du auch beide brauchen. JL und JB sind auch unterschiedlich da ersteres für signed und letzteres für unsigned ist. Bitte beschäftige Dich mal mit der Zahlendarstellung im Zweierkomplement für signed und unsigned.
Das Zitat mit den Shift-Befehlen passt zu Deiner Frage nicht.

Ah, ich glaub jetzt hab ichs verstanden 

Das musst Du als CPU-Designer festlegen. Deswegen wolltest Du doch diesen Job, oder?
Auf meiner CPU ist das verboten, der Decoder wird solche Befehle als Undefined-OpCode verwerfen und es kommt eine Exception. Aber es macht auch den Decoder komplexer wenn er für jeden Befehl individuell prüfen muss ob die aktuelle Kombination aus Operanden gültig ist, hier ist es wichtig ein gutes Mittelmaß zu treffen damit der Decoder mindestens den kritischen Unfug abfängt aber auch nicht zu komplex wird. Dieses Problem existiert auch bei den Speicher-Lesebefehlen wenn das Zielregister mit dem Adressregister übereinstimmt, theoretisch sollte das funktionieren aber wenn Du das Adressregister Inkrementierst/Dekrementierst darf es nicht noch zusätzlich mit den gelesenen Daten überschrieben werden.

Mhh man kann auch doch nur bei ein paar bestimmten Befehlen prüfen ob die Operanden gültig sind(also bei Befehlen wo das wirklich nötig ist)

Nun ich hab jetzt mal mein Instuktions set verbessert:

Code: [Auswählen]

arithmetische Befehle:
Opcode:(11 aus 64)|Rd(5 bits) |Rs1(5bits) |Konstante(16 bit) oder Rs2(5 bit)
---------------------------------------------------------------------
1 |ADD |Rd,Rs |Addiert |Rd+Rs -> Rd
---------------------------------------------------------------------
2 |ANDI |Rd,Wert |Addiere Wert dazu |Rd+Wert -> Rd
---------------------------------------------------------------------
3 |Sub |Rd,Rs1,Rs2 |Subtrahiert |Rs1-Rs2 -> Rd
---------------------------------------------------------------------
4 |SUBI |Rd,Rs1,Wert |Subtrahiere wert ab |Rs1-wert -> Rd
----------------------------------------------------------------------
5 |SUBI |Rd,Rs1,Wert |Subtrahiere Rs1 ab |Wert-Rs1 -> Rd
-----------------------------------------------------------------------
6 |AND |Rd,Rs1,Rs2 |AND |Rs1•Rs2 -> Rd
-----------------------------------------------------------------------
7 |ANDI |Rd,Rs1,wert |AND mit Wert |Rs1•wert -> Rd
-----------------------------------------------------------------------
8 |OR |Rd,Rs1,Rs2 |OR |Rs1 v Rs2 -> Rd
------------------------------------------------------------------------
9 |ORI |Rd,Rs1,wert |OR mit wert |Rs1 v Wert -> Rd
-------------------------------------------------------------------------
10 |XOR |Rd,Rs1,Rs2 |XOR |Rs1 "Xor" Rs2 -> Rd
---------------------------------------------------------------------------
11 |XORI |Rd,Rs1,Wert |XOR mit wert |Rs1 "Xor" wert -> Rd
-----------------------------------------------------------------------------

Spring-Befehle:
Opcode:(9 aus 64) |Rd(5 bits)| Rs(5 Bits)| Adresse(16 bits)
-------------------------------------------------------------------
12 |JA |Rd,Rs,Adresse |Spr. wenn darüber |Rd<Rs
-------------------------------------------------------------------
13 |JAE |Rd,Rs,Adresse |Spr. wenn Gl. oder dar.|Rd<=Rs
-------------------------------------------------------------------
14 |JG |Rd,Rs,Adresse |Spr. wenn größer |Rd<Rs
-------------------------------------------------------------------
15 |JGE |Rd,Rs,Adresse |Spr. wenn Gl oder gr. |Rd<=Rs
-------------------------------------------------------------------
16 |JE |Rd,Rs,Adresse |Spr. wenn gleich |Rd==Rs
-------------------------------------------------------------------
17 |JNE |Rd,Rs,Adresse |Spr. wenn nicht gleich |Rd!=Rs
-------------------------------------------------------------------
18 |JSR |Adresse |Springe, ablage des CP |[FP-1]<-CP, Adresse->CP
--------------------------------------------------------------------
19 |RTS | |Rücksprung aus UP |[FP-1]->CP
--------------------------------------------------------------------
20 |RTI | |Rücksprung aus ISR |[FP-1 bis FP-32] -> Registerblock
--------------------------------------------------------------------

Shift-Befehle
Opcode:(4 von 64) |Rd(5 bits) | Rs1(5 bits)|"Kon-or-Rx-Bit"(1 bit)|10 bit unbenutzt|Konstante(4 bit) oder Rs2(5 bit)
--------------------------------------------------------------------
21 |SHR |Rd,Rs1 or wert |shift logi. nach rechts
--------------------------------------------------------------------
22 |SHL |Rd,Rs1 or wert |shift logi. nach links
--------------------------------------------------------------------
23 |SAR |Rd,Rs1 or wert |shift arith. nach rechts
--------------------------------------------------------------------
24 |ROR |Rd,Rs1 or wert |rotieren logisch nach rechts
--------------------------------------------------------------------

Register-Transfer-Befehle
Opcode:(2 von 64)|Rd(5 bits) |Rs(5bits) |Konstante(16 bits)
--------------------------------------------------------------------
25 |MOV |Rd,Rs |Kopiere Register |Rs->Rd
--------------------------------------------------------------------
26 |LDK |Rd,wert |Lade Konstante |wert->Rd
--------------------------------------------------------------------

Multipliezieren/Dividierern
Opcode:(2 aus 64)|Rd(5) oder Rs(5)|Rs1(5 bits)|Rs2(5Bits)|Rs3(5 bits)|Rd1(5 bits)|
---------------------------------------------------------------------
27 |MUL |Rd,Rd1,Rs1,Rs2 |MUL |Rs1*Rs2->Rd:Rd1
---------------------------------------------------------------------
28 |DIV |Rd,Rd1,Rs1,Rs2,Rs3|Div |Rs1:Rs2/Rs3->Rd,Rd1
------------------------------------------------------------------------

Store und LOAD
OPCODE(2 aus 64)|Rd(5 bits)|Rs1(5 bits)|Controll-Bits(4 bits)|4 bit unbenutzt|Offset(8 bit) oder Rs2(5 bits)
-----------------------------------------------------------------------
29 |Load |Rd,Rs1,wert,Rs2|Load²
-----------------------------------------------------------------------
30 |Store |Rd,Rs1,wert,Rs2|Store³
-----------------------------------------------------------------------

²Es gibt 9 adressierungsarten, diese werden über die Controllbits festgelegt.
------------------------------------------------------------------------
LOAD |Rd,Rs1 |Lade |[Rs1]->Rd
------------------------------------------------------------------------
LDPOI |Rd,Rs1 |Lade, Post-Increment |[Rs1]->Rd, Rs+1->Rs1
-------------------------------------------------------------------------
LDPOD |Rd,Rs1 |Lade, Post-Decrement |[Rs1]->Rd, Rs1-1->Rs1
-------------------------------------------------------------------------
LDPRI |Rd,Rs1 |Lade,Pre-Increment |[Rs1+1->Rs1]->Rd
-----------------------------------------------------------------------
LDPRD |Rd,Rs1 |Lade,Pre-Decrement |[Rs1-1->Rs1]->Rd
-----------------------------------------------------------------------
LDAR |Rd,Rs1,Rs2 |Lade,Add Register |[Rs1+Rs2]->Rd
-----------------------------------------------------------------------
LDSR |Rd,Rs1,Rs2 |Lade,Sub Register |[Rs1-Rs2]->Rd
-----------------------------------------------------------------------
LDAW |Rd,wert(8 bit) |Lade, Add Wert |[Rs1+wert]->Rd
-----------------------------------------------------------------------
LDSW |Rd,wert(8 bit) |Lade, sub wert |[Rs1-wert]->Rd
-----------------------------------------------------------------------

³Auch hier gibts 9 adressierungsarten:

-------------------------------------------------------------------------
ST |Rs,Rs1 |Speicher,aus Bussystem |[Rs1]<-Rs
-------------------------------------------------------------------------
STPOI |Rs,Rs1 |Speicher,Post-Increment|[Rs1]<-Rs, AP+1->AP
-------------------------------------------------------------------------
STPOD |Rs,Rs1 |Speicher,Post-Decrement|[Rs1]<-Rs, AP-1->AP
-------------------------------------------------------------------------
STPRI |Rs,Rs1 |Speicher,Pre-Increment |[Rs1+1->AP]<-Rs
-----------------------------------------------------------------------
STPRD |Rs,Rs1 |Speicher,Pre-Decrement |[Rs1-1->AP]<-Rs
-----------------------------------------------------------------------
STAR |Rs,Rs1,Rs2 |Speicher,Add Register |[Rs1+Rs2]<-Rs
-----------------------------------------------------------------------
STSR |Rs,Rs1,Rs2 |Speicher,Sub Register |[Rs1-Rs2]<-Rs
-----------------------------------------------------------------------
STAW |Rs,wert(8 bit) |Speicher, Add Wert |[Rs1+wert]<-Rs
-----------------------------------------------------------------------
STSW |Rs,wert(8 bit) |Speicher, sub wert |[Rs1-wert]<-Rs
-----------------------------------------------------------------------
jetzt kann man auch alle register als adressregister benutzen.

[Svenska]

LDK ist nur sinnvoll, wenn man deutsch versteht.
Sonst benutzt du Pärchen wie AND/ANDI, für Konsistenz könntest du z.B. LD/LDI benutzen. Ist aber nur eine Bezeichnung im Assembler. Ansonsten würden mich noch die Opcodes in Binär-/Hexschreibweise interessieren, weil ich einfaches Durchnummerieren immernoch als unschön empfinde.

Ansonsten sieht es für mich stimmig aus.

Gruß,
Svenska

[erik.vikinger]

Hallo Tufelix,


dem was Svenska geschrieben hat kann ich nur zustimmen, aber ich hab noch ein paar weitere kleinere Problemchen gefunden (ja ich weiß das ihr alle meinen Perfektionismus ganz arg liebt):

• Nr. 5 (der zweite SUBI) sollte wohl besser SUBRI heißen
• Nr. 20 (RTI) würde ich erstmal weglassen, vor allem da es ja keine offensichtliche Methode gibt Interrupts aufzurufen, für die ersten Versuche spielen Interrupts/Exceptions usw. noch keine Rolle
• Nr. 21..24 (die Shift-Befehle) da müsste die Mnemonik-Beschreibung anstatt "Rd,Rs1 or wert" eher "Rd,Rs1,Rs2 or wert" heißen (Rd und Rs1 sind immer vorhanden und Rs2 nur wenn keine Konstante benutzt wird)
• Nr. 27,28 (MUL/DIV) diese beiden Befehle benötigst Du in jedem Fall jeweils für signed und unsigned, für schnelle Adressberechnung wäre auch eine simple Form der Multiplikation (nur Rs1 * Rs2 -> Rd, keine Unterscheidung zwischen signed und unsigned) nützlich
• Nr. 29,30 (Load/Store) hier müsstest Du Bitte mal die Kodierung der einzelnen Adressierungsarten näher beschreiben (da reichen die hinteren 16 Bit des Befehls) und die Konstante könnte ruhig auch 12 Bit groß sein (ich denke das passt rein)

Mhh man kann auch doch nur bei ein paar bestimmten Befehlen prüfen ob die Operanden gültig sind(also bei Befehlen wo das wirklich nötig ist)

Ja, konzentriere Dich ruhig erst mal darauf das der Decoder die echt kritischen Dinge abfängt und den Rest kannst Du erst mal dem Assembler überlassen (also das dieser bestimmte Operanden-Kombinationen bei bestimmten Befehlen einfach nicht umsetzt, grundsätzlich sollte der Assembler keine Befehle umsetzen die die CPU bekanntermaßen nicht ausführen möchte oder die sonstwie problematisch sind). Mach Dir doch einfach dazu noch ein paar Gedanken und schreibe bei den Befehlen wo es Einschränkungen (von der CPU) geben soll diese mit dazu.

jetzt kann man auch alle register als adressregister benutzen.

Sehr gut, Du musst ja nicht gleich alles in Deiner CPU unterstützen was der OpCode theoretisch her gibt.


Man sieht auf jeden Fall das es vorwärts geht, weiter so!
Und lass Dich nicht von so Miesepetern wie Kevin verunsichern, der Weg zu einer echten vollwertigen CPU ist nunmal nicht ganz so leicht wie bei einem OS das nur gut ausgetrampelten Pfaden folgt. (ich glaub jetzt mag er mich endgültig nicht mehr)


Grüße
Erik

[kevin]

Und lass Dich nicht von so Miesepetern wie Kevin verunsichern

[erik.vikinger]

Entschuldige Bitte, aber Du weißt was ich meine.

[kevin]

Nein. Ich wüsste nicht, dass ich an Tufelix' Ideen rumkritisiert hätte, das haben andere getan.

[Tufelix]

Nr. 27,28 (MUL/DIV) diese beiden Befehle benötigst Du in jedem Fall jeweils für signed und unsigned, für schnelle Adressberechnung wäre auch eine simple Form der Multiplikation (nur Rs1 * Rs2 -> Rd, keine Unterscheidung zwischen signed und unsigned) nützlich

Nun was ist bei einer Unsigned-multiplikation anders wie bei ner signed?

Nr. 29,30 (Load/Store) hier müsstest Du Bitte mal die Kodierung der einzelnen Adressierungsarten näher beschreiben (da reichen die hinteren 16 Bit des Befehls) und die Konstante könnte ruhig auch 12 Bit groß sein (ich denke das passt rein)

Naja ,je nachdem wie man die controllbits setzt wird ein andere adressierungsart ausgewählt(wird Pre/post -inkrementieren/decrementieren als adressierungsart ausgewählt wird zusätzlich geprüft ob die Operanten stimmen.). Dann wird je nach adressierungsart die ersten 5 bits als adresse für ein register bzw die ersten 12 bits als offset benutzt. Auserdem wird bei Store-Befehle, die Rd adresse für Rs benutzt(hab das vergessen im Instruktionsset anzugeben  ).

[Tufelix]

Zitat

    Nr. 27,28 (MUL/DIV) diese beiden Befehle benötigst Du in jedem Fall jeweils für signed und unsigned, für schnelle Adressberechnung wäre auch eine simple Form der Multiplikation (nur Rs1 * Rs2 -> Rd, keine Unterscheidung zwischen signed und unsigned) nützlich

Nun was ist bei einer Unsigned-multiplikation anders wie bei ner signed?

Aja ich glaub ich blick langsam durch... diese Multiplizier/Dividiere-Einheit in logisim kann wohl nur unsigned... daher werd ich glaub zunächst Div/Mul-Signed Befehle drausen lassen.

[Tufelix]

Nun ich hab mal angefangen einen Prototyp zu bauen...Was mir noch Probleme macht ist die CU einheit (bzw. Befehls-decoder), hat da jemand nen tipp wie man die am besten baut ?

[chris12]

CU, ka, was soll das heißen?

Befehlsdecoder hast du zwei möglichkeiten:
a) alle befehle mittels decodern aufdröseln und hart verdraten, oder
b) mittels microprogrammsteuerwerk die einzelnen leitungen einzeln schalten und alle befehle einprogrammieren

[Svenska]

Hallo,

Was mir noch Probleme macht ist die CU einheit (bzw. Befehls-decoder), hat da jemand nen tipp wie man die am besten baut ?

Du könntest mit einem Demultiplexer dekodieren. N Eingänge, 2^N Ausgänge (N=Anzahl der Opcode-Bits). Jeder Ausgang ist eine ENABLE-Leitung und schaltet einen ganz bestimmten Befehl aktiv. Alle Bits nach dem Opcode gehen in alle Befehle.

Darum hatte ich dir übrigens empfohlen, die Befehle an Bitgrenzen in Gruppen zu teilen, so dass du erst die vorderen Bits in die Gruppen dekodierst (und dann wegwirfst), dann innerhalb jeder Gruppe die vorderen Bits in die Befehle dekodierst (und dann wegwirfst) und zum Schluss die restlichen Bits in die Befehlsvariante plus Operanden aufspaltest. Dann hast du zwar mehrere Multiplexer hintereinander, aber die sind alle kleiner (z.B. 2^3 Gruppen und 2^5 Befehle/Gruppe statt 2^8 Befehle).

Gruß,
Svenska

[Tufelix]

Nun, hab mir überlegt das ich sowas ähnliches wie Svenska beschrieben hat bauen werde...die Opcode-Bits dienen als adresse für zwei ROMs. In der einen steht wohin die 26 restlichen bits gehen soll, und in der anderer wie die Steuerleitungen geschaltet werden. Die max. Wortbreite(32 bit) einer einzelen Rom hatte nicht gereicht um alles unterzukriegen daher hab ich mal 2 eingeplant. Auserdem hab ich den Befehlsatz etwas vereinfacht: Hauptproblem waren de LOAD und STORE Befehle sowie die Shift-Befehle, die verschiedene Adressierungsarten hab ich jetzt direkt als Befehle eingebaut, bei den Shift-Befehle hab ich den Wahlbit für Konstante oder Register rausgenommen und stattessen jeweils die 4 shift-Befehle mit einer Konstante als Distanz-Bit² und die 4-shift-befehle mit einem Register als Distanz-Bit².

² Distanz-Bit stet für wie weit die eingangs-bit zu schieben sind.

Auserdem wollte ich für das interrupt-signal ein Flip-Flop in der instruktions-decoder einbauen, bei einem interrupt sollte der stand des CP-registers auf den Stack gepusht werden, und dann zu dem Programm gesprungen werden was die restlichen Register pusht(die adresse des Programms ist von dem instruktions-decoder vorgegeben) Das ende des Programms wird mit einem Noop-befehl gekennzeichnet, der instruktions-decoder wird dann die Programm-adresse vom interrupt aus dem Ram in den CP geladen(also aus dem Interrupt-vektor)...

[Tufelix]

kennt eigentlich einer ne website wo genau beschrieben ist wie so ein instruktions-decoder aufgebaut ist ?

[MNemo]

Hier gibt es einen Folien Satz zu einer Vorlesung die den Aufbau schritt für schritt erklärt: MIPS-PDF (Webseite)

PC steht für Program-Counter und entspricht dem i386 Instruction-Pointer (E)IP

[Tufelix]

Nun bei mir ist es ja so das man bei Mul 4 und bei Div 5 register angeben muss, gibt es sowas auch bei anderen architekturen ?

[Tufelix]

Nun, ich hab jetzt ein wenig meine architektur umgebaut... ansich bleibt alles beim alten nur das es jetzt eine Von-Neuman architektur ist... Fals die CPU dann etwas in bzw. aus dem Bus laden möchte wird der CP und das Laden eines Neuem Befehls für einen taktzyklus angehalten. Auserdem hab ich die Architektur auf 32 bit erweitert, wenn man z.b einen Wert mit einem register addieren möchte, wird der 16 bit Wert mit einem Vorzeichenerweiterer auf 32 bit erweitert.Zudem, ist es dann sinvoll 2 LDK befehle einzubauen ? Also das der eine Befehl seinen 16 bit wert in die untere Hälfte des Registers ladet und der andere Befehl seinen wert in obrige Hälfte ladet.

[Tufelix]

soll ich die Jump-adresse eines Jump-Befehles auch Vorzeichenerweitern ?

[Tufelix]

Nun ich hab jetzt 3 ldk befehle eingebaut, einmal "ldk16": ladet ein 16 bit unsigned-wert in ein register. Dann "ldsk16" ladet ein 16 bit signed wert in ein register und dann noch "ldk32" der ladet ein 32 bit wert in ein Register, dabei steht der 32 bit wert in der nächsten adresse des PC. Ist das so ok oder soll ich bei den Befehlen was ändern?

[Svenska]

Das musst du wissen, darum entwickelst du ja die CPU.
Mach dich nicht zu sehr verrückt, du wirst beim Programieren schon feststellen, was fehlt oder unhandlich gelöst ist - und beim Aufbau, was zu komplex ist. Auf Anhieb schaffts eh keiner richtig.