 |
|||
| HSG |
|
Registertransfer
Problemstellung
Nebenstehende Skizze illustriert die zu simulierende Situation: Verschiedene Register sind über einen Bus verbunden. Die Register speichern ein Byte. Sie können über Steuereingänge zum Lesen und Schreiben gebracht werden. In Anlehnung an die existierende Hardware heißen die Eingänge enable und load, wobei jeweils eine anliegende Null den Eingang aktiviert. In der Skizze schreibt gerade Register 1 auf den Bus, Register 3 liest vom Bus. Jede Änderung in Register 1 würde sofort auch eine Änderung in Register 3 bewirken. Im Beispiel verhält sich Register 2 neutral. Das muss nicht so sein. Es können durchaus mehrere Register 'zuhören'. Es könnte auch sein, dass zwei oder mehr Register schreiben wollen. Das wäre ein Fehlerfall. Das Übertragungsmedium ist der Bus. Der Bus könnte z.B. durch Leitungen realisiert sein. Der Bus könnte aber auch die Luft wie bei der menschlichen Sprache (Schall) oder der Raum wie bei elektromagnetischen Wellen (Funk) sein.
Modellierungsansätze
Man wird schnell an Klassen TRegister und TBus denken, die Register und Bus repräsentieren. Aber wie soll der Transfer einer Nachricht modelliert werden? Das Schreiben auf den Bus kann man sich als eine von einem Register bewirkte Zustandsänderung vorstellen. Diese Zustandsänderung muss allen 'Zuhörern' ('Beobachtern', 'Observern') mitgeteilt werden. Dem kontinuierlichen Senden und Empfangen könnte man durch dauerndes Senden und Empfangen (z.B. Timer-gesteuert) gerecht werden. Ein solches Vorgehen würde aber das System unnötig belasten. Nur Änderungen auf dem Bus interessieren die 'Observer'. Der Bus müsste also die angeschlossenen Register über eine Änderung informieren. Das klappt z.B., wenn er eine Liste der Observer führt, die er bei einer Änderung nacheinander informiert. Diese Liste muss dynamisch, dh. während der Laufzeit verwaltet werden. Der Bus kann schließlich bei seiner Herstellung nicht wissen, welche Register er später verbindet. In Delphi gibt es prozedurale Variablen, sodass die Liste, die der Bus führt, auch eine Liste von Ereignis-Behandlungsroutinen sein kann.
Schwierigkeiten
Bei dem beschriebenen Vorgehen tritt bei gleichzeitigem Schreiben und Lesen eines Registers eine Ereignisschleife auf: Das Register ändert den Bus, der wiederum informiert das Register über die Änderung, dh. er ändert - da das Register vom Bus liest - das Register. Diese Änderung ruft eine Änderung des Busses hervor usw. Dieser Schleife kann man folgendermaßen begegnen: Soll das Register schreiben, so meldet man es aus der Observerliste des Busses ab. Steht es nicht in dieser Liste, so schadet die Abmeldung nicht. Beendet man das Schreiben, so muss das Register wieder angemeldet werden, jedoch nur wenn das Register lesen will. Soll das Register lesen, so meldet man nur in der Liste an, wenn Schreiben inaktiv ist.
erste Versuchsimplementierung
offene Probleme
- Die Views sind aus Panels, Buttons, Edits, Shapes und Labels aufgebaut. Das macht eine Mehrfachverwendung und eine Skalierung aufwändig. Schöner wäre ein Aufbau als View-Objekt mit skalierbarer Grafik. Hierbei ergibt sich das Problem, wie die einzelnen Mausklicks verarbeitet werden sollen. Als Lösungsschritt könnte man zuerst einen Digi-Taster modellieren.
- Wie soll auf das Lesen von einem hochohmigen Bus reagiert werden? Beim Bonsai-Computer wird in einem solchen Fall 255 gelesen.
- Die drei Register sind in obiger Implementierung alle Objekte der Klasse TAkkuPc. Die Update-Routinen für die Register müssen aber Objekt-bezogene Methoden sein, damit obiges Konzept funktioniert. Das bedingt ein etwas umständliches Vorgehen.
Links
- Observer-Pattern von Shaun Parry
