DE69513463T2 - Einausgabe/ausgabe emulationssystem - Google Patents

Description

• Die Erfindung umfaßt auch ein Verfahren zum Testen oder Auswerten von Software auf einem simulierten bestimmten Prozessor mit den folgenden Schritten, nämlich Ausführen des Programms auf einem existierenden Prozessor, Identifizieren von Programmteilen, welche die Bearbeitung durch den bestimmten Prozessor benötigen, Zuführen dieser Programmteile an den Simulator und Zurückführen jedweder resultierender Simulationsantworten an den existierenden Prozessor.
• Es wird somit deutlich, daß die vorliegende Erfindung eine vollständig neue Annäherung einsetzt, indem ein allgemein verwendbarer und existierender Prozessor kombiniert wird mit einem Simulator, wobei der letztere nur konfiguriert ist, diejenigen Zwischenwirkungen und Antworten zu simulieren, die für den simulierten Prozessor spezifisch sind, wobei alle anderen Teile des Programms durch den üblichen Prozessor ausgeführt werden.
• Diese neue Annäherung zum Problem reduziert nicht nur signifikant den Aufwand und die Zeit, die erforderlich sind, um den Simulator zu kreieren, sondern sie ermöglicht es auch, einen Simulator zu kreieren allein mit der Kenntnis der Aufbaukriterien des neuen Prozessors, wobei die interne Architektur des Gerätes irrelevant ist.
• Diese Annäherung ergibt sich aus der Realisation, daß eine substantielle Anzahl der Funktionen, die von einem Prozessor durchgeführt werden, wenn ein Programm ausgeführt wird, nicht spezifisch ist, d. h. es kommt nicht darauf an, welcher Prozessor eingesetzt wird. Darüber hinaus können die Schritte, die spezifisch sind, leicht identifiziert werden, da sie alle Zwischenreaktionen mit peripherer Hardware involvieren, beispielsweise Keyboards, Mausschaltungen und Monitoren. Außerdem liegt ein Vorteil dieser Näherung darin, daß es möglich ist, die simulierten Zwischenwirkungen in einem hohen Sprachniveau auszuführen.
• Somit sind bei einer bevorzugten Ausführungsform die identifizierten Teile des Programms diejenigen, welche eine Interaktion des bestimmten Prozessors mit zugeordneter Peripherie-Hardware bewirken. In vielen Programmen können diese identifizierten Teile Unterprogramme sein, da es übliche Programmierpraxis ist, eine Gruppe von Unterprogrammen vorzusehen, um die Interaktionen zwischen einem Prozessor und einer Peripherie-Hardware zu bewirken. Typischerweise sind diese identifizierten Teile Software oder periphere Treiber.
• Wenn das Programm mit solchen Unterprogrammen konfiguriert ist, kann das System darüber hinaus einen Kreuzkompiler zum Kompilieren existierender Unterprogramme vor deren Zuführung über den BUS in ein Format oder einen Code umfassen, der geeignet ist für die Interaktion mit dem bestimmten Prozessor.
• Vorzugsweise simuliert der Simulator nur die Antworten der Interaktionen mit den identifizierten Teilen des Programms. Somit kann der Simulator ein Prozessor oder ein Softwaremodell sein, welches programmiert ist, daß es anspricht in Übereinstimmung mit der Antwort des Aufbaues des bestimmten Prozessors, oder es kann der Hardware überlassen bleiben, die ausgelegt ist, solche Antworten zur Verfügung zu stellen.
• Die Erfindung kann auf unterschiedliche Weise zur Ausführung gelangen und spezielle Ausführungsformen sollen nun beschrieben werden, lediglich beispielhaft unter Bezugnahme auf die beigefügten Zeichnungen, die eine schematische Repräsentation des Systems darstellen.
• Somit umfaßt das System 10 einen Computer 11 mit einem Softwareeingang 12 und einem Prozessor 13 sowie einen bidirektionalen BUS 14 und einen Simulator 15.
• Wie bereits angegeben wurde, ist der Simulator 15 so ausgelegt, daß er einen Code oder Programmteile empfängt, die mit der Peripherie-Hardware zusammenwirken müssen, welche mit dem simulierten Prozessor assoziiert ist und Aufbauantworten zur Verfügung stellen, die durch den aktuellen Prozessor entwickelt würden, wenn er einen solchen Code oder ein Programmteil bearbeitet haben würde. Dieser Simulator 15 kann in der Form eines Computermodells vorliegen oder es kann eine Hardware-Blackbox sein, die die unterschiedlichen Prozessor- BUS-Zyklen zu emulieren vermag, in Abhängigkeit von den über den Kommunikationskanal gegebenen Nachrichten und die die Änderungen an den Prozessor- Interfacesignalen, d. h. den Stiften, zurück berichten kann.
• Diese Form des Simulators ist möglich aufgrund der Erkenntnis, daß der Prozessor aufgespalten werden kann in zwei getrennte Teile, nämlich die eigentliche Prozessorschaltung (normalerweise der Prozessor, einiges RAM und ROM sowie zugeordnete logische Schaltung, ohne die sich der Prozessor nicht betreiben ließ) sowie die Peripherschaltung, die eingesetzt wird, um das Prozessorsystem einer speziellen Funktion zuzuführen.
• Das Softwareprogramm, welches aufgebaut ist, daß es an dem speziellen oder Zielprozessor oder dem Prozessorsystem arbeitet, muß einige Teile des Codes so geschrieben enthalten, daß es speziell mit der Peripherie-Hardware zusammenwirkt. Wenn dieses Programm in einer Hochsprache geschrieben ist, kann es kompiliert werden, daß es auf vielen unterschiedlichen Computersystemen oder Prozessorsystemen läuft. Nur der Code, der den Peripherischaltungen oder der Hardware zugeordnet ist, verhindert, daß das Programm voll funktional ist an den unterschiedlichen Zielprozessoren oder -prozessorsystemen.
• Kreuzkompiliertechniken machen es möglich, daß der Code, der den Peripherieschaltungen oder der Hardware zugeordnet ist, ersetzt werden kann durch einen äquivalenten alternativen Code zur Kompilierzeit. Der alternative Code bewirkt an Stelle der direkten Zwischenwirkung mit der Hardware, daß eine Hochniveaunachricht zum bidirektionalen BUS gesandt wird, welcher die Software mit dem Simulator 15 verbindet. Eine Entfernung des Codes, der sich direkt auf die Hardwareperipheriegeräte bezieht, macht es möglich, daß das verbleibende Programm an jedem Allzweckcomputer ausgeführt werden kann, für welchen ein Compiler existiert.
• Die "Blackbox" oder der Simulator 15, welcher den Prozessor in dem Prozessorsystem ersetzt, spricht auf die auf dem Prozessorzyklus basierenden Nachrichten von dem Kommunikationskanal 14 an und übersetzt diese in eine Emulation der Antworten des bestimmten Prozessors. Es wird kein Versuch gemacht, die internen Arbeiten des bestimmten Prozessors zu emulieren oder modellieren.
• Die Wirkung ist, daß das Softwarerprogramm auf dem Allzweckcomputer 13 läuft bis es auf den Code trifft, der mit der Peripherie-Hardware zusammenarbeitet. Nur für diesen Abschnitt des Codes wird der Simulator 15 aktiviert und spricht an, als wäre der bestimmte Prozessor in der Schaltung.
• Dies macht es möglich, daß Software aufgebaut und ausgeführt werden kann, bevor das bestimmte Prozessorsystem fertig ist. Wenn der bestimmte Prozessor als ein Computermodell repräsentiert wird, kann eine Entfernung des Gesamtaufbaues der ausführenden Teil des Softwareprogramms, welches nicht mit der Peripherieschaltung von der Computersimulation zusammenwirkt, merklich die verstrichene Zeit reduzieren, die erforderlich ist, um das Softwareprogramm zu verifizieren und zum Laufen zu bringen, wie auch die Zwischenwirkung des Softwareprogramms und der Peripherieschaltung. Es ist keine detaillierte Darstellung des bestimmten Prozessors für diese Arbeitstechnik erforderlich.
• Bei Softwareprogrammen, die in einer Hochsprache geschrieben sind, wird häufig ein Programmierstil eingesetzt, der auf Unterprogrammen basiert. Ein Unterprogramm spezifiziert eine Gruppe von Wirkungen, die vielfach auszuführen sind unter vielen unterschiedlichen Umständen. Das Aufrufen des Unterprogramms macht es dem Programmierer möglich, daß er sich darauf konzentrieren kann, was das Programm ausführen soll, anstatt sich um die Mechanismen zu kümmern, die erforderlich sind, um die Wirkungen zur Ausführung zu bringen.
• Bei Softwareprogrammen, die mit der Peripherie-Hardware zusammenwirken, ist es bei einer Anzahl von Unterprogrammen normal, daß sie geschrieben werden, um die detaillierte Zwischenwirkung mit der Peripherie-Hardware auszuführen. Der Softwareprogrammierer schreibt sein Programm, welches mit der Peripherie- Hardware zusammenwirkt, unter Einsatz der Unterprogramme. Dies kann die Komplexität des Programmes signifikant reduzieren.
• Bei der Bearbeitung des Programms für dessen Ausführung übersetzt ein Kompilierverfahren das Hochsprachprogramm in Binärsymbole, die nur für einen besonderen Prozessortyp geeignet sind. Unterschiedliche Kompiler sind erforderlich für unterschiedliche Prozessortypen. Das Kompilierverfahren umfaßt ein Übersetzen der Programm-Module in die entsprechende Binärrepräsentation, worauf dann die unterschiedlichen Binärmodule aneinander gehängt werden zur Bildung eines vollständig ausführbaren Programmes.
• Die vorliegende Erfindung gestattet es, daß ein neues Programm-Modul geschrieben wird, parallel zum Programm-Modul, welches die Unterprogramme enthält, die mit der Peripherieschaltung zusammenwirken. Die Namen und Schnittstellen für die Unterprogramme in jedem Modul sind die gleichen. Die Betriebsweisen, die in den Unterprogrammen spezifiziert sind, sind verschieden. Die Ausführung der neuen Unterprogramme bewirkt, daß eine oder mehrere, auf dem Prozessorzyklus basierende, Nachrichten zum Kommunikationskanal geschickt werden. Für einige dieser Prozessorzyklen kann eine Antwort von dem Kanal 14 zurückerwartet werden.
• Diese neue äquivalente Modul kann in das Programm im Kopilierstadium eingebracht werden anstelle der Unterprogramme, die direkt mit der Peripherieschaltung zusammenwirken.
• Eine Entfernung des für die Peripherieschaltung oder hardwarespeziellen Codes macht es möglich, daß das Softwareprogramm an jedem Computersystem ausgeführt werden kann, für welches ein Kompiler verfügbar ist.
• Die neuen Unterprogramme, die nun in das Softwareprogramm eingefügt werden, wirken statt dessen mit dem Kommunikationskanal zusammen. Es ist dem Softwareprogramm nicht möglich auszusagen, ob die Peripherieschaltung in dem Computer existiert, an welchem die Software zur Ausführung kommt, da alle Instruktionen, die sich direkt auf die Peripherieschaltung beziehen, nur in den Unterprogrammen enthalten sind.
• Wenn es erforderlich ist, asynchrone Unterbrechungen zu handhaben, ist ein weiterer Kommunikationskanal 16 von dem Simulator 15 zum Computer 11 vorgesehen.
• Asynchrone Unterbrechungen, die an dem Simulator 15 ankommen, können gehandhabt werden durch die Hinzufügung des weiteren Kommunikationskanals 16, der eine Unterbrechungsnachricht von dem Simulator 15 zurück zum Computer 11 führt. Es kann dafür Sorge getragen werden, daß die Abgabe dieser Nachricht eine Softwareunterbrechung in dem Softwareprogramm bewirkt. Somit können Unterbrechungssignale, die an dem Simulator 15 ankommen, direkt dem Softwareprogramm, welches zu handhaben ist, zugeführt werden durch ein Unterbrechungssteuerprogramm, welches in das Benutzerprogramm hinein geschrieben ist.
• Aufgrund der asynchronen Natur von Unterbrechungen ist es wichtig, die richtige Polarisation der Unterbrechungsnachrichten gegenüber normalen Nachrichten sicherzustellen (identifizierter Programmteil). Ein einfaches Verfahren, die Priorisierung zu bewerkstelligen, liegt darin, die Unterbrechungspriorität jeder Nachricht anzuhängen und getrennte Schlangen (FIFOs/Silospeicher) für Nachrichten aufrecht zu erhalten, die bei den unterschiedlichen Unterbrechungsniveaus weitergeleitet werden. Der Simulator 15 nimmt jeweils die erste verfügbare Instruktion von der höchsten Prioritätsschlange auf. Diese Technik gestattet es, daß der völlig unterbrechungsgetriebene Code in korrekten Schritten ausgeführt wird zwischen dem Simulator 15 und dem Softwareprogramm. Einrichtungen 17 bzw. 8 sind vorgesehen für die Priorisierung und für die Zurverfügungstellung der FIFO-Steuerung.

Claims (14)

1. System zum Ausführen eines Softwareprogramms, folgendes umfassend, einen Simulator zum Simulieren eines bestimmten Prozessors; eine Verarbeitungseinrichtung zum Ausführen der nicht spezifischen Teile des Programms mit Mitteln zum Identifizieren derjenigen Teile des Programms, welche die Ausführung durch den bestimmten Prozessor benötigen; und einen bidirektionalen BUS oder einen anderen Kommunikationskanal, zum Zuführen der identifizierten Programmteile an den Simulator und zum Zurückführen jeder sich ergebender Antwort an die Verarbeitungseinrichtung.

2. System nach Anspruch 1, dadurch gekennzeichnet, daß die identifizierten Teile des Programms diejenigen sind, welche eine Interaktion des bestimmten Prozessors mit zugeordneter Peripherie-Hardware bewirken.

3. System nach Anspruch 1 oder 2, dadurch gekennzeichnet, daß die Identifizierten Teile des Programms Unterprogramme sind.

4. System nach Anspruch 3, dadurch gekennzeichnet, daß dieses ferner folgendes aufweist, einen Kreuzkompiler, zum Kompilieren existierender Unterprogramme vor deren Zuführung über den BUS in ein Format oder einen Code, welcher zur Interaktion mit dem bestimmten Prozessor geeignet ist.

5. System nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß die identifizierten Teile des Programms Treiber umfassen.

6. System nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß die identifizierten Teile des Programms bei Zuführung an den Simulator in einer Hochsprache vorliegen.

7. System nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß der Simulator nur die Antwort auf Interaktionen mit den identifizierten Teilen des Programms simuliert.

8. System nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß der Simulator ein Prozessor ist, welcher derart programmiert ist, daß er gemäß der Antwort des Aufbaus des bestimmten Prozessors antwortet.

9. System nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, daß der Simulator ein anwendungsspezifischer Hardwaresimulator ist.

10. System nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß dieses ferner folgendes umfaßt, einen Kommunikationskanal zwischen dem Simulator und der Verarbeitungseinrichtung zum Abwickeln von asynchronen Interrupts.

11. System nach Anspruch 10, dadurch gekennzeichnet, daß die Interrupts eine höhere Priorität als die anderen identifizierten Programmteile erhalten.

12. System nach Anspruch 10 oder 11, dadurch gekennzeichnet, daß dieses ferner folgendes umfaßt, Mittel zum Zuweisen einer Priorität an jeden identifizierten Programmteil.

13. System nach Anspruch 12, dadurch gekennzeichnet, daß dieses ferner folgendes umfaßt, eine FIFO-Datenverarbeitungseinrichtung (First In First Out) für jeden Interruptlevel.

14. Verfahren zum Testen oder Auswerten von Software auf einem simulierten bestimmten Prozessor mit folgenden Schritten, Ausführen des Programms auf einem existierenden Prozessor, Identifizieren von Programmteilen, welche die Verarbeitung durch den bestimmten Prozessor benötigen, Zuführen dieser Programmteile an den Simulator und Zurückführen jedweder resultierender Simulationsantworten an den existierenden Prozessor.

Die vorliegende Erfindung bezieht sich auf ein System sowie ein Verfahren zum Ausführen eines Softwareprogramms.

Es wird in steigendem Maße üblich, für Prozessorhersteller die Auslegungskriterien für einen neuen Prozessor eine beträchtliche Zeit, bevor der Prozessor in Hardwareform verfügbar ist, freizugeben, und insbesondere bevor die interne Schaltung des Prozessor bekannt ist. (Der Begriff Prozessor umfaßt Mikroprozessoren, Digitalsignalprozessoren, Mikrocodeprozessoren und jede andere programmierbare auf Sequenzen basierende Digitalschaltung.) Ein Beispiel ist PENTIUM (eingetragenes Warenzeichen) von Intel. Softwareprogrammierer bemühen sich offensichtlich sehr, Software verfügbar zu halten für derartige neue Prozessoren, sobald Geräte, in welchen diese eingebaut sind, auf dem Markt erscheinen. In gleicher Weise möchten Hardwarehersteller gerne wissen, ob sie den neuen Prozessor mit einer speziellen Software und peripherer Hardware einsetzen können. Versuche, Prozessoren zu simulieren, sind ausgeführt worden, aber diese sind sehr beschränkt hinsichtlich ihrer Anwendbarkeit und neigen insbesondere dazu, ein Wissen des inneren Aufbaus des Prozessors erforderlich zu machen, bevor irgend welche Schritte unternommen werden können. Es kann auch erforderlich sein, einen Kompiler für diesen speziellen Prozessor zu kreieren.

Unter einem Gesichtspunkt besteht die Erfindung aus einem System zum Ausführen eines Softwareprogramms mit einem Simulator zum Simulieren eines speziellen Prozessors, einer Bearbeitungseinrichtung zum Ausführen der nichtspezifischen Teile des Programms mit Mitteln zum Identifizieren derjenigen Teile des Programms, welche die Ausführung durch den bestimmten Prozessor benötigen, sowie einem bidirektionalen BUS oder einem anderen Kommunikationskanal zum Zuführen der identifizierten Programmteile an den Simulator und zum Zuführen jeder sich ergebenden Antwort an die Bearbeitungseinrichtung.