Verständnisfragen

Hallo,

beim Wiederholen der Kapitel sind ein paar Fragen aufgekommen. Es wäre nett wenn noch etwas näher auf diese eingegangen werden können:


1. I/O Interfaces und Controller
Kann nochmal kurz erklärt werden wie genau "Controller" ins Gesamtbild passen? Ich habe das so verstanden: Ein I/O Gerät besitzt ein Interface mit einer bestimmten Anzahl an I/O Ports. Es gibt ja Busprotokolle und I/O-Protokolle. Die Busprotokolle sind auf der Hardware-Ebene und regeln die Lese/Schreibvorgänge von/in die Schnittstellenregister des Geräts. Die Controller sind dazu da die wait-zyklen zu implementieren und gleichzeiting eine uniforme Kontrolllogik auf der CPU Seite zu ermöglichen. Sie sind ja eigentlich nichts anderes als Automaten die man als sequentielle Schaltkreise implementieren kann um so mit den Signalen /mreq /mw und /ack einen einheitlichen Austausch zwischen der CPU und langsameren Geräten zu ermöglichen oder?

Sagt man dann, dass die CPU mit den Controllern kommuniziert um über diese auf das Interface zuzugreifen? Und wie passen Busprotokoll/Controller zusammen? Wo besteht da die Verbindung?

2. Interrupts
Es wurde immer wieder unterstrichen das der PC hardwaremäßig gesichert werden muss. Damals wurde auch als Beisspiel eine unglückliche Eigenschaft genannt wenn man dies über Software machen wollte die ich leider vergessen habe. Sehe ich das richtig, dass wenn man den PC Softwaremäßig sichern wollte und dieser gerade PC = 5 beträgt, man die 5 speichert aber durch den Befehl dann der PC auf 6 gestellt wird? Würde man dann aus einer ISR zurückspringen so könnte man ja in eine Endlosschleife geraten wenn der Interrupt z.B. durch einen Befehl INT i ausgelöst wurde und man sagt, dass vor Beendigung des Normalbetriebs der PC durch Software gesichert wird. Ergibt das überhaupt Sinn? Was war nochmal der Grund dafür?

3. Prozesse
Prozesse sind voneinander abgeschirmt und besitzen jeweils einen eigenen Adressraum. Wo sind diese Informationen abgespeichert? Stehen die auch im activation record? Wie prüft ein Prozess dann ob er seine Grenzen überschreiten würde oder nicht?

Mit freundlichen Grüßen,

Pascal



1 mal bearbeitet. Zuletzt am 23.02.2021 14:22 von PascalW.

Hallo,

ich versuche mal Ihre Fragen zu beantworten soweit ich das kann.

> 1. I/O Interfaces und Controller
> Kann nochmal kurz erklärt werden wie genau
> "Controller" ins Gesamtbild passen? Ich habe das
> so verstanden: Ein I/O Gerät besitzt ein
> Interface mit einer bestimmten Anzahl an I/O
> Ports. Es gibt ja Busprotokolle und
> I/O-Protokolle. Die Busprotokolle sind auf der
> Hardware-Ebene und regeln die Lese/Schreibvorgänge
> von/in die Schnittstellenregister des Geräts. Die
> Controller sind dazu da die wait-zyklen zu
> implementieren und gleichzeiting eine uniforme
> Kontrolllogik auf der CPU Seite zu ermöglichen.
> Sie sind ja eigentlich nichts anderes als
> Automaten die man als sequentielle Schaltkreise
> implementieren kann um so mit den Signalen /mreq
> /mw und /ack einen einheitlichen Austausch
> zwischen der CPU und langsameren Geräten zu
> ermöglichen oder?

Genau so ist es. Die CPU und die Controller kommunizieren über die /mreq, /mw und /ack Signale. Die CPU soll dabei möglichst einheitlich nach bestimmten Regeln agieren unabhängig welcher Speicher bzw. welches I/O-Gerät angesprochen wurde. (z.B. Warten auf das Acknowledge vom Speicher und Einfügen von Wait-Zyklen bis das Acknowledge tatsächlich kommt). Das konkrete spezifische Verhalten der angesprochenen Geräte, also wie viele Takte genau jetzt gebraucht wird bevor die von der CPU geforderte Operation ausgeführt wurde (und dann das Acknowledge an die CPU zurückgegeben wird) und zu welchen Zeitpunkten welche Output Enable (bei Lesezugrifen) oder Schreibsignale (bei Schreibzugriffen) aktiviert werden, wird durch die entsprechenden Controller der Geräte realisiert.

> Sagt man dann, dass die CPU mit den Controllern
> kommuniziert um über diese auf das Interface
> zuzugreifen? Und wie passen
> Busprotokoll/Controller zusammen? Wo besteht da
> die Verbindung?

Die Busprotokolle geben vor, wie genau die Kommunikation zwischen dem CPU-Controller und den Controllern der angesprochenen Geräte auszusehen hat und welche Daten wann bereit liegen müssen, z.B. das bei Lesezugriffen nach einer gewissen Zeit nachdem durch /mreq ein Lesezugriff seitens der CPU angekündigt wurde die Adresse an der Adressleitung A garantiert gültig ist. Sobald das angesprochene Gerät dann diese Anfrage verarbeitet hat (was unterschiedlich lang sein kann je nach dem ob z.b. langsamer oder schneller Speicher angesprochen wurde) signalisiert es durck die /ack Leitung, dass die Anfrage verarbeitet wurde und garantiert (wieder nach einer gewissen Zeit) das am Datenbus D die korrekten Daten anliegen, und zwar solange bis die CPU das /mreq wieder "ausschaltet" (+ eine gewisse Zeit danach noch). Dieses ganze Verhalten ist durch das Busprotokoll bestimmt und die Controller der Geräte sind so aufgebaut, dass sie eben dieses Verhalten garantieren können.

> 2. Interrupts
> Es wurde immer wieder unterstrichen das der PC
> hardwaremäßig gesichert werden muss. Damals wurde
> auch als Beisspiel eine unglückliche Eigenschaft
> genannt wenn man dies über Software machen wollte
> die ich leider vergessen habe. Sehe ich das
> richtig, dass wenn man den PC Softwaremäßig
> sichern wollte und dieser gerade PC = 5 beträgt,
> man die 5 speichert aber durch den Befehl dann der
> PC auf 6 gestellt wird? Würde man dann aus einer
> ISR zurückspringen so könnte man ja in eine
> Endlosschleife geraten wenn der Interrupt z.B.
> durch einen Befehl INT i ausgelöst wurde und man
> sagt, dass vor Beendigung des Normalbetriebs der
> PC durch Software gesichert wird. Ergibt das
> überhaupt Sinn? Was war nochmal der Grund dafür?

Sie haben das schon beispielhaft ganz richtig beschrieben. Sie haben momentan PC = 5 und führen irgendeinen Befehl aus (z.B. LOADI ACC x), dann passiert ein Interrupt (wie im Zusatzautomaten gezeigt können Interrupts immer nur nach Takt E3 erfolgen, wir führen den aktuellen Befehl also immer noch aus) und sie müssen ihr derzeitiges Programm abbrechen um den Interrupt zu verarbeiten (über die ISR). Danach wollen sie an der selben Stelle des Programms weitermachen, also mit dem nächsten Befehl nach dem LOADI ACC x, der in PC = 6 steht (wenn wir kein JUMP machen oder zu einem spezifischen Programm springen wollen wird der nächste Befehl normal durch PC := PC +1 ermittelt). Das heißt nach dem Interrupt wollen wir PC = 6 haben. Würden wir den PC softwaremäßig durch, nehmen wir der Einfachheit halber mal einen einzigen Befehl SAVE an, sichern wollen, müssten wir zunächst zum Programm Code dieses Befehls springen (der irgendwo im Speicher liegen könnten, z.B. an Adresse 100). Das heißt wir würden PC = 100 setzen um die softwaremäßige Rettung zu starten, aber zu dem Zeitpunkt haben wir dann schon unseren alten PC Wert von 6, den wir eigentlich sichern wollten, verloren und würden stattdessen jetzt die 100 sichern.

Ich hoffe das ist einigermaßen verständlich formuliert. Falls das nicht Klarheit schafft kann ich es auch nochmal versuchen besser zu formulieren.

> 3. Prozesse
> Prozesse sind voneinander abgeschirmt und besitzen
> jeweils einen eigenen Adressraum. Wo sind diese
> Informationen abgespeichert? Stehen die auch im
> activation record? Wie prüft ein Prozess dann ob
> er seine Grenzen überschreiten würde oder nicht?
>

Ich kann Ihnen das nicht genau sagen. Aber ich würde schätzen dass diese Informationen entweder auch im Activation Record stehen oder jeder Prozess hat zusätzliche Informationen über seinen Adressraum. Der aktuelle Bereich im Code-Segment wird ja über den PC ermittelt, also kann der Anfang des Code-Segmentes einfach durch den Startzustand des Activation Records ermittelt werden. Ähnlich könnte es mit dem Datensegment und dem Stackpointer funktionieren. Wie allerdings das Ende der Segmente ermittelt werden wüsste ich jetzt gerade auch nicht.

Viele Grüße,
Alexander