DE3587622T2 - Emulationseinrichtung in einem Datenverarbeitungssystem. - Google Patents

Description

• Die vorliegende Erfindung betrifft die Emulation eines ersten Rechnersystems durch ein zweites, wesentlich verschiedenes Rechnersystem, insbesondere in der Weise, daß das zweite System für das erste System entwickelte Softwareprogramme ohne Änderung ausführen kann.
• Eine in Rechnersystemen wiederholt auftretende Schwierigkeit ist die Softwareverfügbarkeit und insbesondere die Verfügbarkeit von Anwendungsprogrammen, das heißt, von Programmen, die in Systemen ablaufen oder von solchen ausgeführt werden, um für Anwender spezielle Aufgaben zu erfüllen. Zu Beispielen solcher Anwendungsprogramme gehören die Text- und Datenverarbeitung, Datenbasen, Grafik und Kalkulationstabellen, die den vollständigen Aufgaben- und Funktionsbereich umfassen, die ein Benutzer mit einem solchen System abdecken möchte.
• Der potentielle Anwendungsbereich für ein bestimmtes System ist so, daß es für einen einzelnen Systemhersteller äußerst schwierig ist, für seine Systeme mehr als einen Grundbereich von Anwendungsprogrammen zu entwickeln. Die übrigen und häufig der größere Teil der Anwendungsprogramme wird von Firmen gemeinsam entwickelt und bereitgestellt, die sich auf die Entwicklung von Anwendungsprogrammen spezialisiert haben. Aus wirtschaftlichen Gründen konzentrieren solche Entwickler von Anwendungsprogrammen die ihnen zur Verfügung stehenden Ressourcen gewöhnlich auf die üblicheren Rechnersysteme. Wenngleich Entwickler von Anwendungsprogrammen den Wunsch haben, Programme für die weniger üblichen, aber noch wirtschaftlich bedeutenden Systeme zu liefern, kann es sein, daß die zur Verfügung stehenden Ressourcen die Programmentwicklung für einen vollständigen Bereich verschiedener Systeme nicht erlauben. Daher kann der Bereich von Anwendungsprogrammen für andere als die wenigen, allgemein gebräuchlichsten Systeme begrenzt sein.
• Diese Schwierigkeit ist häufig als ein Problem der Programm-"Übertragbarkeit" bezeichnet worden, das heißt, der Fähigkeit, ein Programm von einem System auf ein zweites, unterschiedliches System "zu übertragen", ohne daß es nötig ist, das Programm neuzuschreiben oder wesentlich zu ändern. Eine von der Computerindustrie insbesondere für die kleineren "Personal-" oder "professionellen" Rechner angenommene Teillösung dieses Problems besteht in der Entwicklung standardisierter Betriebssysteme, die auf vielen intern verschiedenen Rechnern benutzt werden. In diesem Zusammenhang sei darauf hingewiesen, daß Betriebssysteme im wesentlichen den Gesamtbetrieb eines Rechnersystems, auf dem sie "ablaufen", überwachen, leiten und steuern. Außerdem stellt ein Betriebssystem eine Schnittstelle zwischen einem auf einem System ablaufenden Anwendungsprogramm und der tatsächlichen Innenstruktur des Systems selbst bereit. Im wesentlichen "läuft" das Anwendungsprogramm auf dem Betriebssystem "ab" und "sieht" das Betriebssystem und nicht die tatsächliche, darunterliegende Struktur des Rechnersystems. Die Annahme eines solchen gemeinsamen, standardmäßigen Betriebssystems, z . B. CP/M und MS-DOS, die auf einer Vielzahl intern verschiedener Systeme ablaufen, ermöglicht dadurch theoretisch die Entwicklung von Programmen, die auch auf solchen Systemen ohne Abänderung ablaufen werden. Beispielsweise benutzen sowohl die Professionellen Computer der Wang Laboratories und die IBM-PC im wesentlichen dasselbe, als MS-DOS bezeichnete Betriebssystem. Daher sollte es theoretisch möglich sein, daß ein für den IBM-PC entwickeltes Anwendungsprogramm auf dem professionellen Wang-Computer ohne Modifikation abläuft, und umgekehrt.
• In der Praxis stellen solche Betriebssysteme häufig nicht den vollen Merkmals- und Funktionsbereich bereit, den Entwickler von Anwendungsprogrammen wünschen, oder machen Programme, die an ein System nur über das Betriebssystem anschließen, nicht ausreichend leistungsfähig. Deswegen sind viele, wenn nicht alle Anwendungsprogramme tatsächlich so geschrieben, daß sie mit den Innenstrukturen der Systeme, auf denen sie fahren sollen, wenigstens zum Teil direkt gekoppelt sind. Weil die Innenstrukturen von Rechnersystemen verschiedener Hersteller voneinander abweichen, häufig in großem Maße, sind sogar Anwendungsprogramme, die hauptsächlich für den Ablauf auf einem der Standard-Betriebssysteme geschrieben wurden, tatsächlich nicht von einem System auf ein anderes "übertragbar".
• Außerdem haben viele Hersteller die "Standard"-Betriebssysteme zwecks Leistungserhöhung auf ihren speziellen Systemen abgeändert. Wie weiter oben angegeben, benutzen beispielsweise sowohl Wang Laboratories und IBM das gleiche MS-DOS-Betriebssystem als grundsätzliches Standardsystem in ihren Personal- und professionellen Rechnern. Jedoch wurde in jedem Falle das MS-DOS zwecks Leistungserhöhung auf den von Wang und IBM konstruierten speziellen Systemen modifiziert und ist nicht mehr völlig "Standard".
• Solche Modifikationen sind gewöhnlich von den besonderen Merkmalen der Innenstruktur der speziellen Systeme abhängig und finden danach Niederschlag in den für die speziellen Systeme geschriebenen Anwendungsprogrammen. Folglich sind auch Anwendungsprogramme, die nur an ein auf einem speziellen System ablaufendes "Standard"-Betriebssystem ankoppeln, häufig nicht auf ein anderes System übertragbar, das eine noch andere modifizierte Version dieses "Standard"-Betriebssystems benutzt.
• Eine mögliche Lösung dieser Schwierigkeiten besteht für einen Hersteller darin, die Innenstrukturen eines zu emulierenden Systems im wesentlichen zu duplizieren, ohne sie notwendigerweise zu kopieren. Dies erfordert die Entwicklung sowohl der Hardwarestruktur des emulierenden Systems als auch die Entwicklung eines Betriebssystems für das emulierende System, das im wesentlichen die Funktionsvielfalt vom Betriebssystem des zu emulierenden Systems dupliziert. Dieser Lösungsweg kann jedoch insoweit unerwünscht sein, als das emulierte System veraltet ist oder bei dem auf andere Weise Leistungsmerkmale fehlen oder unzureichend sind. Auch sind das emulierende System und sein Betriebssystem im wesentlichen auf einen einzigen Zweck ausgerichtet, den der Emulation eines anderen Systems, statt auf eine Merkmalserweiterung.
• Eine noch andere mögliche Lösung der vorstehend genannten Schwierigkeiten besteht in der Emulation eines speziellen Systems mittels Software, das heißt, mittels Emulationsprogrammen, die auf einem System ablaufen, das dieses System emulieren soll. Dieser Lösungsweg kann sich jedoch als nicht wünschenswert herausstellen wegen des möglicherweise weitgehenden "Mehraufwands", das heißt, wegen zusätzlicher Speicherplätze und zusätzlicher Prozessor-Operationszeit, die für die Emulationsfunktion erforderlich sind.
• Aus einem Artikel von D.A. Deel et al. "A Microprogrammed AN/UYK-20 (V) Emulation" (Mikroprogrammierte AN/UYK-20 (V)-Emulation) in AFIPS Conference Proceedings (Konferenzberichte) über die National Computer Conference 1978 in Anaheim, Kalifornien vom 5. bis 8. Juni 1978, S. 379 bis 384, ist die Emulation eines AN/UYK-20(V)-Rechners auf einem Nanodata QM-1- Rechner bekannt, der für die Mikroprogrammsteuerung zwei Ebenen aufweist, die als Mikro- und Nanoebene bezeichnet sind. Die Emulation des AN/UYK-20(V) durch den QM-1 geschieht vollständig durch auf dem QM-1 ablaufende Software, die aus QM-1-Mikroebenen-Programmen besteht, die ihrerseits eine Vielzahl von Nanoebenen-Emulationsprogrammen aufruft. Für jede Ein-Ausgabeoperation und für jede Unterbrechungsoperation wird eine Emulationsroutine aufgerufen. Daher muß die Software geladen oder "entladen" werden, je nachdem, ob das QM-1-System den AN/UYK-20(V) emuliert oder als QM-1 betrieben wird. Es werden die leistungsmäßigen Erschwernisse und Nachteile einer reinen Software-Emulation beschrieben.
• In US-A-3 955 180, A.C. Hirtle, auf ein Tabellengesteuertes Emulationssystem, ist ein System beschrieben, das die Ein-- Ausgabefunktionen eines anderen Systems durch Feststellen aller Ein-Ausgabeanforderungen, die im emulierenden System auftreten, und durch Ausführen entsprechender Emulationsroutinen in einem dedizierten Ein-Ausgabe-Steuerungsuntersystem emuliert. Dies erfordert für die Durchführung der Emulation ein vollständiges, getrenntes Untersystem mit einer Prozessoreinheit und im Untersystem residenten Emulationsroutinen. Eine einzige System-CPU kann nicht benutzt werden. Ein solches System führt zur Feststellung und Emulation jeder Ein-- Ausgabeoperation, nicht nur jener Ein-Ausgabeanforderungen, die für das emulierende System "fremd" sind.
• In US-A-3 938 101, Lewis et al., auf ein Rechnersystem mit E/A-Simulierung nach Ausführung, ist ein System beschrieben, das eine Einrichtung zur Emulation verschiedener Ein-Ausgabe- Geräte aufweist, die mit dem System verbunden sein können. Die Emulationseinrichtung besteht aus einem "Quasi-E/A-Gerät", das mit dem System so verbunden ist, daß es Antwortsignale liefert, die anscheinend vom emulierten E/A-Gerät kommen, wogegen die Ein-Ausgabeoperation tatsächlich von einer Reihe Emulationsroutinen über ein anderes E/A-Gerät ausgeführt wird. Diese Art der Emulationseinrichtung erfordert die Benutzung eines vollständigen, getrennten "Quasi-E/A-Gerätes" zur Unterstützung der Emulation.
• Aufgabe der Erfindung ist es, einem ersten System, das nicht als funktionelles Duplikat eines zweiten Systems konstruiert ist, die Emulation des zweiten Systems zu ermöglichen, ohne daß hinsichtlich der Hardware, der Software und des Betriebs die weiter oben beschriebenen Nachteile eintreten.
• In der in den beigefügten Ansprüchen definierten Erfindung wird die Ein-Ausgabestruktur des zweiten Systems im ersten System mittels Routinen emuliert, die im ersten System gespeichert sind und die bereits vorhandene Ein-Ausgabestruktur dazu bringen, in derselben Weise zu arbeiten wie die Ein-Ausgabestruktur des zweiten Systems. Die Emulationsroutinen werden ihrerseits durch den Mechanismus für nicht maskierbare Unterbrechungen des ersten Systems aufgrund einer darin vorgenommenen Änderung aufgerufen, die das Auftreten "fremder" Ein-Ausgabe-Anforderungen feststellt, das heißt, Ein-Ausgabe- Anforderungen, die im anfänglich für das zweite System geschriebenen Programm auftreten, aber vom ersten System normalerweise nicht erkannt werden.
• Bei einer derzeit bevorzugten Ausführungsform der vorliegenden Erfindung weist die Ein-Ausgabe-Struktur des ersten Systems Ein-Ausgabe-Geräte mit Anschlüssen auf, die einen ersten Teilbereich des Systemadressenbereichs einnehmen, und die Ein-Ausgabe-Geräte des zweiten Systems weisen Anschlüsse auf, die in einem zweiten, verschiedenen Teilbereich des Adressenbereichs angeordnet sind. Die Einrichtung zum Feststellen fremder Ein-Ausgabe-Anforderungen weist eine Einrichtung auf, die Anschlußadressen für Ein-Ausgabe-Anforderungen mit dem Anschlußadressenbereich zu vergleichen vermag, der von den Ein-Ausgabe-Geräten des Systems eingenommen wird, und anzugeben vermag, wenn eine Anschlußadresse in dem Adressenbereichsumfang liegt, der von den System-Ein-Ausgabe-Geräten eingenommen wird. Die Detektoreinrichtung für Fremdanforderungen erzeugt dann eine nicht maskierbare Unterbrechung, die eine Ein-Ausgabe-Emulationsroutine aufruft, wenn Ein-Ausgabe- Anforderungen erscheinen, welche nicht normalerweise in den Ein-Ausgabe-Anschlußbereich fallen, der vom ersten System unterstützt wird.
• Die Emulationseinrichtung der vorliegenden Erfindung umfaßt ferner eine Einrichtung zum "Einfangen", das heißt Speichern von sich auf solche fremde Ein-Ausgabe-Anforderungen beziehenden Informationen zu dem Zeitpunkt, an dem solche Anforderungen initiiert werden. Die eingefangene Information wird anschließend von der Emulationseinrichtung beim Bestimmen der zu emulierenden Ein-Ausgabeoperation benutzt. Zum Beispiel, wenn die Anforderung eine Schreib-Operation betrifft, wird die zu schreibende Information, die in Verbindung mit der Anforderung erscheint, auf ähnliche Weise eingefangen, um danach an den Ein-Ausgabe-Anschluß des ersten Systems geschrieben zu werden, der im zweiten System dem Anschluß entspricht, welcher in der Anforderung angegeben war.
• Bei einer weiteren Ausführungsform der vorliegenden Erfindung weist das erste System ferner eine Einrichtung zum Emulieren des Hardware-Unterbrechungsmechanismus des zweiten Systems auf. Im Hardware-Unterbrechungs-Emulationsmechanismus des erfindungsgemäßen Systems sind die Software-Unterbrechungsserviceroutinen des ersten Systems mit einer zusätzlichen Gruppe von Hardware-Unterbrechungs-Emulationsroutinen versehen, welche die Arbeitsweise des Hardware-Unterbrechungsmechanismus des zweiten Systems emuliert. Die Unterbrechungs- Vektortabelle des ersten Systems enthält dementsprechend zusätzliche Vektoren zu den Emulationsroutinen, und die Hardware-Unterbrechungsserviceroutinen des ersten Systems sind so geändert, daß sie Verweise auf diese Vektoren enthalten.
• Die Emulationsroutinen, Vektoren und Änderungen an den vorhandenen Hardware-Unterbrechungsroutinen des ersten Systems sind aktiviert, wenn das System das zweite System emuliert. Dadurch emuliert das erste System den Hardware-Unterbrechungsmechanismus des zweiten Systems, indem es Hardware-Unterbrechungs-Emulationsoperationen in derselben Weise durchführt wie Software-Unterbrechungsoperationen. Es sei darauf hingewiesen, daß die hinzugefügten Unterbrechungsmechanismus- Emulationsroutinen nicht auf reine Emulationsroutinen beschränkt sind, sondern ferner andere Routinen umfassen oder durch solche ersetzt sind, die für das System zusätzliche Funktionsfähigkeiten oder Leistungserhöhungen zur Verfügung stellen.
• Das Verständnis für weitere Vorteile und Merkmale der vorliegenden Erfindung ergibt sich für den Fachmann durch Bezugnahme auf die folgende detaillierte Beschreibung einer bevorzugten Ausführungsform und auf die Zeichnungen, in denen zeigt:
• Fig. 1 ein Blockschaltbild eines Rechnersystems der "Personal-" oder "professionellen" Klasse,
• Fig. 2 ein Blockschaltbild einer im System der Fig. 1 benutzten Video-Steuereinrichtung,
• Fig. 3 eine vereinfachte Darstellung der Software- und Steuerungsstruktur eines in Fig. 1 und 2 dargestellten Systems,
• Fig. 4 eine vereinfachte Darstellung der Adressenbereiche des Systems gemäß Fig. 1 bis 3,
• Fig. 5A und 5B vereinfachte Darstellungen einer Emulationseinrichtung für eine Ein-Ausgabe-Struktur, und
• Fig. 6 eine vereinfachte Darstellung eines Hardware-Unterbrechungs-Emulationsmechanismus.
• Im folgenden wird zuerst die allgemeine Struktur und Arbeitsweise der Hardware und Software eines üblichen Rechnersystems der "Personal-" oder "professionellen" Computerklasse beschrieben, z. B. eines professionellen Computers der Wang Laboratories, Inc., wie es dem Fachmann einleuchtet. Sodann werden die struktur- und betriebsmäßigen Merkmale beschrieben, in denen sich ein erstes derartiges System von einem zweiten System, z. B. einem IBM-PC unterscheidet und die Auswirkungen solcher Unterschiede auf die weiter oben beschriebenen "Standard" -Betriebssysteme und Anwendungsprogramme. Schließlich werden das Verfahren und die Vorrichtung gemäß der vorliegenden Erfindung beschrieben, durch die es einem ersten solchen System ermöglicht wird, Programme ohne Änderung "zu fahren", die anfänglich für ein zweites solches System geschrieben wurden.
1. Struktur und Arbeitsweise eines Rechners der "Personal"- oder "professionellen" Klasse A. Hardware-Grundstruktur und Arbeitsweise (Fig. 1 und 2)
• Fig. 1 zeigt ein Blockschaltbild eines Rechnersystems der "Personal-" oder "professionellen" Klasse. Beim dargestellten Beispiel handelt es sich um einen "professionellen Computer" der Wang Laboratories. Dieses System ist für die Klasse solcher Systeme üblich und repräsentativ und beispielsweise im "Technischen Handbuch für Wang Professionelle Computer" und anderen, bei Wang Laboratories, Inc., in Lowell, MA erhältlichen diesbezüglichen Veröffentlichungen beschrieben, die durch Bezugnahme zum Inhalt der vorliegenden Beschreibung gemacht sind. Die nachstehende Beschreibung des Systems gemäß Fig. 1 wird kurz sein, weil Struktur und Arbeitsweise solcher Systeme dem Fachmann gut bekannt sind und weil das hier als Beispiel dargestellte System in den Veröffentlichungen, auf die weiter oben verwiesen wurde und die hier zum Bestandteil gemacht wurden, ausführlich beschrieben sind.
• Wie in Fig. 1 angegeben, umfassen die Hauptkomponenten des Systems eine Zentraleinheit (CPU) 10 und eine Steuer-Ein-Ausgabe-Logik (CIO) 12, welche durch die von einem Systemadressen-Bus (SA) 14, einem Systemdatenbus (SD) 16 und einer System-Steuerung (SC) 18 gebildeten Busstruktur miteinander verbunden sind. Wie ihre Bezeichnungen angeben, übertragen der SA-Bus 14 und der SD-Bus 16 Adressen bzw. Daten zwischen den Systemkomponenten, wogegen der SC-Bus 18 im wesentlichen zur Übertragung von Systemsteuerinformationen benutzt wird.
1. Zentraleinheit (Fig. 1)
• Bezugnehmend auf die CPU 10 werden arithmetische und logische Operationen, darunter wichtige Systemsteuerungsfunktionen, durch einen Hauptprozessor (MP) 20 durchgeführt, der bei arithmetischen Operationen von einem Coprozessor (COP) 22 unterstützt wird. MP 20 und COP 22 können z. B. ein Mikroprozessor Intel 8086 bzw. ein Intel 8087 sein.
• MP 20 und COP 22 übertragen Adressen und Daten an den SA-Bus 14 bzw. an den SD-Bus 16 über einen Adressenzwischenspeicher (AL) 24 bzw. einen Daten-Sendeempfänger (DT) 26, und Speicher- und Bus-Steuerinformationen über eine Bussteuereinrichtung (BC) 28 an den SC-Bus 18.
• Der BC 28 ist eine Ein-Ausgabe-Decodier-Logik (IODL) 29 zugeordnet, die auf dem SA-Bus 14 erscheinende Adressen und auf dem SC-Bus 18 erscheinende Ein-Ausgabe-Steuerinformationen überwacht. Die IODL 29 stellt das Auftreten von System-Ein- Ausgabe-Anforderungen fest und liefert entsprechende Steuersignalausgänge an den SC-Bus 18. Die Steuerausgänge der IODL 29 werden bei der Durchführung von System-E/A-Operationen von den weiter unten näher beschriebenen System-E/A-Geräten benutzt.
• Dem MP 20 und dem COP 22 sind ein Taktgenerator (CG) 30, der die Quelle für die Taktsignale für das System ist, und eine Buserfassungs-Logik (BAL) 32 zugeordnet, welche DMA-Operationen des direkten Speicherzugriffs steuert, das heißt, den weiter unten beschriebenen direkten Transfer von Daten zu und von dem Hauptspeicher des Systems. Ferner ist dem MP 20 und dem COP 22 eine Wartezustands-Logik (WSL) 34 zugeordnet, welche im wesentlichen den Systembetrieb überwacht und die jedem zugemessene Zeit einstellt, um Konfliktsituationen in den Operationen der CPU 10 zu vermeiden. Eine Logik für Nicht Maskierbare Unterbrechungen (NMIL) 36, die weiter unten näher beschrieben wird, steuert einen Teil der Arbeitsweise des System-Unterbrechungsmechanismus.
• Schließlich sind die vorstehend beschriebenen verschiedenen Komponenten der CPU 10 durch einen CPU-Lokalbus (CPUL) 38 miteinander verbunden und stehen durch diesen in Beziehung zueinander.
2. Steuer- und Ein-Ausgabe-Einheit (Fig. 1)
• Bezugnehmend auf die CIO 12: Die Komponenten der CIO 12 sind, wie in Fig. 1 dargestellt, hauptsächlich durch einen Gepufferten Adressen-Bus (BA) 40 und einen Gepufferten Daten-Bus (BD) 42 und durch den SC-Bus 18 miteinander verbunden. Wie dargestellt, ist der BA-Bus 40 über einen Adressenpufferspeicher (AB) 44 an den SA-Bus 14 angeschlossen, wogegen der BD-Bus 42 über Daten-Sendeempfänger (DT) 46 mit dem SD-Bus 16 verbunden ist.
• Die CIO 12 umfaßt einen Hauptspeicher (MM) 48, der vom System zu verarbeitende Daten und die Programme speichert und bereitstellt, welche den Betrieb des Systems steuern, z. B. das Betriebssystem und die Anwendungsprogramme. Dem MM 48 sind zugeordnet eine Hauptspeicher-Steuerlogik (MMCL) 50 und ein Hauptspeicher-Adressen-Multiplexer (MMAM) 52, die mit dem SC- Bus 18 bzw. dem SA-Bus 14 verbunden sind und Steuer- bzw. Adresseneingänge an den MM 48 liefern. Der Daten-Ein-Ausgang des MM 48 ist mit dem BD-Bus 42 verbunden.
• Mit dem Gepufferten Adressenbus (BA) 40 und dem Gepufferten Datenbus (BD) 42 sind ein DMA-Beginnadressen-Zwischenspeicher (DLAL) 54 und ein DMA-Endadressen-Zwischenspeicher (DHAL) 56 verbunden. Die DLAL 54 und DHAL 56 sind Teil vom DMA-Mechanismus des Systems und stellen bei DMA-Operationen des direkten Speicherzugriffs die nieder- und höherwertigen Teile der DMA-Adressen über den SA-Bus 14 und den MMAM 52 an den MM 48 bereit. Den DLAL 54 und DHAL 56 ist ein DMA-Seitenregister (DPR) 58 zugeordnet, das mit dem BA-Bus 40 verbunden ist und bei DMA-Operationen auf ähnliche Weise einen Teil von DMA- Adressen über den SA-Bus 14 und den MMAM 52 an den MM 48 bereitstellt, in diesem Falle jenen Adressenteil, der die bei der DMA-Operation beteiligte Speicherseite identifiziert. DNA-Operationen werden hauptsächlich gesteuert durch die DMA- Steuerlogik (DCL) 60 und die DMA-Bussteuerlogik (DBCL) 62, die mit dem BA-Bus 40 verbunden sind und Datenausgänge an den BD-Bus 42 und Steuerausgänge an andere Systemteile bereitstellen.
• Die in der CIO 12 enthaltene System-Steuerlogik umfaßt eine Zähler- und Zeitgeber-Logik (CTL) 64 und eine Programmierbare Unterbrechungs-Steuereinrichtung (PIC) 66, die z. B. von einem Intel 8253 bzw. Intel 8259A gebildet sein können. Die CTL 64 steuert im wesentlichen den zeitlichen Verlauf aller größeren Systemoperationen, wogegen die PIC 66 in Verbindung mit der NMIL 36 die System-Unterbrechungs-Steuerlogik bildet, welche weiter unten beschrieben wird. Dem MM 48 und der System-Unterbrechungs-Steuerlogik ist eine Paritätsfehler-Logik (PEL) 67 zugeordnet, welche in den MM 48 geschriebene und aus ihm ausgelesene Daten überwacht und an die Unterbrechungs-Steuerlogik ein Paritäts- oder Datenfehlersignal abgibt, wenn ein solcher Fehler auftritt.
• Die System-Programm- und -Steuerlogik umfaßt ferner einen Löschbaren Programmierbaren ROM-Speicher (EPROM) 68, der Programme speichert und bereitstellt, die zum Laden des System- Betriebssystems und der Anwendungsprogramme aus z. B. in externen Laufwerken angeordneten Disketten in den MM 48 benutzt werden. Die im EPROM 68 gespeicherten Programme sind im wesentlichen permanent residente Programme, die zum Initialisieren des Systembetriebs benutzt werden. Die System-Programm- und -Steuerlogik umfaßt ferner eine Arbeitspeicher- Steuerung-Speicherdecodier-Einrichtung (MCSD) 69, die in Verbindung mit EPROM 68 arbeitet, um zu wählen, ob die laufende Systemsteuerung aus dem EPROM 38 bei der Systeminitialisierung, oder von Programmen, die im MM 48 gespeichert sind, im normalen Betrieb zu holen sind.
• Die CIO 12 umfaßt ferner eine Vielzahl von Komponenten zum Übertragen zwischen dem System und externen Geräten, z. B. einer Tastatur, Diskettenlaufwerken und Druckern. Zu diesen Komponenten gehören ein kombinierter Sender-Empfänger-Baustein für asynchrone Datenübertragung (UART) 70, der eine serielle Schnittstelle zu einer Tastatur ist, und eine Disketten-Steuereinrichtung (FDC) 72, die eine Schnittstelle zu einem Diskettenlaufwerk ist. Ferner sind vorgesehen eine Erweiterte Programmierbare Übertragungs-Schnittstelle (EPCI) 74, z. B. ein Intel 2661, die ein programmierbarer E/A-Anschluß RS-232 ist, und eine Paralleldrucker-Schnittstelle (PPI) 76, z. B. ein Intel 8255A, die eine parallele Schnittstelle zu verschiedenen Druckern ist. Zu weiteren Ein-Ausgabeelementen können gehören Schnittstellen-Komponenten zu z. B. Festplatten-Laufwerken und zu verschiedenen Telekommunikations-Fernschnittstellen.
• Schließlich enthält die CIO 12 eine E/A-Steuerungs-Speicher- Decodier-Einrichtung (IOCSD) 75, die im wesentlichen Befehlssequenzen speichert und bereitstellt, das heißt, Routinen zum Steuern der Ein-Ausgabeoperationen des Systems und insbesondere der Operationen der vorstehend beschriebenen E/A-Geräte.
3. Video-Steuereinheit (Fig. 2)
• Das System umfaßt zwei hauptsächliche Benutzeroberflächen: Die erste, oben beschriebene, ist eine mit dem UART 70 verbundene Tastatur und die zweite ist ein Bildschirm-Anzeigegerät. In Fig. 2 ist eine Videosteuereinrichtung (VC) 78 dargestellt, welche die Schnittstelle zwischen dem System und einer Kathodenstrahlröhre bildet. Während dem hier beschriebenen System eine Vielzahl solcher Videosteuereinrichtungen für verschiedene Anzeigegeräte zur Verfügung stehen, ist die VC 78 für diese Klasse von Datensichtgerät-Schnittstellenorganen üblich und bietet Darstellungen sowohl grafisch für Zeichensätze als auch in bitweiser Abbildung.
• Es wird zuerst Bezug genommen auf den Zeichensatz-Teil der VC 78. Die VC 78 umfaßt einen Zeichenspeicher (CM) 80 zum Speichern und Bereitstellen von ASCII-Codes, die alphanumerische Zeichen, grafische Symbole und zugehörige textuelle Symbole zur Darstellung am Bildschirm bereitstellen. Diese Codes sind im CM 80 an Stellen gespeichert, die den Stellen entsprechen, an denen sie auf dem Anzeigegerät erscheinen sollen. Dem CM 80 ist ein Attributspeicher (AM) 82 zugeordnet, der für jeden im CM 80 gespeicherten Zeichencode entsprechende Attributcodes speichert und bereitstellt, die angeben, ob das entsprechende Zeichen oder Symbol z. B. unterlegt, unterstrichen usw. sein soll.
• Das Schreiben von Informationen in den CM 80 und den AM 82 geschieht vom SD-Bus 16 aus an vom SA-Bus 14 gelieferte Adressen und mit Steuerung durch Steuereingänge vom SC-Bus 18. Zu diesen Zwecken enthält die VC 78 einen VC-Adressen- Pufferspeicher (VCAB) 84, der mit dem SA-Bus 14 verbunden ist und entsprechende Adresseneingänge an einen C/A-Speicher-Eingabeadressen-Multiplexer (CMIAM) 86 liefert. Der CMIAM 86 gibt seinerseits Adresseneingänge an den CM 80 und den AM 82 ab. Gemäß Fig. 2 liefert der VCAB 84 Adresseneingänge auch an einen C/A-Speicher-Ausgabe-Multiplexer (CMOM) 88, der, wie weiter unten beschrieben, das Lesen von Zeichen- und Attributcodes aus CM 80 und AM 82 und ihre Weiterleitung an die das Datensichtgerät steuernde Logik steuert.
• Die VC 78 umfaßt ferner einen VC-Daten-Sendeempfänger (VCDT) 90, der mit dem SD-Bus 16 verbunden ist und zum Teil zum Schreiben von Zeichen- und Attributcodes in den CM 80 und den AM 82 benutzt wird. Gemäß Fig. 2 ist der VCDT 90 auch mit einem Ausgang zu einer Bildschirm-Steuereinrichtung (CRTC) 92 versehen, welche ihrerseits Steuersignale an die Bildschirm- Treiberschaltungen abgibt, und mit einem mit einem weiter unten beschriebenen Fontspeicher (FM) 94 verbundenen Eingang, welcher das Übertragen der Inhalte des FM 94 auf den SD-Bus 16 ermöglicht.
• Der FM 94 wird zum Speichern von Bitmustern benutzt, die den verschiedenen Zeichen- und Symbolcodes entsprechen, die am Datensichtgerät darstellbar sind. Die Codes, die im CM 80 gespeichert sind und auf dem Datensichtgerät anzuzeigende Zeichen und Symbole darstellen, werden aus dem CM 80 mit Steuerung durch Adressen ausgelesen, welche die CRTC 92 über den CMIAM 86 liefert und als Adresseneingänge an den FM 94 abgegeben werden. Der FM 94 seinerseits antwortet auf diese Eingänge durch die Abgabe der entsprechenden Bitmuster als Ausgänge an ein Bitmuster-Schieberegister (BPSR) 96, das seinerseits eine Parallel-Serien-Umsetzung vornimmt und die sich ergebenden seriellen Bitmuster an eine Attribut-Logik (AL) 98 abgibt.
• Gemäß Fig. 2 umfaßt die AL 98 einen weiteren Eingang, der mit dem Ausgang von AM 82 verbunden ist. Die den im CM 80 gespeicherten Zeichen-/Symbolcodes entsprechenden Attributcodes werden aus dem AM 82 parallel mit aus dem CM 80 ausgelesenen entsprechenden Codes gelesen und von der AL 98 benutzt, um die vom BPSR 96 abgegebenen Bitmuster in zweckdienlicher Weise so zu modifizieren, daß die entsprechenden Zeichen/Symbole mit ihren entsprechenden Attributen bereitgestellt werden. Der Ausgang der AL 98 ist als Text-Video-Ausgang zu den Bildschirm-Treiberschaltungen vorgesehen, um am Datensichtgeräteschirm eine entsprechende Anzeige zu erhalten.
• Schließlich weist die VC 78 eine Taktgenerator-Logik (TGL) 100 auf, die an den SC-Bus 18 angeschlossen ist und Takt- und Steuersignale an die Logik und die Schaltung der VC 78 abgibt.
• Es wird nun auf den sich auf die bitweise Darstellung beziehenden Teil der VC 78 verwiesen. Ein Bildspeicher (BM) 102 speichert und liefert auf dem Schirm des Datensichtgerätes in bitweiser Darstellung anzuzeigende Bilddaten. Die anzuzeigenden Informationen werden in den BM 102 in bitweiser Form über den Datenbus, der an den Ausgang des VCDT 90 angeschlossen ist, und mit Steuerung durch Adressen eingeschrieben, welche durch einen Adressenbus geliefert werden, der mit einem Ausgang eines Bildspeicheradressen-Multiplexers (BMAM) 104 verbunden ist. Der BMAM 104 empfängt seinerseits Schreibadresseneingänge von dem mit dem Ausgang des VCAB 84 verbundenen Adressenbus.
• Der BMAM 104 empfängt auch Leseadresseneingänge von den Ausgängen eines X-Achsen-Adressengenerators (XAAG) 106 und eines Y-Achsen-Adressengenerators (YAAG) 108. Die im BM 102 als digitales Muster gespeicherten Bilddateninformationen werden aus dem BM 102 mit Steuerung durch die Leseadressen gelesen, welche vom XAAG 106 und YAAG 108 und durch ein Digitalmuster- Schieberegister (BMSR) 110, das eine Parallel-Serien-Umsetzung vornimmt, geliefert werden, um in einem Video-ODER-Glied (VORG) 112 mit einem möglichen Bildinformationen-Ausgang aus AL 98 kombiniert zu werden. Der Ausgang des VORG 112 wird dann als Video-Ausgang an die Bildschirm-Treiberschaltungen abgegeben und ergibt eine entsprechende Darstellung am Bildschirm.
• Der BM 102 wird detailliert gesteuert durch eine BM-Steuerlogik (BMCL) 114, die ihrerseits Steuersignale von der TGL 100 empfängt.
B. Grundsätzliche Software- und Steuerstruktur und Arbeitsweise (Fig. 3)
• Fig. 3 zeigt eine vereinfachte Darstellung einer beispielhaften Software- und Steuerstruktur eines Rechnersystems des weiter oben beschriebenen Typs.
1. Anwendungsprogramme, Betriebssystem und Ein-Ausgabe- Grundsystem (Fig. 3)
• Wie in Fig. 3 angegeben, ist die Software/Steuerstruktur eines üblichen Systems auf mehrere Ebenen verteilt. Die/das laufende(n) Anwendungsprogramm(e) (AP) 116 ist/sind die oberste, am deutlichsten sichtbare Ebene. Die System-Hardwarestruktur (HS) 118, einschließlich CPU 10 und CIO 12 und zugehörigen Externen Geräten (ED) 120, z. B. Datensichtgeräte, Tastaturen, Diskettenlaufwerke, Drucker und Telekommunikationsgeräte, ist die unterste Ebene.
• Zwischen den AP 116 und der HS 118 liegen das Betriebssystem (OS) 120 und das Ein-Ausgabe-Grundsystem (BIOS) 122. Wie weiter oben beschrieben wurde, hat ein OS 120 als wesentliche Aufgabe die Überwachung, Leitung und Steuerung des Gesamtbetriebes vom Rechnersystem. Außerdem bildet das OS 120 eine Schnittstelle zwischen den auf dem System laufenden AP 116 und der tatsächlichen Innenstruktur des Systems selbst, einschließlich der HS 118. Die AP 116 "laufen" im wesentlichen auf dem OS 120 "ab" und "sehen" das OS 120 statt der tatsächlichen, darunterliegenden Systemstruktur. Bei vielen Systemen ist das häufig als Plattenbetriebssystem (DOS) bezeichnete OS 120 im MM 48 resident und ist von einer Diskette geladen worden.
• Wie ebenfalls weiter oben beschrieben, sind die darunterliegenden Strukturen von Rechnersystemen, häufig in großem Maße, verschieden als Folge des von ihrem Entwickler gewählten Entwurfs, der angestrebten Merkmale und Funktionen und der verfügbaren Implementierungstechnik. Um als Standard zu gelten, kann ein Betriebssystem nicht direkt mit der Systemhardware in Verbindung treten, sondern muß eine Schnittstelle spezifizieren zu Hardware-Steuerroutinen, die jeder Hardware-Hersteller vorsieht. Folglich kann ein "Standard"-Betriebssystem, wie das OS 120, im allgemeinen nicht direkt auf der Systemstruktur ablaufen.
• Aus diesem Grunde weist die System-Steuerstruktur ferner als Teil der Innenstruktur des Systems die weitere, als Ein-Ausgabe-Grundsystem (BIOS) 122 bezeichnete Ebene auf. BIOS 122 besteht im wesentlichen aus Sequenzen von Routinen, das heißt, Programmen, welche die Funktionen und Operationen der Systemstruktur auf der niedrigsten und detailliertesten Ebene leiten und steuern, und bildet eine Schnittstelle zwischen dem OS 120 und der Innenstruktur des Systems. Das BIOS 122 bildet auch eine weiter unten beschriebene primäre Einrichtung, durch welche die Systemkomponenten, z. B. die die HS 118 bildenden, untereinander und mit den höheren Steuerebenen kommunizieren. Außerdem bieten viele BIOS-Systeme zusätzliche Serviceroutinen oder Merkmale, die nicht zum Standardbetriebssystem gehören und eine zusätzliche Funktionsfähigkeit im System sichern oder die Leistung des Systems erhöhen.
• BIOS 122 kann im MM 48 resident sein, nachdem es von einer Diskette aus geladen wurde, oder in einem Lesespeicher (ROM) in derselben Weise resident sein wie die im EPROM 68 permanent gespeicherten System-Initialisierungsroutinen. Bei vielen Systemen steht das BIOS 122 zum Teil in einem ROM und zum Teil als ladbare Routinen im MM 48.
2. Unterbrechungsmechanismus (Fig. 3)
• Zur Systemstruktur gehört eine weitere Steuer- und Übertragungskomponente, die als Unterbrechungsmechanismus (IM) 124 bezeichnet wird. Der IM 124 ist im wesentlichen ein Mechanismus zum Behandeln von Ereignissen, die während der Ausführung eines Programms auftreten, aber gewöhnlich nicht als direkter Arbeitsschritt im Programmablauf ausgeführt werden. Wenn ein solches Ereignis auftritt, wird die Ausführung des Programms "unterbrochen", der Zustand des Programmablaufs gesichert, das Ereignis behandelt und das Programm von der Stelle aus weitergeführt, an der es unterbrochen wurde.
• Die zwei Hauptklassen von Unterbrechungen sind Software-Unterbrechungen, die von AP 116 oder Routinen des OS 120 ausgelöst werden, und Hardware-Unterbrechungen, ausgelöst durch den Betrieb der die HS 118 bildenden Komponenten. Das heißt, Software-Unterbrechungen werden von einem Programm aufgerufen, wenn das Programm die Ausführung einer Operation durch das Betriebssystem oder durch die System-Hardware wünscht, wogegen Hardware-Unterbrechungen erzeugt werden, wenn eine Komponente der System-Hardware bedient werden muß.
• Die Unterbrechungsroutinen arbeiten im wesentlichen auf derselben Detailebene wie die Routinen des BIOS 122 und werden, wie bei dem in Fig. 1 und 2 dargestellten Systembeispiel, als Teil der Routinen betrachtet, die im BIOS 122 resident sind. In Abhängigkeit von der speziellen Zuordnung von Funktionen innerhalb des BIOS 122 und des IM 124, können die Unterbrechungsroutinen jedoch als einen getrennten Satz Routinen bildend betrachtet werden. Auch hier können die Unterbrechungsroutinen als ladbare Routinen im MM 48 oder in einem ROM oder in beiden resident sein.
• Die Behandlung von Software-Unterbrechungen, das heißt, das Aufrufen oder Starten der zweckdienlichen Software-Unterbrechungs-Behandlungsroutinen wird in derselben Weise durchgeführt wie der Aufruf oder das Starten von Routinen des BIOS 122. Das heißt, eine Routine der AP 116 oder des OS 120 gibt eine Anforderung oder einen Befehl aus, die bzw. der die im MM 48 oder in einem ROM gespeicherte zweckdienliche Unterbrechungs-Behandlungsroutine adressiert.
• Hardware-Unterbrechungen, die durch die HS 118 erzeugt werden, werden durch eine zu diesem Zweck vorgesehene spezifische Logik ausgelöst und folgen aus der Arbeitsweise der Komponenten der HS 118. Bei dem Systembeispiel gemäß Fig. 1 und 2 wird dieser Mechanismus durch die PIC 66 und die NMIL 36 gebildet. Im wesentlichen sind PIC 66 und NMIL 36 zu diesem Zweck mit spezifischen Steuersignaleingängen von den verschiedenen Komponenten der HS 118 versehen. Wenn durch einen solchen Unterbrechungseingang das Auftreten einer Unterbrechungsbedingung in einer Komponente der HS 118 an die PIC 66 oder die NMIL 36 angezeigt wird, gibt die PIC 66 oder die NMIL 36 eine entsprechende Anforderung oder Anweisung aus, die auf eine entsprechende Stelle in einer im Speicher residenten Unterbrechungs-Vektortabelle zugreift. Die Unterbrechungs-Vektortabelle enthält ihrerseits Vektoren oder Adressen, welche die Stelle der entsprechenden Unterbrechungs-Behandlungsroutine im Speicher identifizieren. Sodann wird ein aus der Tabelle gelesener Vektor benutzt, um die entsprechende Unterbrechungs-Behandlungsroutine anzuwählen und zu starten.
• PIC 66 und NMIL 36 starten Unterbrechungsoperationen für zwei Typen Unterbrechungsbedingungen. Dabei handelt es sich um maskierbare und um nicht maskierbare Unterbrechungen, von denen die nicht maskierbaren Unterbrechungen im wesentlichen Bedingungen sind, die sofort behandelt werden müssen, wogegen maskierbare Unterbrechungen Unterbrechungsbedingungen sind, deren Behandlung, wenn notwendig, hinausgezögert werden kann. Beispielsweise gehören zu nicht maskierbaren Unterbrechungen Paritäts- oder Datenfehler, die bei Leseoperationen im MM 48 auftreten, und, wie weiter unten beschrieben, die Behandlung von E/A-Operationen, wenn das System als Emulator eines anderen Systems arbeitet. Maskierbare Unterbrechungen, welche die größere Gruppe von Unterbrechungsbedingungen sind, werden in zweiter Linie nach nicht maskierbaren Unterbrechungen behandelt und sind innerhalb der Klasse priorisiert, wobei die relative Priorität maskierbarer Unterbrechungen durch die Programmierung der PIC 66 bestimmt ist, wie weiter unten beschrieben wird. Zu maskierbaren Unterbrechungen gehören, als Teilbeispiel, Tastatureingaben, Disketten-E/A-Abschluß, Drukker-E/A und serielle E/A-Operationen.
C. System-Adressenstruktur (Fig. 4)
• Der Adressenbereich des in Fig. 1 bis 3 dargestellten Systembeispiels ist im wesentlichen in zwei Adressenteilbereiche unterteilt, von denen der erste der allgemeine (Programm/Daten-)Bereich für Programme, Routinen und Daten ist und der zweite der (E/A- und Steuerungs-)Bereich für Ein-Ausgaben und Systemsteuerung. Auf beide Adressenteilbereiche wird über den BA-Bus 40 und den BD-Bus 42 zugegriffen, und der Bereich, auf den zugegriffen wird, wird bestimmt durch die auszuführende Operation.
• Der Bereich Programm/Daten ist im allgemeinen gebildet vom MM 48 und Programm-ROM-Speichern, z. B. dem EPROM 68. Dieser Adressenbereich wird im allgemeinen benutzt zum Speichern von Programmen und Routinen, z. B. den AP 116, des OS 120 und des BIOS 122, einschließlich der Unterbrechungsroutinen, und von Daten, die zu bearbeiten sind oder sich aus dem Arbeiten solcher Programme und Routinen ergeben. Wie weiter unten angegeben, gehört zu diesem Bereich der in der VC 78 residente Speicherbereich für Bildsichtgerät-E/A-Funktionen.
• Der Adressenbereich E/A-Steuerung ist von Registern und Speichern in Steuer- und E/A-Komponenten des Systems gebildet. Dieser Adressenbereich wird beispielsweise zum Speichern und Bereitstellen von Informationen benutzt, die in der Systemsteuerung, zum Programmieren bestimmter Systemsteuerfunktionen und zum Übertragen von Informationen zwischen dem System und externen Komponenten, z. B. einem Diskettenlaufwerk oder der Tastatur benutzt werden. Wie oben beschrieben, können aber bestimmte E/A-Funktionen im Bereich Programme/Daten stehen.
• Hinsichtlich der Systemsteuerung sei darauf hingewiesen, daß viele Systemkomponenten, wie die PIC 66 oder die EPCI 74, zur Durchführung von den Systembetrieb unterstützenden Funktionen individuell programmierbar sind. Die Arbeitsweise solcher Komponenten wird programmiert, indem zweckdienliche Befehle und/oder Daten adressiert und in ihre internen Speicherplätze geschrieben werden. Diese Komponenten können ihrerseits Informationen speichern und liefern, die bei der Steuerung der Systemarbeitsweise benutzt werden, wenn auf die Speicherplätze darin in zweckdienlicher Weise zugegriffen wird. Beispielsweise kann die PIC 66 so programmiert werden, daß sie die Prioritätsbeziehungen der System-Unterbrechungsbedingungen bestimmt und die zweckdienlichen Unterbrechungsroutinen angibt, die für jede solche Bedingung aufzurufen sind. Informationen, die bereits eingetretene Unterbrechungsbedingungen betreffen, werden in dortigen Registern gespeichert und können durch die Unterbrechungsbehandlungsroutinen erreicht werden, um die zu treffende zweckdienliche Maßnahme zu bestimmen. Andere Systemsteuerkomponenten, wenngleich nicht programmierbar, können ebenfalls den Systembetrieb betreffende Informationen speichern und liefern, auf die für diese Zwecke zugegriffen werden kann und die hierfür benutzt werden können.
• Bei den System-E/A-Funktionen lassen sich viele Komponenten, z. B. die FDC 72, die EPCI 74 und die PPI 76, auf ähnliche Weise programmieren, und sie umfassen zusätzlich Register und Speicherplätze, welche die Wege bilden, auf denen Informationen zwischen dem System und externen Komponenten übertragen werden. Beispielsweise enthält die FDC 72 Register, die zum Speichern und Puffern von zwischen dem System und einer Diskette übertragenen Informationen benutzt werden. Diese Register werden über den BA-Bus 40 adressiert, und auf oder von einer Diskette zu übertragende Informationen werden über den BD-Bus 42 in die Register geschrieben oder aus ihnen gelesen. Als weiteres Beispiel kann der UART 70 ähnliche Register enthalten, die zum Puffern und Speichern von Tastenanschlaginformationen benutzt werden, bis sie vom System gelesen werden.
• Fig. 4 zeigt eine vereinfachte Darstellung des System-Adressenbereichs. Die verschiedenen Teilbereiche innerhalb des dargestellten Adressenbereiches sind durch die in hexadezimaler Notation links im Diagramm angegebenen Adressen bezeichnet. Die Funktion jedes Adressenbereichsegments ist rechts im Diagramm angegeben.
• Erstens, im Bereich Programme/Daten ist beispielsweise der Adressenbereich 00000H bis 9FFFFH (H = hexadezimal) der allgemeine Adressenbereich, der für die CPU 10 zugänglich ist und im allgemeinen im MM 48 steht. Innerhalb dieses Bereiches sind die Adressen 0000H bis 003FF reserviert und z. B. an die weiter oben beschriebenen Tabellen dediziert, die vom IM 124 benutzt werden. Die Adressenbereiche E0000H bis F3FFFH sind einem Bildsichtgerätespeicher, beispielsweise den in der VC 78 stehenden Anzeigespeichern zugeordnet. In dieser Hinsicht entspricht der Adressenbereich F0000H bis F0FFFH dem CM 80 und dem AM 82, F2000H bis F3FFFH dem FM 94 und E0000H bis E7FFFH dem BM 102. Schließlich ist der Adressenbereich FC000H bis FFFFFH reserviert und beispielsweise an den EPROM 68 und die darin gespeicherten Routinen dediziert.
• Zweitens, im Bereich E/A-Steuerung werden die Adressen 1000H bis IFFFH für Ein-Ausgabe- und Steuer-Funktionen benutzt. Von diesem Adressenbereich belegen die in Fig. 1 dargestellten Komponenten die Adressen 1000H bis 10FFH, wogegen die Adressen 1x00H bis 1xFFH, mit x gleich oder größer 1, für zusätzliche und wahlweise Komponenten reserviert sind, z. B. für Festplattenlaufwerke.
• Nachdem nun die Struktur und die Arbeitsweise eines üblichen Systems der "Personal-" oder "professionellen" Rechner-Klasse beschrieben wurden, werden nachfolgend jene Faktoren beschrieben, welche die Emulation eines solchen Systems durch ein anderes System durchführen.
2. Systememulation auslösende Systemunterschiede
• Wie weiter oben beschrieben, ergibt sich bei der "Softwareübertragbarkeit", das heißt, der Fähigkeit eines für ein erstes System geschriebenen Programms, auf einem zweiten, verschiedenen System ohne Modifikation abzulaufen, eine Hauptschwierigkeit aus der von den Entwicklern von Anwendungsprogrammen durchgeführten Praxis, das Betriebssystem zu "umgehen", das heißt, in das Anwendungsprogramm Instruktionen und Befehle einzubauen, die zum BIOS, zum Unterbrechungsmechanismus oder zur Hardwarestruktur eines Systems direkt gehen statt nur zum und durch das Betriebssystem. Folglich, und wegen der möglichen Unterschiede zwischen zwei solchen Systeme in der Innenstruktur, kann es sein, daß ein Anwendungsprogramm, das für das erste System geschrieben wurde und Instruktionen und Befehle direkt an die Innenstruktur des ersten Systems liefert, beim Ablauf auf dem zweiten System das erwartete Ergebnis nicht zu erzeugen vermag.
• Beispielsweise kann sich das zweite System unterscheiden in der Struktur und Arbeitsweise seines BIOS, in der bitweisen Darstellung oder Plazierung von Programmen und Routinen in seinem Adressenbereich Programme/Daten, hinsichtlich seines Unterbrechungsmechanismus, seines Adressenbereichs E/A-Steuerung oder seiner Hardwaregeräte. Die beiden Systeme können für denselben Zweck verschiedene Geräte oder dasselbe Gerät für verschiedene Zwecke benutzen. Beispielsweise wird die PPI 76 im Wang-PC als Treiber für einen Paralleldrucker benutzt, aber dasselbe Gerät wird im IBM-PC als Tastaturschnittstelle benutzt. Als weiteres Beispiel kann ein System einen Signetics 2661 UART für serielle E/A-Operationen einsetzen, wogegen ein anderes System einen National Semiconductor 8250 UART benutzt, die je auf verschiedene Befehle ansprechen und verschiedene E/A-Adressen benutzen. Als noch anderes Beispiel können zwei Systeme Tastaturen benutzen, die sich hinsichtlich der vorgesehenen Tasten und des den verschiedenen Tasten entsprechenden Hardwarecodes unterscheiden. Wie weiter oben beschrieben, ist das BIOS eines Systems im wesentlichen die Brücke zwischen dem Betriebssystem und der Hardwarestruktur des Systems. Als solche können die BIOS-Systeme von zwei Systemen entsprechend differieren, und eine Instruktion oder ein Befehl, die bzw. der für das BIOS des ersten Systems gültig ist, kann für das BIOS des zweiten Systems ungültig sein.
• Als weiteres Beispiel kann die Organisation der Adressenbereiche Programme/Daten bei zwei Systemen so unterschiedlich sein, daß ein für das erste System geschriebenes Anwendungsprogramm versucht, Daten oder Routinen in einen Teil des Programm/Daten-Bereiches vom zweiten System zu schreiben oder diesen Teil zu modifizieren, der für bzw. an andere Funktionen reserviert oder dediziert ist. Beispielsweise ist der Programm/Daten-Bereich des Wang-PC, der der Speicherung von Bildsichtgeräte-Informationen zugeordnet ist, also die Speicherplätze der VC 78, verschieden von dem Speicherplatz ist, der dieser Funktion im IBM-PC zugeordnet ist. Daher wird jedes Programm, das für den IBM-PC geschrieben ist und Bildsichtgeräteausgänge liefert, die direkt in die VC 78 geschrieben werden, nicht in der Lage sein, auf dem Wang-System einwandfrei abzulaufen, und umgekehrt.
• Als noch weiteres Beispiel unterscheiden sich die Unterbrechungsmechanismen der Wang- und IBM-PC in zweierlei Hinsicht. Erstens, und wie oben schon angedeutet, die Unterbrechungs- Behandlungsroutinen und -tabellen der beiden Systeme stehen in verschiedenen Teilen der Adressenbereiche beider Systeme, so daß ein Anwendungsprogramm für einen IBM-PC, das eine Unterbrechungsroutine direkt aufruft, auch hier nicht einwandfrei ausgeführt werden kann. Als weitere Differenz kann bei einem Wang-PC eine spezielle Hardware-Unterbrechungsroutine von mehreren Geräten kommende Unterbrechungen abarbeiten, wobei der Unterbrechungsmechanismus das spezielle Gerät identifiziert, das bedient werden muß. Beim IBM-PC ist jedes Gerät mit einem individuellen Unterbrechungsvektor versehen, das heißt, jedes Gerät ist effektiv mit einer getrennten Unterbrechungsserviceroutine versehen. Außerdem können die Software-Unterbrechungsserviceroutinen der beiden Systeme völlig verschiedene Spezifikationen aufweisen, das heißt, es kann notwendig sein, daß sie auf völlig verschiedene Bedingungen ansprechen.
• Als letztes Beispiel können die Adressen oder "Anschlüsse" der Ein-Ausgabe-Geräte der beiden Systeme in verschiedene Teilbereiche ihrer Adressenbereiche E/A-Steuerung aufgeteilt sein, innerhalb ihrer zugehörigen Bereiche verschieden organisiert sein oder verschiedene E/A-Geräte bedienen.
3. Emulation eines ersten Systems durch ein zweites System (Fig. 5A, 5B und 6)
• Die Emulation eines ersten Systems durch ein zweites System in der Weise, daß für das erste System geschriebene Programme auf dem zweiten System ablaufen können, ohne durch es modifiziert zu werden, erfordert eine Emulation des ersten Systems in vierfacher Hinsicht. Dabei handelt es sich um das BIOS, die Aufteilung des Adressenbereiches Programme/Daten, den Unterbrechungsmechanismus und die Aufteilung, Struktur und Funktionsfähigkeit des Adressenbereichs E/A-Steuerung.
• Die Funktion, Arbeitsweise und Konstruktion eines BIOS-Systems, das ein spezielles Betriebssystem mit der Hardware und der Innenstruktur eines gegebenen Systems koppelt, sind dem Fachmann bekannt und werden hier nicht mit weiteren Einzelheiten beschrieben. Es sei darauf hingewiesen, daß die Forderung, daß ein spezielles BIOS ein anderes BIOS emuliert, eher als Auslegungsbeschränkung statt als fundamentale Änderung der Art des emulierenden BIOS wirkt.
• In ähnlicher Weise ist die Neuaufteilung des Adressenbereichs Programme/Daten eines Systems zur Emulation jenes eines anderen Systems dem Fachmann bekannt und kann in vielen Systemen einfach ausgeführt werden, gewöhnlich mit Steuerung durch zu diesem Zweck geschriebene Programme. Beispielsweise bei der Emulation eines IBM-PC auf einem Professionellen Wang-PC erfordert die primäre Aufteilung des Programme/Daten-Bereichs im Wang-System die Zuordnung von Adressenbereichen für den IBM-Bildsichtgeräte-Speicher und bestimmter reservierter Adressenbereiche und die Neuzuordnung der Wang-Unterbrechungstabellen und -routinen.
• Als Beispiel: Im Wang-System werden die Adressenbereiche B0000H bis B0FFFH und B1000H bis B1FFFH, die sonst frei sind, je zur Aufnahme eines Rahmenpuffers, ähnlich dem CM 80 und dem AM 82 der VC 78, und eines reservierten Adressenbereiches zugeordnet, der einem solchen Bereich im System des IBM-PC entspricht. Dadurch kann die VC 78 Anzeigedaten an den und an die Adressen empfangen und liefern, die von den für das IBM- PC-System geschriebenen Programmen erwartet werden.
• Wie weiter oben beschrieben, stehen die Unterbrechungstabellen und -routinen des Wang-Systems in den Speicherzellen 00000H bis 003FFH des Wang-Programme/Daten-Bereiches. Von diesen Teilbereichen sind jedoch im IBM-PC-System bestimmte nicht geschützt oder reserviert, und für den IBM-PC geschriebene Programme können in diesen Teil des Adressenbereichs vom Wang-System schreiben oder ihn auf andere Weise modifizieren. Demgemäß werden bestimmte Wang-Unterbrechungsvektoren, das heißt, Adressen, die auf Speicherstellen von Unterbrechungsbehandlungsroutinen für Hardwarefunktionen des Wang-PC verweisen, von den Vektoren Nr. 00080H bis 00087H (Adressen 200H bis 21FH) nach den Vektoren Nr. 00050H bis 00057H (Adressen 140H bis 15FH) verlagert, die im IBM-PC-System reserviert sind. Die Verlagerung dieser Unterbrechungsvektoren erfordert die Umprogrammierung der PIC 66, so daß die PIC 66 als Antwort auf die entsprechenden Unterbrechungsbedingungen die entsprechenden neuen Adressen der verlagerten Vektoren liefert. Wie weiter oben beschrieben, ist die PIC 66 eine programmierbare Einrichtung und läßt sich zu diesem Zweck durch das Emulations-BIOS oder eine andere zu diesem Zweck bereitgestellte Software entsprechend umprogrammieren.
• Die übrigen zwei Bereiche der Systememulation, nämlich die Aufteilung, Struktur und Funktionsvielfalt des Adressenbereichs E/A-Steuerung, und der Unterbrechungsmechanismus werden hier anschließend in näheren Einzelheiten dargestellt.
1. Emulation der E/A-Struktur (Fig. 5A und 5B)
• Wie weiter oben beschrieben, ist die E/A-Struktur des Systems von den Hardwarekomponenten und den steuernden Routinen gebildet, durch die Informationen zwischen dem System und externen Geräten, z . B. Diskettenlaufwerken, Bildsichtgeräten, Tastatur und seriellen und parallelen Ein-Ausgabegeräten übertragen werden. Wie ebenfalls schon genannt, können ein emulierendes System und das emulierte System häufig verschiedene Hardwaregeräte benutzen, um ähnliche E/A-Funktionen auszuführen, und selbst dort, wo die Geräte ähnlich sind, können programmierbare E/A-Geräte verschieden programmiert sein. Außerdem können in den beiden Systemen die E/A-Geräteanschlüsse verschiedene Speicherzellen in ihren zugehörigen Adressenbereichen E/A-Steuerung belegen. Beispielsweise liegen die E/A-Anschlüsse im IBM-PC im Adressenbereich von 000H bis 3FFH, wogegen sie im Professionellen Wang-Computer, wie angegeben, an den Adressen 1000H bis 1FFFH liegen.
• Folglich werden E/A-Anforderungen, die von für ein erstes System geschriebenen Programmen erzeugt werden, wahrscheinlich ungültig sein, wenn diese Programme auf einem zweiten System ablaufen. Das zweite System muß daher die E/A-Struktur des ersten Systems hinsichtlich der programmerzeugten E/A- Anforderungen emulieren und wird dies vorzugsweise tun, ohne weitgehende oder grundsätzliche Änderungen seiner E/A-Struktur zu erfordern.
• In Fig. 5A und 5B ist der Mechanismus dargestellt, mit dem das erfindungsgemäße System die E/A-Struktur und die Funktionsvielfalt eines anderen Systems emuliert. Wie darin angegeben, umfaßt der Mechanismus einen E/A-Mechanismus für nicht maskierbare Unterbrechungen (IONMIM) 128, der seinerseits den im System bereits vorhandenen IM 124 aufweist, und einen E/A- Emulationsmechanismus (IOEM) 130. Wie nachstehend beschrieben, stellt der IONMIM 128 das Auftreten von "fremden" E/A- Anforderungen fest, das heißt, E/A-Anforderungen, die von anfänglich für ein anderes System geschriebenen Programmen erzeugt werden. Wie weiter unten beschrieben wird, werden E/A-Anforderungen außerhalb des Adressenbereiches 1000H bis 1FFFH als fremde E/A-Anforderungen betrachtet. Der IOEM 130 liefert Steuerroutinen, welche die E/A-Struktur des erfindungsgemäßen Systems so leiten, daß es die E/A-Struktur das anderen Systems emuliert.
• Es wird zuerst die Feststellung von fremden E/A-Anforderungen betrachtet. Wie weiter oben beschrieben, umfaßt die CPU 10 eine Ein-Ausgabe-Decodier-Logik (IODL) 29. Die IODL 29 überwacht im wesentlichen System-Ein-Ausgabe-Anforderungen und liefert entsprechende Steuersignalausgänge an den SC-Bus 18, die erstens angeben, ob eine E/A-Anforderung vorliegt, und zweitens, ob die E/A-Anforderung an eine gültige E/A-Anschlußadressen-Speicherstelle gerichtet ist.
• Unter Bezugnahme auf den IONMIM 128: Der IONMIM 128 umfaßt eine E/A-Detektor-Logik (IODET) 132, bei der Eingänge mit dem SC-Bus 18 und insbesondere mit den vorstehend beschriebenen Steuerausgängen der IODL 29 verbunden sind. Die IODET 132 spricht auf diese Steuersignale in der Weise an, daß sie bei Auftreten einer E/A-Anforderung, die nicht an eine gültige E/A-Anschlußadresse im erfindungsgemäßen System gerichtet ist, wenn es sich also um eine fremde E/A-Anforderung handelt, an den IM 124 des Systems eine nicht maskierbare Unterbrechung (NMI) sendet. Wie weiter oben beschrieben, liefert der IM 124 einen Unterbrechungs-Vektoradressen-Ausgang (IVA) an eine entsprechende Stelle in einer Unterbrechungs-Vektortabelle 134, die Vektoren oder Adressen enthält, welche die Speicherstellen entsprechender Unterbrechungs-Behandlungsroutinen (IHR) 136 identifizieren.
• Bei der Emulation eines anderen Systems durch das erfindungsgemäße System werden die IVT 134 und die IHR 136 des IM 124 zusätzlich mit den entsprechenden Vektoren und Routinen zum Steuern der Arbeitsweise des nachstehend beschriebenen IOEM 130 versorgt. Das Verständnis für die Programmierung des IM 124 und für die Erzeugung der zweckdienlichen Routinen zum Steuern des nachfolgenden Betriebs des IOEM 130 ergibt sich für den Fachmann aus der Lektüre der folgenden Beschreibung der Arbeitsweise des IOEM 130.
• Wie vorstehend beschrieben, stehen die E/A-Emulationsroutinen im IOEM 130 und werden von diesem an das System geliefert, und sie sind nach der Art der auszuführenden Operation in zwei Gruppen unterteilt. Die erste Gruppe besteht aus Leseoperations-Emulationsroutinen und ist in Lese-E/A-Emulationsroutinen (RIOER) 138 gespeichert, wogegen die zweite Gruppe aus Schreiboperations-Emulationsroutinen besteht und in Schreib-E/A-Emulationsroutinen (WIOER) 140 gespeichert ist. Wie weiter oben unter Bezugnahme auf IHR 136 beschrieben, sind die RIOER 138 und die WIOER 140 im allgemeinen in einem Teil des Systembereichs Programme/Daten, entweder in einem Speicher als geladener Code oder in einem ROM, gespeichert.
• Es sei darauf hingewiesen, daß, wie in Fig. 5A angegeben, die in den RIOER 138 und den WIOER 140 gespeicherten E/A-Emulationsroutinen je eine Lese-Defaultroutine (RDEF) 142 und eine Schreib-Defaultroutine (WDEF) 144 aufweisen. Diese Routinen sind vorgesehen für den Fall, daß bestimmte fremde E/A-Operationen erscheinen, die von den Emulationsroutinen in RIOER 138 und WIOER 40 nicht unterstützt werden können. Solche Anforderungen werden gewöhnlich wenig angetroffen, treten aber doch in bestimmten Anwendungsprogrammen auf. In diesen Fällen besteht die wesentliche Aufgabe der RDEF 142 und der WDEF 144 darin, die nicht unterstützten Anforderungen ohne weiteres und in solcher Weise zu beenden, daß die Systemarbeitsweise nicht in unerwünschtem Maße unterbrochen wird.
• Bei jeder zu emulierenden Operationsart, das heißt, Lese- oder Schreib-Operation, sind die auszuführenden Operationen in Operations"klassen" unterteilt, die beispielsweise ähnliche Merkmale besitzen, und die in RIOER 144 und WIOER 146 gespeicherten Routinen sind im allgemeinen auf diese Weise organisiert. Die Auswahl einer speziellen RIOER 144 oder WIOER 146 zum Emulieren einer speziellen fremden E/A-Operation durch sie erfordert die Identifizierung des Operationstyps, der Operationsklasse innerhalb dieses Typs, und die Identifizierung der speziellen entsprechenden Routine innerhalb dieser Klasse.
• Die Auswahl von E/A-Emulationsroutinen aus RIOER 138 und WIOER 140 als Antwort auf eine fremde E/A-Anforderung wird, wie oben beschrieben, durch in IHR 136 gespeicherte Routinen gesteuert. Die tatsächliche Routinewahl wird durch den von Lese-Abfertigungstabellen (RDT) 146 und Schreib-Abfertigungstabellen (WDT) 148 gebildeten Mechanismus und durch entsprechende Lese-Klassentabellen (RCT) 150 und Schreib-Klassentabellen (WCT) 152 mit Steuerung durch die von IHR 136 gelieferten Routinen ausgeführt. Die RDT 146 und RCT 150 werden zur Auswahl von Leseoperationsroutinen aus den in den RIOER 138 gespeicherten benutzt, wogegen die WDT 148 und WCT 152 zur Auswahl von Schreiboperationsroutinen aus denen in WIOER 140 gespeicherten benutzt werden.
• Wie nachstehend beschrieben, enthalten die RCT 150 und die WCT 152 je Lese-E/A-Emulationsroutinen-Zeiger (RIOERP) und Schreib-E/A-Emulationsroutinen-Zeiger (WIOERP) oder Adressen, welche die Speicherstellen der einzelnen in RIOER 138 und WIOER 140 gespeicherten Emulationsroutinen identifizieren und auswählen. Wie in Fig. 5B angegeben, die eine vereinfachte Darstellung der Innenstrukturen von RCT 150 und WCT 152 ist, sind die in RCT 150 und WCT 152 stehenden Zeiger in Klassen 154 unterteilt, die den Klassengruppen der Emulationsroutinen in RIOER 138 und WIOER 140 entsprechen. Jede Klasse 154 enthält die Zeiger, IOER 156, welche die Speicherstellen der einzelnen entsprechenden Emulationsroutinen in RIOER 138 und WIOER 140 identifizieren.
• Die in RCT 150 und WCT 152 stehenden Zeiger werden ihrerseits durch Adresseneingänge lokalisiert und angewählt, die zum Teil aus RDT 146 und WDT 148 und zum Teil aus bestimmten Registern des IOEM 130 kommen, welche Informationen blockieren und speichern, die sich auffremde E/A-Anforderungen beziehen. Wie weiter unten beschrieben wird, werden die in RDT 146 und WDT 148 gespeicherten und von dort an RCT 150 bzw. WCT 152 gelieferten Adressen als Indexadressen benutzt, um innerhalb RCT 150 oder WCT 152 die speziellen Klassen 154 anzuwählen, welche die auf die entsprechenden Emulationsroutinen in RIOER 138 und WIOER 140 verweisenden IOER enthalten. Die sich auf die fremde E/A-Anforderung beziehenden blockierten Informationen werden zum Teil für den Zugriff auf RDT 146 und WDT 148 zum Anwählen der darin gespeicherten zweckdienlichen Indexe, welche an RCT 150 oder WCT 152 zu liefern sind, und zum Teil als Verschiebeadresseneingang in RCT 150 und WCT 152 benutzt, um die einzelnen IOER innerhalb der entsprechenden Klassen 154 zu wählen, welche durch die Indexadressen aus RDT 146 oder WDT 148 angewählt wurden.
• Unter Bezugnahme auf die Register des IOEM 130 zum Blockieren und Speichern von fremde E/A-Anforderungen betreffenden Informationen: Ein IOEM 130 umfaßt ein E/A-Adressenregister (IOA) 158, das an den SA-Bus 14 angeschlossen ist, ein E/A- Datenregister (IOD) 160, das mit dem SD-Bus 16 verbunden ist, und ein E/A-Zustandsregister (IOS) 162, das mit dem SC-Bus 18 verbunden ist. Nach dem Starten einer fremden E/A-Anforderung wählt und startet der NMI-Ausgang aus IODET 132 in der oben beschriebenen Weise die E/A-Emulationsroutine aus IHR 136 zum Leiten der Arbeitsweise vom IOEM 130 und blockiert zur gleichen Zeit bestimmte, auf die Anforderung sich beziehende Informationen in IOA 158, IOD 160 und IOS 162. Insbesondere wird die angeforderte fremde E/A-Adresse im IOA 158 blockiert und, wenn sich die Anforderung auf eine E/A-Schreiboperation bezieht, werden die zu schreibenden Daten im IOD 160 gehalten. Die im IOS 162 gehaltene Zustandsinformation enthält die Angaben, daß die Anforderung erschienen ist, ob die Anforderung sich auf Lesen oder Schreiben bezieht, ob sie für einen E/A-Zugriff auf ein Byte oder ein Wort gilt, und im letzteren Fall, ob sich die Adresse an einer unregelmäßigen Adresse befindet.
• Als Antwort auf eine Unterbrechung für eine fremde E/A-Operation führt das System, wie zuvor ausgeführt, unter Bezugnahme auf den IM 124 des Systems eine Sicherung des Unterbrechungszustandes durch. Die daraus sich ergebende E/A-Emulationssteuerroutine aus IHR 136 liest dann die Adresseninformation der E/A-Anforderung aus IOA 158 und die Zustandsinformation aus IOS 162. Die Zustandsinformationen, die identifizieren, ob die angeforderte Operation eine Lese- oder Schreiboperation ist, und ein erster Teil der aus IOA 158 gelesenen Adresseninformationen werden als Adresseneingang in RDT 146 und WDT 148 benutzt, um den Index zu erlangen, der in RCT 150 oder WCT 152 die Klasse 154 identifiziert, welche den IOERP zur zweckdienlichen entsprechenden Emulationsroutine enthält, die in RIOER 138 oder WIOER 140 steht. In dieser Hinsicht wählt der Lese/Schreib-Zustandsinformationsteil der an die RDT 146 und die WDT 148 gegebenen Adresse, ob der entsprechende Index im Adressenbereich der RDT 146 oder der WDT 148 liegt.
• Der aus RDT 146 oder WDT 148 gelesene Index wird dann als erster Teil einer Adresse benutzt, mit der in RCT 150 bzw. WDT 152 die Klasse 154 angewählt wird, die den IOERP zur auszuführenden Emulationsroutine enthält. Der zweite Teil der in RCT 150 oder WDT 152 eingegebenen Adresse ist, wie weiter oben beschrieben, von einem zweiten Teil der aus IOA 158 gelesenen Adresseninformation gebildet. Dieser Teil des Adresseneingangs in RCT 150/WDT 152 wird effektiv als Relativzeiger, bezogen auf den Indexeingang, benutzt, um innerhalb der mit dem Indexteil der Adresse angewählten Klasse 154 die Speicherstelle des IOERP zur Emulationsroutine anzuwählen.
• Der angewählte IOERP wird dann von der aus IHR 136 bereitgestellten E/A-Emulationssteuerroutine zum Anwählen und Starten der entsprechenden Emulationsroutine aus den in RIOER 138 oder WIOER 140 stehenden benutzt. Die Emulationsroutine kann dann ihrerseits nach Bedarf auf die im IOS 162 gespeicherten Zustandsinformationen zugreifen, um die angeforderte fremde E/A-Operation entsprechend zu emulieren. Wenn sich die angeforderte Operation auf eine Datenschreiboperation bezog, wird die angewählte Emulationsroutine die im IOD 160 gehaltenen Daten in zweckdienlicher Weise lesen und übertragen.
• Nachdem die Einrichtungen beschrieben wurden, mit denen das erfindungsgemäße System die E/A-Struktur eines anderen Systems emuliert, werden nachfolgend die Einrichtungen beschrieben, mit denen das erfindungsgemäße System die Unterbrechungsstruktur dieses anderen Systems emuliert.
2. Emulation des Unterbrechungsmechanismus (Fig. 6)
• Wie zuvor beschrieben, gibt es in einem System des hier beschriebenen Typs zwei Klassen Unterbrechungsoperationen, nämlich Software- und Hardware-Unterbrechungen. Software-Unterbrechungen werden durch AP 116 oder Routinen des OS 120 ausgelöst, und Hardware-Unterbrechungen werden durch den Betrieb der die HS 118 bildenden Hardwarekomponenten gestartet. Beispiele von Hardware-Unterbrechungen sind u. a. von der Tastatur aus gestartete Tastatureingaben, E/A-Operationen an seriellen und parallelen Anschlüssen, Plattenoperationen und zeitlich festgelegte Reihenfolgen. Die Routinen aus IHR 136 zur Behandlung von Unterbrechungsoperationen funktionieren auf im wesentlichen derselben Detailebene wie die Routinen des BIOS 122 und werden gewöhnlich, wie in Fig. 5A für das Systembeispiel gemäß Fig. 1 und 2 dargestellt, als Teil der im BIOS 122 gespeicherten Routinen betrachtet.
• Die Behandlung von Software-Unterbrechungen, das heißt, das Abrufen oder Starten der entsprechenden Behandlungsroutinen für Software-Unterbrechungen, wird in derselben Weise durchgeführt wie das Aufrufen oder Starten der Routinen des BIOS 122. Das heißt, ein AP 116 oder eine Routine des BIOS 122 gibt eine Anforderung oder eine Anweisung aus, welche die entsprechende Unterbrechungs-Behandlungsroutine adressiert, die im MM 48 oder in einem ROM gespeichert ist. Die Emulation der Software-Unterbrechungsoperation eines anderen Systems wird dadurch, wie weiter oben beschrieben, zu einer Sache der Addition der entsprechenden Unterbrechungsbehandlungsroutinen zu dem das andere System emulierenden BIOS.
• Hardware-Unterbrechungen, die durch die HS 118 aufgerufen werden, werden über eine spezielle, zu diesem Zweck vorgesehene Logik ausgelöst und ergeben sich aus der Arbeitsweise der Komponenten der HS 118. Bei dem Systembeispiel gemäß Fig.
• 1, 2 und 5A, ist dieser Mechanismus von der PIC 66 und der NMIL 36 gebildet. Im wesentlichen empfangen die PIC 66 und die NMIL 36 zu diesem Zweck spezielle Steuersignaleingänge von den verschiedenen Komponenten der HS 118. Wird durch einen solchen Unterbrechungseingang das Auftreten einer Unterbrechungsbedingung in einer Komponente der HS 118 der PIC 66 oder der NMIL 36 angezeigt, gibt PIC 66 oder NMIL 36 eine entsprechende Adresse (IVA) ab, die eine entsprechende Stelle in einer Unterbrechungs-Vektortabelle (IVT 134) adressiert. Die IVT 134 enthält und gibt ihrerseits Vektoren oder Adressen ab, welche die Stelle der entsprechenden Unterbrechungsbehandlungsroutinen in IHR 136 identifizieren.
• Wie weiter oben beschrieben, können die interne Hardwarestruktur und die Arbeitsweisen von zwei Systemen in hohem Maße verschieden sein, und folglich trifft dies auch auf die Arbeitsweisen der Hardware-Unterbrechungsmechanismen der Systeme zu. Folglich wird ein Anwendungsprogramm, das für ein System geschrieben wurde und mit dem Unterbrechungsmechanismus dieses Systems in direkter Verbindung steht, auf einem anderen System höchstwahrscheinlich nicht ordnungsgemäß ablaufen. Beispielsweise kann es bei einem speziellen Anwendungsprogramm notwendig sein, daß der Benutzer bestimmte Informationen mittels der Tastatur eingibt, und daß es erwartet, daß die Hardware-Unterbrechungsroutinen, welche Tastatureingabenunterbrechungen behandeln, die Informationen in einer besonderen Weise darstellen.
• Wie weiter oben beschrieben, kann die Emulation des Software- Unterbrechungsmechanismus eines zweiten Systems durch ein erstes System durch das BIOS des ersten Systems durchgeführt werden, welches das zweite System emuliert; dieser Vorgang ist dem Fachmann gut bekannt. Die Emulation eines Hardware- Unterbrechungsmechanismus eines zweiten Systems durch ein erstes System ist jedoch hinsichtlich der Schwierigkeiten der Emulation der E/A-Struktur des zweiten Systems ähnlich.
• Fig. 6 zeigt eine vereinfachte Darstellung der Einrichtungen, mit denen das erfindungsgemäße System den Hardware-Unterbrechungsmechanismus eines zweiten Systems emuliert. Darin angegeben ist der Hardware-Unterbrechungsmechanismus des erfindungsgemäßen Systems mit PIC 66, NMIL 36, IVT 134 und IHR 136, deren Arbeitsweise weiter oben beschrieben wurde.
• Im Hardware-Unterbrechungsemulations-Mechanismus des erfindungsgemäßen Systems enthalten die IHR 136 in ihren Software- Unterbrechungsserviceroutinen (SISR 164) eine zusätzliche Gruppe Hardware-Unterbrechungsemulationsroutinen (HIER) 166, welche die Arbeitsweise des Hardware-Unterbrechungsmechanismus des zweiten Systems emuliert. Die IVT 134 enthält entsprechend zusätzliche HIER-Vektoren (HIERV) 168 zu den HIER- Routinen 166, und die Hardware-Unterbrechungsserviceroutinen (HISR) 170 der IHR 136 sind so geändert, daß sie Verweise auf die HIERV 166 enthalten.
• Die HIER 166, HIERV 168 und die geänderten HISR 170 werden aktiviert, wenn das System das zweite System emuliert. Die Generierung einer Hardware-Unterbrechung im System führt dadurch dazu, daß die entsprechende HISR 170 über den zugehörigen HIERV 168 die entsprechende, in den SISR 164 gespeicherte HIER 166 aufruft. Die HIER 166, HIERV 168 und die geänderten HISR 170 führen dadurch effektiv Hardware-Unterbrechungsoperationen in derselben Weise aus wie die oben beschriebenen Software-Unterbrechungsoperationen.
• Es sei darauf hingewiesen, daß die HIER 166 nicht auf reine Emulationsroutinen beschränkt sind, sondern ferner andere Routinen einschließen oder durch solche ersetzt sein können, die zusätzliche Funktionsfähigkeiten oder erhöhte Leistung bringen. Auch hier sind die Auslegung und die Arbeitsweise von Hardware-Unterbrechungs-Emulationsroutinen denen von Software-Unterbrechungsroutinen ähnlich, und weil sie dem Fachmann bekannt sind, werden hier keine weiteren Einzelheiten dazu beschrieben.
• Für den Fachmann leuchtet ein, daß die vorliegende Erfindung in noch anderen speziellen Formen ausgeführt werden kann, ohne daß von ihrem Wesen oder ihren wesentlichen Merkmalen abgewichen wird. Die vorliegenden Ausführungsformen sind somit in jeder Hinsicht als erläuternd und nicht als einschränkend zu betrachten, wobei der Umfang der Erfindung eher durch die beigefügten Patentansprüche als durch die obenstehende Beschreibung angegeben ist, und daher sollen alle Änderungen, die sich innerhalb des Bedeutungs- und Äquivalenzumfanges der Patentansprüche ergeben, abgedeckt sein.

Claims (10)

1. Einrichtung zum Emulieren der Ein-Ausgabe-Struktur eines zweiten Datenverarbeitungssystems in einem ersten Datenverarbeitungssystem mit einer Einrichtung zum Speichern von Programmen, einer auf die Programme oder auf Verarbeitungsdaten ansprechende Zentraleinheit, und einer auf die Programme ansprechenden Ein-Ausgabe-Struktur (12) zur Übertragung von Informationen zwischen dem System und externen Geräten, dadurch gekennzeichnet, daß

- die Ein-Ausgabe-Struktur (130, 138, 140) des ersten Systems Anschlußstellen (48, 70, 72, 74, 76, 78) aufweist, die einen ersten Bereich des Systemadressierungsbereichs einnehmen,

- die Ein-Ausgabe-Struktur (12) des zweiten Systems Anschlüsse aufweist, die einen vom ersten Bereich des Systemadressierungsbereichs verschiedenen zweiten Bereich des Systemadressierungsbereichs einnehmen,

- eine Einrichtung (132) zur Erkennung von Ein- Ausgabeanforderungen, die Adressen von Ein-Ausgabe- Anschlüssen mit dem ersten Bereich von Anschlußadressen zu vergleichen und ein Bereichsausgangssignal bereitzustellen vermag, das einen ersten Zustand hat, wenn die Anschlußadresse einer Ein-Ausgabeanforderung im ersten Bereich des Systemadressierungsbereichs liegt, und einen zweiten Zustand hat, wenn die Anschlußadresse einer Ein- Ausgabeanforderung nicht im ersten Bereich des Systemadressierungsbereichs liegt,

- eine Unterbrechungseinrichtung (128) in Antwort auf das Auftreten einer Ein-Ausgabeanforderung und auf den zweiten Zustand des Bereichsausgangssignals daraufhin ein nicht maskierbares Unterbrechungssignal zu generieren vermag, und

- Emulationsroutinen-Einrichtungen (158, 160, 162, 146, 148, 150, 152), die Emulationsroutinen zu speichern vermögen und auf das nicht maskierbare Unterbrechungssignal ansprechen, das bei Auftreten einer Ein-Ausgabeanforderung mit einer Anschlußadresse im zweiten Bereich des Systemadressierungsbereichs generiert wird, wobei die Emulationsroutinen-Einrichtungen in Antwort auf das nicht maskierbare Unterbrechungssignal eine entsprechende Emulationsroutine zur Ausführung der Ein-Ausgabeanforderung des zweiten Systems aufzurufen und auszulösen vermögen.

2. Emulations-Einrichtung nach Anspruch 1, bei der die Unterbrechungs-Einrichtung (128) auf den Betrieb der Anforderungserkennungseinrichtung (132) ansprechende Einrichtungen (134, 136) aufweist, die das Auftreten von Ein- Ausgabeanforderungen festzustellen vermögen, welche nicht von entsprechenden Angaben zu Anschlußadressen in dem von den Ein-Ausgabegeräten des Systems eingenommenen Bereich des Adressierungsbereichs begleitet sind, und die entsprechenden nicht maskierbaren Unterbrechungsausgänge bei Auftreten jeder solchen fremden Ein-Ausgabeanforderung bereitzustellen vermögen.

3. Emulations-Einrichtung nach Anspruch 1, bei der die Emulationsroutinen-Einrichtungen umfassen:

- eine auf die nicht maskierbaren Unterbrechungen ansprechende Einrichtung (158, 160, 162) zum Speichern von Informationen, die sich auf die fremden Ein- Ausgabeanforderungen beziehen,

- wobei die Einrichtungen (146, 148, 150, 152) zum Aufrufen und Auslösen von Emulationsroutinen ferner beim Aufrufen der entsprechenden Ein-Ausgabe-Emulationsroutinen auf die gespeicherten Informationen über Ein- Ausgabeanforderungen ansprechen.

4. Emulations-Einrichtung nach Anspruch 3, bei der die Einrichtung zum Speichern von Anforderungs-Informationen umfaßt

- ein erstes Register (158) zum Speichern von Anschlußadressen von fremden Ein-Ausgabeanforderungen, und

- ein zweites Register (162) zum Speichern von fremde Ein- Ausgabeanforderungen betreffenden Statusinformationen, einschließlich einer Angabe, ob eine fremde Ein- Ausgabeanforderung eine Lese- oder eine Schreiboperation betrifft.

5. Emulations-Einrichtung nach Anspruch 4, bei der die Einrichtung zum Speichern von Anforderungs-Informationen ferner umfaßt:

ein drittes Register (160) zum Speichern von Daten, die zu schreiben sind, wenn eine Ein-Ausgabeanforderung eine Schreiboperation betrifft.

6. Emulations-Einrichtung nach Anspruch 1, bei der die Aufruf- und Auslöse-Einrichtung umfaßt:

- Klassentabellen-Einrichtungen (150, 152) zum Speichern von Adressen von Emulationsroutinen, die im Routinespeicher gespeichert sind, wobei die in den Klassentabellen-Einrichtungen (150, 152) gespeicherten Adressen von Emulationsroutinen klassenweise strukturiert sind, dabei jede Klasse die Adressen einer entsprechenden Gruppe fremder Ein-Ausgabeanforderungen enthält, und

- Abfertigungstabellen-Einrichtungen (146, 148) zum Speichern von Indexadressen, wobei jede Indexadresse einer Gruppe von Emulationsroutinen entspricht und die Position in den Klassentabellen-Einrichtungen (150, 152) der entsprechenden Klasse von Emulationsroutinenadressen identifiziert,

wobei die Abfertigungstabellen-Einrichtungen (146, 148) auf einen ersten Teil jeder fremden Ein-Ausgabeanforderung durch Bereitstellen einer entsprechenden Indexadresse der entsprechenden, in den Klassentabellen-Einrichtungen (150, 152) gespeicherten Adressenklasse ansprechen, und die Klassentabellen-Einrichtungen (150, 152) auf einen zweiten Teil jeder fremden Ein-Ausgabeanforderung und auf die entsprechende Indexadresse durch Bereitstellen einer entsprechenden Emulationsroutineadresse ansprechen, um die entsprechende Emulationsroutine aufzurufen und ihre Ausführung auszulösen.

7. Emulations-Einrichtung nach Anspruch 6, bei der

- jede fremde Ein-Ausgabeanforderung eine Anschlußadresse enthält, welche die Position eines entsprechenden Ein- Ausgabegerätes innerhalb des Adressierungsbereiches des anderen Systems identifiziert und dem Typ der angeforderten Ein-Ausgabeoperation entspricht,

- die Einrichtung zum Speichern von Anforderungs- Informationen ein erstes Register (158) zum Speichern von Anschlußadressen für fremde Ein-Ausgabeanforderungen umfaßt und

- der erste Teil einer fremden Ein-Ausgabeanforderung ein erster Teil der Anforderungs-Anschlußadresse ist und

- der zweite Teil der fremden Ein-Ausgabeanforderung ein zweiter Teil der Anforderungs-Anschlußadresse ist.

8. Emulations-Einrichtung nach Anspruch 7, bei der

- die Einrichtung zum Speichern von Anforderungs- Informationen ferner ein zweites Register (162) zum Speichern von fremde Ein-Ausgabeanforderungen betreffenden Statusinformationen, einschließlich einer Angabe umfaßt, ob eine fremde Ein-Ausgabeanforderung eine Lese- oder eine Schreiboperation betrifft, und

- die Index-Einrichtung (146, 148) ferner auf die Statusinformation, welche angibt, ob eine Anforderung eine Lese- oder eine Schreiboperation betrifft, durch Bereitstellen der entsprechenden Indexadresse anspricht.

9. Emulations-Einrichtung nach Anspruch 1, bei der die Emulationsroutinen-Einrichtung ferner umfaßt:

- Standardroutinen, die fremden Ein-Ausgabeanforderungen entsprechen, welche keine entsprechenden Emulationsroutinen haben, wobei jede Standardroutine die entsprechende Ein- Ausgabeanforderungs-Operation beendet, dabei die Aufruf- und Auslöse-Einrichtung auf Anforderungen, die keine entsprechenden Emulationsroutinen haben, durch Aufrufen und Ausführen einer entsprechenden Standardroutine antwortet.

10. Einrichtung zum Emulieren der Ein-Ausgabestruktur eines zweiten Systems gemäß Anspruch 1, bei der die Unterbrechungs-Einrichtung (128) umfaßt:

- eine erste Unterbrechungs-Einrichtung (164), die auf erste Unterbrechungsanforderungen, die von den Systembetrieb steuernden Programmen kommen, durch Bereitstellen entsprechender erster Unterbrechungsbehandlungsroutinen zum Steuern entsprechender erster Unterbrechungsbehandlungsoperationen des Systems antwortet, und

- eine zweite Unterbrechungsbehandlungs-Einrichtung (170), die auf zweite Unterbrechungsanforderungen, die von den Hardwareelementen des Systems kommen, durch Bereitstellen entsprechender zweiter Unterbrechungsbehandlungsroutinen zum Steuern entsprechender zweiter Unterbrechungsbehandlungsoperationen des Systems antwortet, ferner gekennzeichnet durch

- eine Einrichtung in der Unterbrechungs-Einrichtung (128) zum Emulieren der zweiten Unterbrechungsbehandlungseinrichtung des zweiten Systems, einschließlich

einer Einrichtung in der ersten Unterbrechungs-Einrichtung (164) zum Speichern von Unterbrechungsemulationsroutinen zum Steuern der Systemoperation, um die zweiten Unterbrechungsbehandlungsoperationen des zweiten Systems zu emulieren,

einer Einrichtung in der zweiten Unterbrechungs-Einrichtung (170) zum Feststellen zweiter Unterbrechungsanforderungen sowohl des ersten als auch des zweiten Systems, und

- eine Einrichtung (146, 148) zum Bereitstellen eines Betriebsartensignals, das anzeigt, wenn das erste System das zweite System emulieren soll, wobei die zweite Unterbrechungs-Einrichtung (170)

- auf das Betriebsartensignal und auf zweite Unterbrechungsanforderungen des ersten Systems durch Bereitstellen entsprechender zweiter Unterbrechungsbehandlungsroutinen des ersten Systems zum Steuern entsprechender zweiter Unterbrechungsbehandlungsoperationen des Systems antwortet, wenn das erste System das zweite System nicht emuliert, und

- auf das Betriebsartensignal und auf zweite Unterbrechungsanforderungen des ersten Systems durch Bereitstellen entsprechender zweiter Unterbrechungsbehandlungsroutinen des zweiten Systems zum Steuern entsprechender zweiter Unterbrechungsbehandlungsoperationen des Systems antwortet, wenn das erste System das zweite System emuliert.