Thema: Logisim CPU

[Svenska]

Ich sehe da nicht so recht durch und lese da ungefähr folgendes raus:

- Ein Befehl aus dem ROM geht durch ein Befehls-Register zum Instruction Decoder und verschwindet.
- Program-Pointer und Status-Register bilden zusammen den Program-Counter, also eine ROM-Adresse, die vom Ergebnis des letzten Befehls abhängt.
- Die ALU kommuniziert mit dem Program-Pointer, der aber Adresse enthält - keine (ALU-)Befehle.
- Die eigentliche CPU kann den RAM nicht lesen.
- Der RAM kommuniziert mit externer Hardware. Daten werden also immer von der Hardware in den RAM kopiert und umgekehrt. Das ist nicht MMIO, sondern DMA.
- Der Datenbus enthält nur I/O-Daten, ein eigener Adressbus fehlt.
- Die allgemeinen Register sind mit nichts verbunden.

Warum ein JUMP für seine Erlaubnis die ALU fragen soll, ist nachvollziehbar (wenn auch unpraktisch). Wie die ALU aber ihre Entscheidung treffen soll, ist unklar.

Gruß,
Svenska

[Tufelix]

- Ein Befehl aus dem ROM geht durch ein Befehls-Register zum Instruction Decoder und verschwindet.

Nun die Befehle werden Decodiert und an die jeweiligen Module weitergeleitet, also An Ram,Registerblock,Alu...

Warum ein JUMP für seine Erlaubnis die ALU fragen soll, ist nachvollziehbar (wenn auch unpraktisch). Wie die ALU aber ihre Entscheidung treffen soll, ist unklar.

Die ALU hätte eigentlich bei einem Sprung die 2 werte subtrahiert und dann über einen Komparator geschaut ob das ergebnis größer, kleiner oder gleich wie 0 ist.Am schluss währe entweder ein true(1) oder ein false(0) an das Statusregister geschickt worden.Naja das ganze ist eigentlich überflüssig...daher werd ich das "vergleichen" direkt in dem Statusregister einbauen(heißt jetzt Jump)

Program-Pointer und Status-Register bilden zusammen den Program-Counter, also eine ROM-Adresse, die vom Ergebnis des letzten Befehls abhängt.

Naja der Programm-Counter ist ein Zähler und bei einem Befehl wo was in das ProgrammPointer-Register geschrieben wird(bzw. wenn das Status-Register springt), werden die jeweiligen Daten in den Zähler geschrieben.

Die eigentliche CPU kann den RAM nicht lesen.

Joar da hab ich nen Pfeil vergessen .

- Der Datenbus enthält nur I/O-Daten, ein eigener Adressbus fehlt.

ein Adressbus wofür?

- Die allgemeinen Register sind mit nichts verbunden.

Doch mit der ALU und mit dem RAM da hab ich aber den Pfeil vergessen.

So jetzt nochmal mein verbesserter Entwurf:


Nochmal zur "Jump"(status-register) funktion, dort werden 2 werte miteinander verglichen und falls die Bedingung für den Sprung stimmt wird die Adresse in den Programm-Counter geschrieben.

[Svenska]

Hallo,

- Ein Befehl aus dem ROM geht durch ein Befehls-Register zum Instruction Decoder und verschwindet.

Nun die Befehle werden Decodiert und an die jeweiligen Module weitergeleitet, also An Ram,Registerblock,Alu...

Das fehlt in deinem Bild immernoch. Da ist hinter dem Decoder Schluss.

Die ALU hätte eigentlich bei einem Sprung die 2 werte subtrahiert und dann über einen Komparator geschaut ob das ergebnis größer, kleiner oder gleich wie 0 ist.

Alle drei Fälle sind sinnvoll (Funktionen: Sprung nach vorne, Schleifen: Sprung nach hinten, Endlosschleife: Sprung zu sich selbst), insofern bringt der Vergleich nichts.

Naja der Programm-Counter ist ein Zähler und bei einem Befehl wo was in das ProgrammPointer-Register geschrieben wird(bzw. wenn das Status-Register springt), werden die jeweiligen Daten in den Zähler geschrieben.

Hat das nen Sinn oder möchtest du nur wissen, wieviele Befehle die CPU jetzt ausgeführt hat?

- Der Datenbus enthält nur I/O-Daten, ein eigener Adressbus fehlt.

ein Adressbus wofür?

Du hast da vier Ports eingezeichnet... wenn ich jetzt ein "OUT" machen will - welche Hardware soll sich angesprochen fühlen? Alle gleichzeitig?

Schau dir mal den Pinout von (antiken, weil weniger komplex) realen CPUs an. Ein Großteil dessen kann dir in einer Simulation natürlich ziemlich egal sein, aber du siehst dabei ganz gut, welche Verbindungen es von "drinnen" nach "draußen" und umgekehrt gibt. Die unterscheiden sich zwischen Mikroprozessoren (µP) und Mikrocontrollern (µC), sind aber innerhalb einer Klasse ziemlich gleich.

µPs und µCs:
- Taktversorung
- Reset (sinnvoll für definierten Start)

µCs:
- Ports für Hardwarezugriffe

µPs:
- Adress-/Datenbus für RAM und MMIO(*)
- (Harvard-Architektur) Adress-/Datenbus für ROM und Flash(*)
- (optional) I/O-Bus für Hardwarezugriffe(*)
- IRQ- und NMI-Eingang

(*) Die Bussysteme können sich die Pins teilen, d.h. es gibt dann zusätzliche Pins, die angeben, welcher Bus jetzt gemeint ist und ob die Pins als Inputs, Outputs oder High-Impedance geschaltet sind (letzteres trennt die Pins vom Bus ab und ist wichtig, wenn sich zwei andere Geräte über den Bus unterhalten möchten)

Das Konzept von Mikroprozessoren ist flexibler, erfordert aber eine komplexere Bus-Logik. Bei Mikrocontrollern nutzt man meist nur eine Hardware an einem Port oder muss die Bus-Arbitrierung mit mehreren Ports in Software realisieren, wenn man mehr Geräte anschließen möchte. Das Interrupt-Management solltest du dir auch noch überlegen; µPs haben fixe Pins (und oft einen Interruptcontroller), bei µCs sind die Ports selbst in Grenzen in der Lage, Interrupts auszulösen.

Gruß,
Svenska

[erik.vikinger]

Hallo Tufelix,


schau doch mal auf http://en.wikibooks.org/wiki/Microprocessor_Design/Pipelined_Processors das vierte Bild zeigt eine relativ simple RISC-Pipeline in der recht gut zu erkennen ist wie u.a. das Registerfile eingebunden ist.
(und auch ins eigentliche Buch http://en.wikibooks.org/wiki/Microprocessor_Design)

Was Du in deinem Bild mit "RAM" beschreibst sollte eine Art Bus-Master sein der einen externen Bus ansteuert an welchem dann RAM aber auch MMIO-Ports hängen können, so ein Bus benötigt nicht nur die eigentlichen Datenleitungen sondern auch Adressleitungen (die Anzahl dieser Leitungen bestimmt die Größe des Adressraums der CPU) und Steuerleitungen (um z.B. zwischen Lesen und Schreiben unterscheiden zu können). Wenn das was bei Dir mit "ROM" bezeichnet wird ein vergleichbarer Busmaster ist dann kannst Du einfach zwischen Harvard (jeder dieser Busmaster verfügt über ein eigenes System) oder von-Neuman (beide Busmaster greifen auf den selben Bus zu, was natürlich eine Arbitrierung erfordert) umbauen.


Grüße
Erik

[Tufelix]

mmh pipelines ist was ganz neues für mich...bisher haben meine cpu's die Befehle mit 1 taktzyklus abgearbeitet. War immer der Meinung das es in Logisim nix bringt.

[erik.vikinger]

Hallo Tufelix,


die Pipeline entsteht durch die Zwischenregister (die grünen vertikalen Blöcke), einige davon (aber nicht alle!) kannst Du problemlos weglassen und schon hat diese Pipeline weniger Stufen. Solange Du nur innerhalb eines Simulators bleibst der keine Durchlaufzeit durch die Logik hat ist das völlig in Ordnung.

In dem Wikibook gibt es doch auch Single-Clock-CPUs, schau dort mal vorbei.


Grüße
Erik

[Tufelix]

Nun ich hab jetzt mein konzept wieder einmal verbessert.


Legende:
Weiße Bauteile= I/O Ports.
Hellblau = Ram-Speicher( hab mal 2 Ram-Speicher eingebaut, den eigentliche Ram und der Speicher der Portx und DIRx werte der I/O-Ports.).
Blau = Registerblöcke.
Orange = Rechen- und Jump-einheiten.
Grün = Alles Was mit den Befehlen zu tun hat.

Schwarzer Pfeil = Daten.
Roter Pfeil = Decodierte Befehle.
Blauer Pfeil = Adressen.

Erklärung:

Programm-Counter:
Der zeigt auf die nächste Adresse in der Rom, kann aber auch mit werten gefüttert werden( Das passiert z.b. bei einem Sprung).

Die ROM:
Eine Einfache Rom die , die Befehle für den CPU enthält, die Adresse für die Rom kommt vom Programm-Counter.

Befehls-Register
Enthält den Befehl der gerade ausgeführt wird.

Instruktion Decoder
Decodiert den Befehl und schickt ihn an den
einzelne Komponenten.
In meine Decoder gab es bisher immer für jede Instruktion (also die Argumentbits wie Mov,ALU,JMP...) eine sogenannte Programmierbare Instruktion-Unit. Über spezielle eingänge konnte man bestimmen wann sie sich aktivieren sollte, was sie an die Ausgänge des Decoders schicken Sollte außerdem konnte sie man so programmieren das sie bei einem bestimmten Registern ein ausgang-bit aktiviert(z.b. wenn im Programm-Pointer was reingeschrieben wird hätte sie dann den Programm-Counter zum schreiben freigegeben). Gibt es bessere Möglichkeiten die so übersichtlich sind aber mehr freiheit bietet?
 
ALU
verrechnet 2 Register und Speichert dann das Ergebnis im Drain-Register.

JUMP
Vergleicht 2 Register und wenn die Bedingungen erfüllt sind schreibt er die Adresse die im Befehl angegeben ist in den Programm-Counter.

I/O( das hellblaue)
Enthält alle Dirx und PORTx werte der I/O Ports.
Wird genauso angesprochen wie der Ram.

So noch ihrgentwelche Fragen bzw Kritik ?

MfG Tufelix

[erik.vikinger]

Hallo Tufelix,

Nun ich hab jetzt mein konzept wieder einmal verbessert.

Ja, also die Richtung stimmt schon mal, nur weiter so.

Das "JUMP" zwei Register vergleichen kann ist recht gut, auf diese Weise kannst Du Dinge wie "if (a > b) then ..." ziemlich effizient umsetzen und kannst Dir die Flags komplett sparen. Wimre waren in der offiziellen Spec der ALPHA-CPU sogar einige Beispiele drin wie man sowas geschickt einsetzen kann, das ist zwar eher für Compiler-Programmierer interessant aber dürfte einen angehenden CPU-Entwickler sicher auch nicht schaden.

Wozu der Programm-Counter zweimal vorhanden ist (einmal einzeln oben rechts und einmal im Registerfile unten) verstehe ich nicht. Du kannst den aktuellen Programm-Counter durchaus als "normales" Register anbieten aber er sollte trotzdem nur an einem Ort gespeichert sein. Wenn der Programm-Counter als normales Register ansprechbar ist musst Du erstmal definieren was für einen Wert ein Befehl daraus lesen kann, z.B. seine eigene Adresse (das ist super toll für positionsunabhängigen Code und ein paar andere Nettigkeiten). Auch musst Du definieren was passieren soll wenn auf dieses Register geschrieben wird, z.B. das die Pipe-Line geleert werden soll und an der neuen Adresse im ROM weiter gearbeitet wird womit Du nahezu jeden Rechenbefehl als JUMP benutzen kannst und z.B. ein simpler "MOV ProgCount,LinkReg" als RET-Befehl funktioniert (spart Dir wertvolle OpCode-Bits ein da es so keinen eigenständigen RET-Befehl gibt). Außerdem ist dann ein unbedingter JUMP nur ein "LI ProgCount,&Label" (also ein normaler Load-Imediate den Du eh brauchst um Konstanten in ein beliebiges Register zu laden).

Das Du I/O als RAM bauen möchtest verstehe ich nicht, bei mancher Hardware ist so ein I/O-Register gar kein echtes Speicherelement sondern der Schreibzugriff startet einfach nur eine Aktion in der Hardware welche durch den übermittelten Wert selektiert wird (also eine Art Commando-Port, Lesezugriffe auf diesen Port liefern oft nichts oder einen reinen Status-Wert). Ich würde Dir doch noch mal empfehlen an die Stelle von RAM und I/O einen richtigen Bus-Master zu setzen der dann mit seinem Bus eben RAM aber auch beliebige Memory-Mapped-Hardware ansprechen kann.


Grüße
Erik

[Tufelix]

Nun wie funktioniert eigentlich so ein Busmaster ?

[Svenska]

Hallo,

stellt sich die Gegenfrage: Was ist ein Bus?

Einfache, parallele Bussysteme bestehen aus drei Komponenten:

• Adressleitungen
  Die Adressleitungen geben an, von wo die Daten gelesen werden oder wohin sie geschrieben werden. Das müssen nicht unbedingt RAM-Adressen sein, denn eine Hardware kann die Adressleitungen auch benutzen, um ein bestimmtes Register auszuwählen.
• Datenleitungen
  Da laufen die Daten drüber.
• R/W-Leitung
  Diese Leitung gibt an, ob die Daten von der Adresse gelesen oder geschrieben werden sollen und das angesprochene Gerät schaltet die Pins entsprechend als Input oder Output.
  Außerdem kann eine Hardware unter einer Adresse zwei verschiedene Register anbieten (die dann nur gelesen bzw. geschrieben werden können).

Hast du diese Bestandteile, kann die CPU auf den angeschlossenen Adressraum (RAM, MMIO) zugreifen. Allerdings geht dann jeder Buszugriff von der CPU aus (die CPU ist der Busmaster). Es gibt übrigens drei Zustände, die jede Leitung haben kann: "High" (logisch 1), "Low" (logisch 0) und "High-Impedance"/"Tri-State" (nicht angeschlossen). Wenn ein Gerät ein High schreibt und ein zweites Gerät ein Low, ist das Ergebnis Müll, im schlimmsten Fall ein Kurzschluss (es gibt allerdings auch Bussysteme, die anders funktionieren - z.B. I²C). Geräte am Bus haben also die Adressleitungen und R/W als Input und die Datenleitungen als Tri-State, bis sie angesprochen werden - dann schalten sie die Datenleitungen entsprechend um.

Sollen sich zwei Geräte direkt miteinander unterhalten können (z.B. ein DMA-Controller und der RAM), musst du eine Busarbitrierung haben. Das kannst du mit zwei Leitungen machen: BUSREQ/BUSACK. Wann immer ein Gerät, welches nicht die CPU ist, auf den Bus schreiben möchte, muss es die Leitung BUSREQ (Bus Request) aktivieren und warten. Die CPU aktiviert dann die Leitung BUSACK (Bus Acknowledge) und trennt ihre eigenen Adress- und Datenleitungen vom Bus ab (Tri-State), bis BUSREQ wieder Low ist. Solange ein Gerät also BUSREQ aktiviert hält und BUSACK von der CPU auf High gehalten wird, darf es auf dem Bus tun und lassen, was es will. Die CPU ist also nach wie vor der Chef auf dem Bus, aber andere Geräte dürfen ihn auch benutzen, also temporär den Status des "Busmasters" übernehmen.

In dieser Darstellung ist es hilfreich, die CPU als Ganzes mit den Verbindungen zu ihrer Außenwelt zu sehen. Wie die CPU intern aufgebaut ist, ist schließlich der Umgebung egal - eine CPU liest und schreibt Adressen, mehr nicht (d.h.: liest/schreibt RAM, liest ROM, liest/schreibt MMIO-Geräte).

Gruß,
Svenska

[erik.vikinger]

Hallo,

Nun wie funktioniert eigentlich so ein Busmaster?

Das ist im wesentlichen eine Bridge die zwischen der internen Art wie die CPU auf Speicher zugreift in das Protokoll übersetzt welches auf dem externen Bus benutzt wird.
Schau Dir doch mal an wie die Klassiker wie ISA o.ä. funktionieren.
Zu den CPUs aus der Altersgruppe 386 und 486 gibt es im iNetz bestimmt eine ansprechende Beschreibung wie ein ordentlicher 32Bit-Bus funktioniert.
Und wenn Du dann das Niveau "fortgeschritten" erreicht hast ist PCI oder besser PCI-Express auch eine interessante Lektüre (mal davon abgesehen das diese Spezifikationen nicht frei erhältlich sind, aber die iNetz-Suchmaschine Deines persönlich geringsten Misstrauens kann Dir bestimmt weiterhelfen, ansonsten ist Hypertransport guter Lesestoff, aber Vorsicht: alle diese Specs haben etliche hundert Seiten).

edit:
Für den Anfang ist aber z.B. der 8Bit-AVR eine gute Vorlage, wimre gab es auch dort Versionen die externen SRAM (und auch passende MMIO-Hardware) anbinden können. Üblicherweise liefert Atmel sehr gute (und frei verfügbare) Datenblätter in denen bestimmt sehr anschaulich beschrieben ist wie dieser externe Bus arbeitet also wie ein Zugriff auf externen Speicher abläuft und wie das vom CPU-Kern benutzt wird.

... musst du eine Busarbitrierung haben. Das kannst du mit zwei Leitungen machen: BUSREQ/BUSACK.

Fast richtig, jedes busmasterfähige Gerät benötigt natürlich ein eigenes BUSREQ/BUSACK-Pärchen. SCNR
Theoretisch kann man sogar diese Arbitrierungslogik als eigenständige Komponente bauen und die CPU benötigt dann ebenfalls BUSREQ/BUSACK um den Bus bekommen zu können (aber üblicherweise wird die Arbitrierungslogik einfach in die CPU integriert und deren BUSREQ/BUSACK-Leitungen gehen nur im Chip vom CPU-Kern zum Arbiter). Bei besseren Systemen berücksichtigt der Arbiter auch Prioritäten damit z.B. die CPU nicht so lange warten muss bis sie mal wieder ran darf aber fürs erste geht es auch ohne solche Extras.


Grüße
Erik

[OS_3000]

Ich selber beschäftige mich schon seit einiger Zeit mit dem "virtuellen Prozessorbau".
Allerdings nicht in einer Logiksimulation sondern in Form von zellulären Automaten.

Derzeit baue ich einen sehr einfachen Neumann 32Bit RISC Prozessor.
Grob inspiriert wurde ich ursprünglich von den Pic-Mikrocontrollern von Microchip. (So änlich wie die Avrs. Ich persönlich verwende ausschießlich solche, was aber hauptsächlich Geschmackssache ist.)

Das Design habe ich als Pdf angehängt. Vielleicht enthält es wiederrum für dich die eine oder andere Inspiration. 
Spezielle Befehle wie Goto\If\In\Out gibt es darin nicht. Die Peripherie wird auf die selbe Weise angesprochen wie der Speicher. ("Memory-Mapped-Hardware" wie es erik.vikinger genannt hat)

Der Programmcounter ist (fast) ein ganz normales Register. Beim Sprung wird einfach der Registerwert neu gesetzt, genauso wie beim Setzten eines X-beliebigen anderen Registers.
Stackpointer und co sind wegrationalisiert. Entweder wird der Stack softwaremäßig emuliert oder der Rücksprung wird einfach durch "goto"-Konstrukte ersetzt. Das sollte dann der Compiler erledigen können. Das es später einmal einen hardwaremäßigen Stack gibt, schließe ich jetzt auch nicht hundertprozentig aus.

Der Bus sieht bei mir so aus:
Eine Anfrage besteht aus Befehl, Adresse und Daten\Feedback. (Daten beim Schreiben\Feedback beim Lesen)
Nun werden die Anfragen im Scheduler zwischengespeichert(Queue) und weitergegeben sobald das "Gerät", das in dem Adressbereich liegt, bereit ist.
Das "Gerät" speichert entweder die Daten an der Adresse oder es liest an der Adresse und schickt die gelesenen Daten wieder zurück mit dem angehängten Feedback. Was es tut, hängt vom Befehl ab.
Die Komponente die die Anfrage gestellt hat erkennt an dem Binärcode im Feedback, dass jetzt die Daten kommen, die es angefordert hat.

Da es in Logiksim aber scheinbar keine Durchlaufzeit gibt, kann man das wahrscheinlich deutlich einfacher gestallten.
Eine umfangreiche Komponente die die ganzen Anfragen "managt" kann man sich dann auch sparen.
Das alles passiert in meinem Fall seriell. In der Realität und auch Logiksim ist es parallel eher geschickter.

[Tufelix]

nun ich hab jetzt ein Paralleles Bussystem mit passive Komponenten entworfen

Legende :
Schwarzer Pfeil = Daten.
Blauer Pfeil = Adresse.
Roter Pfeil = Befehle.
grüner Pfeil = Aktivierungsadresse

Verteilung der Adresse:
0-16 Register.
16-2064 Stack und Framepointer.
2064-2096 I/O ports,
Der Rest ist ist Ram.


Nun um etwas in ein Register der CPU bzw. etwas herraus zu laden gibt es 2 Spezial Befehle.
Um etwas von einer Komponente zu einer anderen Komponenten zu laden setzt man einfach den aktivierungs-Adresse vom DME-Modul auf die Quelladresse bzw auf eine Zieladresse und dann ladet man die werte( für das Werte laden gibts 2 Befehle, der eine nimmt den aktivierungsadresse als ziel und der Andere Als quelle).

MfG tufelix

[Svenska]

Hallo,

das sieht auf jeden Fall so aus, als ob es funktionieren könnte. Ein paar Anmerkungen:
- Wofür steht DME?
- Warum hast du einen eigenen Instruktionsbus? Instruktionen sind doch auch nur Daten.
- Framepointer und Stackpointer sind genau zwei Pointer, die brauchen also auch zwei Register, um gespeichert zu werden. Außerdem kann man die auch in die CPU einbauen und muss sie dann nicht an den Bus anschließen.
- Register sind Teil der CPU, brauchen also keine (Bus-)Adressen besitzen. Innerhalb der CPU natürlich schon, aber da hast du natürlich andere Adressen.

Die Systemstruktur kannst du auch deutlich einfacher gestalten, ich häng unten mal ein schnell gekliertes Bild ran. Erklärung: A=Adressleitungen, D=Datenleitungen, Clk=Taktleitung, R/W=Read/Write (0=Read, 1=Write) und I/O ist mit MMIO angebundene Hardware. Die Busbreiten (24-Bit-Adressbus, 8-Bit-Datenbus) sind nur ein (unpraktisches) Beispiel.

Ein 24-Bit Adressbus erlaubt 16M verschiedene Adressen, bei 8-Bit-Daten ist das dann ein Adressraum von 16 MB. Wie du den aufteilst, ist deine Sache, eine Möglichkeit ist:
- 00xxxxxx xxxxxxxx xxxxxxxx (unteres Viertel, 0 bis 4M): ROM (max. 4 MB)
- 01xxxxxx xxxxxxxx xxxxxxxx (4M bis 8M): Hardware-Register für MMIO (max. 4 MB)
- 1xxxxxxx xxxxxxxx xxxxxxxx (obere Hälfte, 8M bis 16M): RAM

Die CPU ist in diesem Beispiel der einzige Busmaster (ansonsten bräuchtest du noch BUSREQ/BUSACK, wie oben beschrieben). Um Code oder Daten zu lesen, macht die CPU nun beispielsweise folgendes:
- CPU legt Adresse auf die Adressleitungen
- CPU legt R/W-Leitung auf Low (CPU will lesen)
- CPU legt Taktleitung auf High (Adressen sind jetzt gültig)
- alle Geräte am Bus dekodieren die Adresse (prüfen, ob sie die Adresse besitzen)
- das angesprochene Gerät legt die gewünschten Daten auf den Datenbus
- CPU legt Taktleitung auf Low und liest die Daten ein
Der Takt muss natürlich langsam genug sein, dass die Geräte schnell genug reagieren können.



Nachtrag: Kann man eigentlich Bilder ins Forum hochladen?

Gruß,
Svenska

[Tufelix]

Nun braucht man den eigentlich diese BUSACK-leitung überhaupt? Die Befehle aus der Rom werden ja Zeile für Zeile abgearbeitet. Wenn in der Zeile jetzt steht das ein I/O port- seinen wert in den Ram laden soll, muss das doch nicht von dem CPU abgesichert werden. Weil die CPU ja in diesem Moment nix ausführt.

[Svenska]

Hallo,

du brauchst kein BUSREQ/BUSACK, wenn alle Aktivitäten auf dem Bus von einem Gerät ausgehen. Für solche netten Features wie DMA (allgemeiner: mehrere möglichen Busmaster) brauchst du aber eine Form von Busarbitrierung. Sind aber nicht unbedingt notwendig.

Gruß,
Svenska

[Tufelix]

nun wie würde der bus bei einem cics-CPU ausehen ?

[Svenska]

nun wie würde der bus bei einem cics-CPU ausehen ?

Vier Räder, große Fenster, viele Sitze, ... wie ein Bus halt.

[LittleFox]

Svenska, du kannst nicht sinnvolle Beiträge schreiben? Da hätte ich dir irgendwie nicht zugetraut^^

@Tufelix AFAIK nicht anders als bei einem RISC, der Unterschied ist ja wimre dass die CPU mehr Befehle unterstützt die auch alle mächtiger sind, aber auch mal länger als einen Takt brauchen (können)

[Svenska]

Das sollte subtil darauf hinweisen, dass die Frage ... nicht so toll war.
Ein Bus transportiert Menschen. Dem ist es relativ egal, wie die aussehen.
Ein Bus transportiert Daten. Dem ist es relativ egal, was da angeschlossen ist (schließt die CPU ein).
Hauptsache, man hält sich an die für den Bus gültigen Protokolle (Fahrschein bezahlt, Adressen vollständig dekodiert, ...)