DE102005003667B4

DE102005003667B4 - Emulator und Verfahren zur Behandlung asynchroner Unterbrechungen bei einer Emulation

Info

Publication number: DE102005003667B4
Application number: DE200510003667
Authority: DE
Inventors: Andreas Stotz
Original assignee: Fujitsu Technology Solutions GmbH
Current assignee: Fujitsu Technology Solutions GmbH
Priority date: 2005-01-26
Filing date: 2005-01-26
Publication date: 2008-06-19
Anticipated expiration: 2025-01-27
Also published as: DE102005003667A1

Abstract

Verfahren zur Behandlung von asynchronen Unterbrechungen bei einer Emulation eines für einen Ursprungsprozessor erstellten Programms (400) auf einem Zielprozessor (100) durch einen Emulator (300),
bei dem
– das Programm (400) dynamisch in Objektcode (330) für den Zielprozessor (100) übersetzt wird und der Objektcode (330) gespeichert wird,
– der Objektcode (330) durch den Zielprozessor (100) ausgeführt wird,
– beim Auftreten einer Aufforderung zu einer asynchronen Unterbrechung (101), der eine dem Emulator (300) vorgegebene Unterbrechungsroutine (210) zur Ausführung zugeordnet ist, während des Ausführens des Objektcodes (330) die Ausführung des dynamisch übersetzten Objektcodes (330) unterbrochen wird, im Objektcode (330) ein Haltepunkt (331) gesetzt wird, wobei der Haltepunkt (331) ein Befehl im Objektcode (330) ist, bei dessen Abarbeitung durch den Zielprozessor (100) eine Aufforderung zu einer synchronen Unterbrechung (102) hervorgerufen wird, und die Ausführung des Objektcodes (330) fortgesetzt wird und,
– falls nachfolgend während des Ausführens des Objektcodes...

Description

Die Erfindung betrifft ein Verfahren zur Behandlung von asynchronen Unterbrechungen bei einer Emulation eines für einen Ursprungsprozessor erstellten Programms auf einem Zielprozessor. Die Erfindung betrifft weiterhin einen Emulator, der zur Durchführung des Verfahrens geeignet ist.
Werden ältere Prozessorsysteme durch neue Prozessorarchitekturen abgelöst, ist es in der Regel erforderlich, die auf den älteren Prozessorsystemen (Ursprungsprozessoren) erstellten Programme auf den neuen Prozessoren (Zielprozessoren) zu emulieren. Dies erfordert, dass durch ein auf dem Zielprozessor installiertes Emulatorprogramm (kurz: Emulator) Befehle des Befehlssatzes für den Ursprungsprozessor durch Befehle des Befehlssatzes für den Zielprozessor nachgebildet werden.
Eine bekannte Vorgehensweise bei der Emulation ist es, nacheinander jeden Befehl des Programms einzeln zu interpretieren, d.h. nachzubilden und auszuführen. Diese Methode birgt den Nachteil, dass häufig auszuführende Programmsequenzen mehrfach nachgebildet werden müssen, was zeitaufwändig ist.
Gemäß dem Stand der Technik kann die Emulation eines für einen Ursprungsprozessor erstellten Programms (zu emulierendes Programm) dadurch beschleunigt werden, dass jeweils häufig auszuführende Teile des zu emulierenden Programms dynamisch, d.h. während der Emulationszeit, in Objektcode für den Zielprozessor übersetzt, dieser im Arbeitsspeicher des Zielprozessors abgelegt und schließlich unter der Kontrolle des Emu lators direkt auf dem Zielprozessor gegebenenfalls mehrfach ausgeführt wird.
Eine korrekte Emulation erfordert auch, dass die typischerweise im Betriebssystem vorgesehenen Behandlungsroutinen für synchrone Unterbrechungen, wie z.B. beim Zugriff auf eine nicht zugewiesene Speicheradresse (pagefault), sowie für asynchrone Unterbrechungen, etwa ein Zeitscheibenablauf (timer interrupt) beim Ablauf eines eingestellten Weckers, der Spezifikation des Ursprungsprozessors entsprechend zur Ausführung gebracht werden. Synchron bzw. asynchron bezieht sich in diesem Zusammenhang darauf, ob eine Unterbrechung an die Ausführung eines bestimmten Befehls des Prozessors gekoppelt ist (synchron) oder nicht (asynchron). Vor der Ausführung einer Routine, die für die Behandlung der Unterbrechung vorgesehen ist, muss insbesondere der Ursprungsprozessorzustand, welcher u.a. die Register und den Befehlszähler (program counter) umfasst, nachgebildet werden. Gemäß dem Stand der Technik wird in manchen Emulatoren, die dynamisch Teile des zu emulierenden Programms übersetzen, der Ursprungsprozessorzustand des zu emulierenden Programms während der Ausführung übersetzten Codes nicht permanent mitgeführt. Stattdessen führen solche Emulatoren eine Zuordnungstabelle, welche die Informationen über den Zustand, den der Ursprungsprozessor an der entsprechenden Stelle im zu emulierenden Programm hätte, mit Befehlsadressen in den Übersetzungen assoziieren. Anhand dieser Tabelle kann dann z.B. bei Unterbrechungen aus der Befehlsadresse des Zielprozessors der zugehörige Ursprungsprozessorzustand ermittelt werden.
Nicht jedem Befehl einer Übersetzung kann ein korrekter Ursprungsprozessorzustand zugeordnet werden. So kann etwa die Übersetzung eines komplexen Befehls eines CISC (complex in struction set computer)-Ursprungsprozessors eine Codesequenz von mehreren Befehlen eines RISC (reduced instruction set computer)-Zielprozessors erfordern, wobei ein korrekter Zustand des Ursprungsprozessors erst am Ende dieser Sequenz existiert. Auch Optimierungen von generiertem Code für mehrere Ursprungsbefehle können dazu führen, dass erst am Ende der optimierten Codesequenz ein korrekter Zustand des Ursprungsprozessors nachgebildet werden kann. Dieses Problem ist einfach für synchrone Unterbrechungen zu lösen, da diese nur von einigen bestimmten Befehlen ausgelöst werden können, z.B. Seitenfehler von Speicherzugriffen. Daher kann mit Regeln bzgl. der Verwendung solcher Befehle und Einschränkungen bei den Optimierungen dafür gesorgt werden, dass an den Verwendungsstellen solcher Befehle in Übersetzungen stets ein korrekter Zustand des Ursprungsprozessors nachgebildet werden kann. Dagegen können asynchrone Unterbrechungen die Ausführung einer Übersetzung nach jedem Befehl unterbrechen. Ein korrekter Zustand des Ursprungsprozessors kann daher i.a. nicht gewährleistet werden.
Gemäß dem Stand der Technik, wie z.B. in dem Patent US 6,308,318 B2 offenbart, kann bei einer Emulation mit dynamischer Übersetzung eine asynchrone Unterbrechung bis zum nächsten Befehl, zu dem ein korrekter Zustand des Ursprungsprozessors nachgebildet werden kann, verzögert werden, indem die Befehle der Übersetzung bis zu dieser Stelle interpretiert werden. Dieses Verfahren erfordert somit neben einem Übersetzer einen zusätzlichen Interpreter für den Zielprozessor.
Aus der Druckschrift US 5,764,962 ist ein Emulator bekannt, bei dem asynchrone Unterbrechungen verzögert werden, indem bei ihrem Auftreten ein Indikator gesetzt wird, welcher an Stellen in Übersetzungen, bei denen ein korrekter Zustand des Ursprungsprozessors nachgebildet werden kann, regelmäßig abgefragt wird. Es wird dann die Ausführung der Übersetzung bis zu einer solchen Überprüfung fortgesetzt. Diese Technik erfordert jedoch Prüfbefehle, welche dann jeweils zusätzlich zu dem übersetzten Objektcode des zu emulierenden Programms ausgeführt werden müssen, was zusätzlich Zeit in Anspruch nimmt.
Aus der Druckschrift US 6,567,933 B1 ist ein Prozessor mit einer integrierten Schnittstelle zur Fehlersuche (debugging) bekannt. Mithilfe der Schnittstelle kann der Prozessor innerhalb eines Debuggingsystems betrieben werden, wobei ein Aufruf von Debuggingroutinen mittels asynchroner Unterbrechungen vorgesehen ist. Die Debuggingroutinen ermöglichen dann z.B. eine Analyse interner Variablen und Abläufe. Insbesondere zur Fehlersuche bei Anwendungen mit Echtzeitanforderungen weist der Prozessor dabei einen Betriebsmodus auf, in dem die Bearbeitung der Debuggingroutinen nach Empfang einer asynchronen Unterbrechungsanforderung bis zum Erreichen eines manuell in der Codesequenz der Anwendung gesetzten Haltepunkts verzögert wird.
Es ist nun eine Aufgabe der vorliegenden Erfindung, ein Verfahren zur Behandlung von asynchronen Unterbrechungen bei einer Emulation vorzustellen, das weder einen Interpreter für den Zielprozessor noch zusätzliche Prüfbefehle im dynamisch übersetzten Objektcode des Zielprozessors noch einen manuellen Eingriff in den Objektcode erfordert.
Diese Aufgabe wird gelöst durch ein Verfahren gemäß Anspruch 1 und ein Computerprogramm gemäß Anspruch 13. Vorteilhafte Weiterbildungen und Ausgestaltungen der Erfindung sind Gegenstand der abhängigen Ansprüche.
Erfindungsgemäß werden asynchrone Unterbrechungen bei der Emulation eines für einen Ursprungsprozessor erstellten Programms auf einem Zielprozessor durch einen Emulator wie folgt durchgeführt: Das Programm wird dynamisch in Objektcode für den Zielprozessor übersetzt, der Objektcode wird gespeichert und durch den Zielprozessor ausgeführt. Beim Auftreten einer Aufforderung zu einer asynchronen Unterbrechung, der eine dem Emulator vorgegebene Unterbrechungsroutine zur Ausführung zugeordnet ist, während des Ausführens des Objektcodes wird die Ausführung des dynamisch übersetzten Objektcodes unterbrochen und im Objektcode ein Haltepunkt gesetzt. Dabei ist der Haltepunkt ein Befehl im Objektcode, bei dessen Abarbeitung durch den Zielprozessor eine Aufforderung zu einer synchronen Unterbrechung hervorgerufen wird. Die Ausführung des Objektcodes wird fortgesetzt und es wird, falls nachfolgend während des Ausführens des Objektcodes vom Zielprozessor die durch den Haltepunkt hervorgerufene Aufforderung zu einer synchronen Unterbrechung abgegeben wird, die Ausführung des Objektcodes unterbrochen, ein Zustand von Befehlszähler und Registern hergestellt, der dem Zustand entspricht, den sie bei Ausführung des Programms auf dem Ursprungsprozessor an einer entsprechenden Stelle im Programm hätten, und die zugeordnete Unterbrechungsroutine ausgeführt.
Vorteilhafterweise wird der Haltepunkt im Objektcode an eine Adresse gesetzt, bei der sichergestellt ist, dass der Zustand von Befehlszähler und Registern, den sie bei Ausführung des Programms auf dem Ursprungsprozessor an einer entsprechenden Stelle im Programm hätten, hergestellt werden kann.
In einer Ausführungsform der Erfindung wird eine solche Adresse einer Liste entnommen, in die während des Übersetzens des Programms in Objektcode für den Zielprozessor alle geeigneten Adressen für Haltepunkte eingetragen werden.
Durch das beschriebene Verfahren wird der Aufruf einer asynchronen Unterbrechung bis zu einer geeigneten Adresse verzögert, ohne dass während der Ausführung des Objektcodes zusätzliche Prüfbefehle oder die Kontrolle der Ausführung durch einen Interpreter notwendig sind. Durch den als Reaktion auf das Auftreten einer Aufforderung zu einer asynchronen Unterbrechung während des Ausführens des Objektcodes gesetzten Haltepunkt wird die Ausführung der asynchronen Unterbrechung zu einem geeigneten Zeitpunkt vom Zielprozessor selber durch das Absetzen einer Aufforderung zu einer synchronen Unterbrechung, die mit der Abarbeitung eines Haltepunktes einhergeht, angestoßen.
Nachstehend wird das erfindungsgemäße Verfahren anhand von Ausführungsbeispielen unter Bezugnahme auf die Figuren näher erläutert. Diese Ausführungsbeispiele beziehen sich auf einen Emulator, welcher Teile des zu emulierenden Programms dyna misch in Objektcode für den Zielprozessor übersetzt und kontrolliert direkt auf dem Zielprozessor gegebenenfalls mehrfach ausführt. Das Betriebssystem des Ursprungsprozessors ist dabei bereits für den Zielprozessor übersetzt worden und bedarf daher keiner Emulation. Diese Annahme dient nur der besseren Verständlichkeit der Erläuterungen. Die Erfindung ist nicht auf diesen Fall beschränkt und kann selbstverständlich auch eingesetzt werden, wenn das Betriebssystem ebenfalls emuliert wird. Die Erfindung umfasst jede Behandlung asynchroner Unterbrechungen während einer Emulation mit dynamischer Übersetzung, bei der Haltepunkte auf im folgenden auszuführende Befehle gesetzt werden, an denen ein korrekter Zustand des Ursprungsprozessors nachgebildet werden kann, und bei der schließlich bei Auslösung der Haltepunkte die eigentliche Reaktion auf die asynchrone Unterbrechung veranlasst wird.
Es zeigen:
1 ein Ausführungsbeispiel eines erfindungsgemäßen Emulators,
2 einen möglichen Aufbau eines Laufzeitstacks zur Stackspeicherverwaltung von Unterprogrammaufrufen in einem Ausführungsbeispiel der Erfindung,
3 ein Flussdiagramm zu dem Verfahrensschritt des Auffindens einer haltepunktgeeigneten Adresse in einer Ausführungsform der Erfindung,
4 eine schematische Darstellung zu dem Verfahrensschritt des Setzen eines Haltepunkts in einer Ausführungsform der Erfindung, und
5 eine schematische Darstellung zu dem Verfahrensschritt des des Setzen eines Haltepunkts in einer weiteren Ausführungsform der Erfindung.
1 zeigt schematisch ein Ausführungsbeispiel eines erfindungsgemäßen Emulators 300, einschließlich seiner Einbettung in unterschiedliche Hard- und Softwareschichten eines Computersystems, auf dem der Emulator 300 eingesetzt wird.
Auf einem Zielprozessor 100 eines Computersystems wird ein Betriebssystem 200 ausgeführt. Mit dem Zielprozessor 100 und dem Betriebssystem 200 wirkt der Emulator 300 zusammen und ermöglicht die Ausführung eines für einen Ursprungsprozessor erstellten Programms 400.
Der Emulator 300 weist einen Compiler 310 auf, der, gesteuert von einem Dispatcher 320 das Programm 400 blockweise in Objektcode 330 übersetzt. Während der Übersetzung wird vom Compiler 310 weiterhin eine Liste 340 von Adressen möglicher Haltepunkte 341 innerhalb des Objektcodes 330 erstellt. Der Objektcode 330 enthält u.U. Aufrufe von Routinen eines Laufzeitsystems 350. Zur Kontrolle der Ausführung hat der Dispatcher 320 Zugriff auf den Objektcode 330. Eine von dem Zielprozessor 100 abgegebene Aufforderung zu einer asynchronen Unterbrechung 101 oder einer synchronen Unterbrechung 102 wird von einem Unterbrechungsbehandler 360 aufgenommen. Es ist eine weitere Liste 370 vorgesehen, in der der Unterbrechungsbehandler 360 Unterbrechungsinformationen 371 der Aufforderungen für eine asynchrone Unterbrechung ablegt. Der Unterbrechungsbehandler 360 hat Zugriff auf die Liste 340 möglicher Haltepunkte 341 und auf den Objektcode 330, in den er einen Haltepunkt 331 setzt. Der Unterbrechungsbehandler 360 ist darüberhinaus mit dem Betriebssystem 200 verbunden, um eine im Betriebssystem 200 vorgesehene Unterbrechungsroutine 210 aufzurufen.
Der Emulator 300 wird zur Ausführung des Programms 400 auf dem Zielprozessor 100 eingesetzt. Bei dem hier gezeigten Ausführungsbeispiel liegt das Betriebssystem 200 bereits in einer für den Zielprozessor 100 übersetzten Version vor und kann unmittelbar auf dem Zielprozessor 100 ausgeführt werden. Allerdings sind die Schnittstellen des Betriebssystems 200 immer noch für das Computersystem des Ursprungsprozessors ausgelegt. So müssen z.B. die Gerätetreiber des Computersystems des Zielprozessors 100 entsprechend an diese Schnittstellen angepasst werden. Ebenso kann das Betriebssystem 200 Unterbrechungen des Zielprozessors 100 nicht unmittelbar verarbeiten. Sie werden gemäß dem Stand der Technik vom Emulator 300 auf Unterbrechungsschnittstellen des Ursprungsprozessors abgebildet.
Das Betriebssystem 200 lässt das Programm 400 von dem Dispatcher (auch Steuerroutine genannt) 320 ausführen. Der Dispatcher 320 kontrolliert dann die eigentliche Emulation. Gemäß dem Stand der Technik erfolgt die Emulation des Programms 400 dadurch, dass jeweils die auszuführenden Programmteile vom Compiler 310 dynamisch, das heißt während der Emulationszeit, dekodiert und in Objektcode 330 für den Zielprozessor 100 übersetzt werden. Im Objektcode 330 können auch von dem Laufzeitsystem 350 bereitgestellte Unterroutinen verwendet werden. Dies ist beispielsweise für die Übersetzung komplexer Cisc-Befehle hilfreich, deren Semantik mittels solcher Unterroutinen realisiert werden kann. Der so entstandene Objektcode 330 wird dann unter der Kontrolle des Dispatchers 320 direkt auf dem Zielprozessor 100 ausgeführt. Der Dispat cher führt dabei mittels einer hier nicht gezeigten Tabelle Buch über die bereits generierten Übersetzungen. Eine solche, dem Stand der Technik entsprechende Buchführung kann man sich als Zuordnungstabelle zwischen Befehlsadressen des zu emulierenden Programms 400 und Adressen des erzeugten Objektcodes 330 vorstellen. Dabei sind Fachleuten verschiedene Verfahren zur Realisierung solcher Zuordnungstabellen bekannt, die eine effiziente Suche der Übersetzungen zu einer gegebenen Befehlsadresse ermöglichen. Beispielsweise können Hash-Tabellen oder Suchbäume hierfür eingesetzt werden.
Am Ende der Ausführung eines Abschnitts des Objektcodes 330 gibt es einen neuen Zustand des Ursprungprozessors, zu welchem der Dispatcher 320 wieder eine geeignete Übersetzung in der Tabelle sucht. Falls er eine findet, führt er diese aus. Ansonsten veranlasst er den Compiler 310 zur Erzeugung eines weiteren erforderlichen Abschnitts des Objektcodes 330. Der Dispatcher 320 gibt die Kontrolle über die Ausführung von Objektcode 330 an das Betriebssystem 200 ab, wenn das emulierte Programm 400 mittels eines Systemaufrufs (system call), z.B. zur Programmbeendigung, eine Betriebssystemfunktion aufruft oder durch eine synchrone Unterbrechung, etwa einen Seitenfehler, unterbrochen wird.
Eine vom Zielprozessor ausgegebene Aufforderung zu einer asynchronen Unterbrechung 101 wird an den Unterbrechungsbehandler 360 geleitet. Dieses wird z.B. durch geeignetes Setzen sogenannter Unterbrechungsvektoren erreicht. Der Unterbrechungsbehandler 360 veranlasst den Dispatcher 320, die Ausführung des Objektcodes 330 zu stoppen. Daraufhin überprüft der Unterbrechungsbehandler 360 zunächst, ob in der Liste 370 bereits Unterbrechungsinformationen 371 einer asynchronen Unterbrechung gespeichert sind. Wenn das der Fall ist, wurde bereits ein Haltepunkt 331 gesetzt und der Unterbrechungsbehandler 360 fügt lediglich die Unterbrechungsinformationen 371 der mit der aktuellen Aufforderung zu einer asynchronen Unterbrechung 101 als weiteren Eintrag in die Liste 370. Falls der Unterbrechungsbehandler 360 bei der Überprüfung der Liste 370 noch keinen Eintrag vorfindet, einnimmt er aus der Liste 340 die Adressen für einen Haltepunkt 341, welche garantiert bei der weiteren Fortsetzung der Ausführung des Objektcodes als erste durchlaufen wird, und setzt an dieser Adresse im Objektcode 330 den Haltepunkt 331. Danach werden die Unterbrechungsinformationen 371 der aktuellen Aufforderung zu einer asynchronen Unterbrechung 101 als erster Eintrag in die Liste 370 geschrieben. Anschließend wird die Ausführung des Objektcodes an der unterbrochenen Adresse weiter fortgesetzt.
Der Haltepunkt 331 zeichnet sich dadurch aus, dass er auf dem Zielprozessor bei seiner Abarbeitung die Aufforderung zu einer synchronen Unterbrechung 102 hervorruft. Typischerweise sind im Befehlsatz eines Prozessors spezielle Befehle für diese Aufgabe definiert. Bei Prozessoren, bei denen das nicht der Fall ist, können für diesen Zweck auch ungültige Befehlswerte, d.h. Werte, die nicht im Befehlssatz definiert sind, verwendet werden. Wie die asynchrone Unterbrechung 101 wird auch die synchrone Unterbrechung 102 an den Unterbrechungsbehandler 360 geleitet. Der Unterbrechungsbehandler 360 veranlasst den Dispatcher 320, die Ausführung des Objektcodes 330 zu stoppen und stellt für Register und Befehlszähler einen Zustand her, der dem Zustand entspricht, den sie bei Ausführung des Programms auf dem Ursprungsprozessor an einer entsprechenden Stelle im Programm hätten, was an dieser Stelle im Objektcode 330 gesichert möglich ist. Daraufhin wird der Haltepunkt 331 entfernt, indem er durch den ursprünglichen Befehl an dieser Adresse ersetzt wird. Dadurch kann dieser Objektcode 330 zukünftig wieder verwendet werden. Anschließend ruft der Unterbrechungsbehandler 360 für die Einträge der Unterbrechungsinformationen 371 in der Liste 370 die passenden Unterbrechungsroutinen 210 des Betriebssystems 200 auf und leert anschließend die Liste 370. Nach Abarbeitung der Unterbrechungsroutinen 210 veranlasst das Betriebssystem 200 über den Dispatcher 320 die weitere Emulation des Programms 400 mit dem nun gültigen Zustand des Ursprungprozessors. Unter bestimmten Umständen kann das bedeuten, den Objektcode 330 nach der Adresse des Haltepunkts 331 fortzusetzen. In anderen Fällen kann vom Dispatcher 320 entweder eine bereits vorhandene passende Übersetzung zur Ausführung gebracht werden oder der Compiler 310 angestoßen werden, einen neuen Abschnitt des Objektcodes 330 zu erzeugen, der danach zur Ausführung gebracht wird.
Im Folgenden sind Details dieses Ausführungsbeispiels einer erfindungsgemäßen Behandlung von asynchronen Unterbrechungen näher beschrieben.
Die erfindungsgemäße Behandlung von asynchronen Unterbrechungen bedient sich der Liste 340 der möglichen Adressen für einen Haltepunkt 341. Diese Liste 340 wird beim Übersetzen vom Compiler 310 angelegt. In einer möglichen Ausführungsform der Erfindung wird in der Liste 340 jeder Befehlsadresse innerhalb der Übersetzung eine Menge haltepunktgeeigneter Adressen 341 zugeordet. Dieses sind Adressen, bei denen ein Zustand der Register und des Befehlszählers des Ursprungprozessors nachgebildet werden kann. Diese Adressen 341 müssen ebenfalls zu Befehlen innerhalb der Übersetzung gehören. Es muss gewährleistet sein, dass garantiert eine der zugeordneten Ad ressen bei einer von der Unterbrechungsstelle ausgehenden Fortsetzung durchlaufen wird.
In einer weiteren Ausführungsform kann die Liste 340 vereinfacht werden, falls der Compiler 310 geeignete Regeln bei ihrer Erzeugung befolgt. Eine solche Regel kann z.B. lauten, dass ein bedingter Sprungbefehl innerhalb einer Übersetzung stets für einen Haltepunkt geeignet sein muss. Dies sichert die Existenz eines eindeutigen Haltepunkts. Ansonsten sind, wie bereits beschrieben, alle möglichen Verzweigungen zu berücksichtigten. Fordert man sogar, dass jeder Sprungbefehl für einen Haltepunkt geeignet sein muss, so ist gewährleistet, dass stets eine höhere Folgeadresse für einen Haltepunkt geeignet ist. In einem solchen Fall ist es nicht notwendig, dass in der Liste 340 jeder Befehlsadresse eine haltepunktgeeignete Adresse 341 zugeordnet ist, sondern es ist ausreichend, die Menge aller haltepunktgeeigneten Adressen 341 in die Liste 340 aufzunehmen. Die Adresse des nächsten Haltepunkts 331 zu einer Unterbrechungsadresse kann dann bestimmt werden, indem die kleinste Adresse aus der Menge der haltepunktgeeigneten Adressen 341 ermittelt wird, welche gleich oder größer der Unterbrechungsadresse ist. Neben einer Liste wie sie für in dieses Ausführungsbeispiel beschrieben ist, können weitere Datenstrukturen im Rahmen der Erfindung eingesetzt werden. Insbesondere sind solche geeignet und Fachleuten bekannt, die eine effiziente Suche des nächsten Haltepunkts 331 zu einer gegebenen Unterbrechungsadresse ermöglichen. Beispielsweise können Sortierbäume dafür eingesetzt werden.
Weiterhin ist bekannt, dass Prozessoren bei Unterbrechungen den aktuellen Prozessorzustand automatisch abspeichern. Zum Prozessorzustand gehört insbesondere der Befehlszähler und Registerinhalte. Dieser gespeicherte Prozessorzustand wird zusammen mit unterbrechungsspezifischen Informationen, etwa der fehlerhaften Speicheradresse bei einem Seitenfehler, der Unterbrechungsroutine als Unterbrechungsinformationen 371 übergeben und wird von dieser zur eigentlichen Unterbrechungsbehandlung und anschließenden Fortsetzung des unterbrochenen Programms verwendet. Diese zur Unterbrechungsbehandlung übergebenen Unterbrechungsinformationen 371 sind prozessorabhängig. Daher können die vom Zielprozessor 100 ausgelösten Unterbrechungen nicht unmittelbar von der Unterbrechungsroutine 210 des Betriebssystems 200 verarbeitet werden, da dessen Schnittstellen für Unterbrechungen des Ursprungsprozessors ausgelegt sind. Deshalb werden die Unterbrechungen zunächst von dem Unterbrechungsbehandler 360 abgefangen. Dieser unterscheidet zwischen Aufforderungen zu asynchronen Unterbrechungen 101, z.B. Zeitscheibenablauf, und Aufforderungen zu synchronen Unterbrechungen 102, etwa Seitenfehlern und auch Haltepunkten, und arbeitet wie folgt:

1. Aufforderung zu einer asynchronen Unterbrechung 101: Zunächst werden die Unterbrechungsinformationen 371 zu der Liste 370 hinzugefügt, welche z.B. gemäß dem first in first out (fifo) Verfahren organisiert ist. Falls es der erste Eintrag in der Liste 370 ist, veranlasst der Unterbrechungsbehandler 360 nun den Abbruch der Emulation. Falls es bereits weitere Einträge gibt, ist die Arbeit schon erledigt, da die erste Unterbrechung den Abbruch der Emulation bereits veranlasste. Für den Abbruch der Emulation sind zwei Fälle bzgl. der Unterbrechungsstelle zu unterscheiden:
a) Die Unterbrechung erfolgt nicht während der Ausführung einer Übersetzung, sondern im Programmcode des Emulators, etwa des Compiler 310. In diesem Fall ist garantiert ein konsi stenter Zustand der Ursprungsmaschine verfügbar und der Emulator kann damit unmittelbar die Kontrolle an das Betriebssystem 200 abgeben.
b) Die Unterbrechung erfolgt während der Ausführung eines Abschnitts des Objektcodes 330: Erfindungsgemäß wird aus der Liste 340 möglicher Adressen für Haltepunkte 341 die zur Unterbrechungsstelle passende haltepunktgeeignete Adresse 341 ermittelt und ein Haltepunkt 331 im Objektcode 330 an die Adresse 341 gesetzt. Anschließend wird die aktuelle Unterbrechungsbehandlung beendet und die Ausführung des Objektcodes 330 fortgesetzt. Dabei können weitere Aufforderungen zu einer asynchronen Unterbrechung 101 auftreten, die wie beschrieben vermerkt werden. Auch eine Aufforderung zu einer synchronen Unterbrechung 102, wie z.B. Seitenfehler, kann die Ausführung abbrechen. Spätestens aber beim gesetzten Haltepunkt 331 wird eine Aufforderung für eine synchrone Unterbrechung 102 vom Zielprozessor 100 ausgelöst, welche, wie im folgenden allgemein für synchrone Unterbrechungen beschrieben, behandelt wird.
2. Aufforderung zu einer synchronen Unterbrechung 102: Auf synchrone Unterbrechungen muss der Emulator 300 unmittelbar reagieren und somit gemäß dem Stand der Technik stets einen konsistenten Zustand der Register und des Befehlszählers des Ursprungsprozessors nachbilden können. Damit kann er die Kontrolle an das Betriebssystem 200 übergeben. Diese Übergabe erfolgt über den Unterbrechungsbehandler 360, der mittels einer Endebehandlung noch Aufräumarbeiten erledigt, etwa die Entfernung eines eventuell vorhanden Haltepunkts 331 wegen früheren asynchronen Unterbrechungen. Er ist auch für das Leeren der Liste 370 verantwortlich und muss die in der Liste 370 anhand der Unterbrechungsinformationen 371 vorgemerkten asynchronen Unterbrechungen zusammen mit dem synchronen Unterbrechung geeignet über die Unterbrechungsroutine 210 des Betriebssystems 200 zur Ausführung bringen. Wurde die synchrone Unterbrechung von einem Haltepunkt 331 ausgelöst, so werden nur die asynchronen Unterbrechungen dem Betriebssystem 200 signalisiert.

2 zeigt den Aufbau eines Laufzeitstacks 500 für die Speicherverwaltung von Unterprogrammaufrufen. Ein solcher Aufbau ist aus dem Stand der Technik bekannt. Die Figur dient der beispielhaften Erläuterung, wie ein Haltepunkt 331 in dem Objektcode 330 gesetzt wird, falls der Aufruf zu einer asynchronen Unterbrechung 101 auftritt, während eine Routine des Laufzeitsystems 350 ausgeführt wird. Da die Routinen des Laufzeitsystems 350 an vielen Stellen von Übersetzungen genutzt werden können, können Adressen innerhalb des Laufzeitsystems 350 keine festen Zustände des Ursprungsprozessors zugeordnet werden. Sie sind somit nicht für Haltepunkte geeignet. Daher ist es vorteilhaft, bei einer Unterbrechung, die während der Ausführung einer Routine des Laufzeitsystems 350 auftritt, den Haltepunkte 331 ebenfalls im Objektcode 330 zu setzen. Dazu wird mittels der auf dem Laufzeitstack 500 vorhandenen Informationen die Rückkehradresse raddr in den Objektcode 330 ermittelt und der Haltepunkt 331 davon ausgehend gesetzt, d.h., der Haltepunkt 331 wird so gesetzt, als wäre die Aufforderung zu einer asynchronen Unterbrechung 101 unmittelbar nach der Rückkehr aus dem Laufzeitsystem 350 aufgetreten. Fachleuten ist bekannt, dass bei Funktionsaufrufen auf dem Laufzeitstack 500 spezielle Datenstrukturen, so genannte Prozedur Segmente (activation records) 510, 520, 530 für aufgerufene Funktionen angelegt werden. Diese werden mit Hilfe von Zeigern auf die Vorgänger 511, 521, 531 rückwärts verkettet und enthalten zusätzlich lokalen Speicherplatz 513, 523, 533 der Funktion sowie die Rückkehradresse 512, 522, 532 in die aufrufende Funktion. Ein globaler Zeiger (frame pointer) 540 verweist auf das Prozedur Segment (hier) 510 der aktuell ausgeführten Funktion und wird beim Rücksprung auf den Vorgänger (hier) 520 zurückgesetzt. Über diese Verkettung kann stets die Rückkehradresse raddr in die Übersetzung ermittelt werden, indem ein weiterer Zeiger 541 verwaltet wird, der auf das Prozedur Segment (hier) 530 des aktuell ausgeführten Abschnitts des Objektcodes 330 zeigt. Dazu wird dem weiteren Zeiger 541 stets zu Beginn der Ausführung einer Übersetzung der Wert des aktuellen frame pointers 540 zugewiesen. Tritt nun der Aufruf zu einer asynchronen Unterbrechung 101 auf, ist zu prüfen, ob der frame pointer 540 mit dem weiteren Zeiger 541 übereinstimmt. Falls dies der Fall ist, so ist die Unterbrechung an einem Befehl innerhalb des Objektcodes 330 aufgetreten. Ansonsten liegt die Unterbrechungsstelle im Laufzeitsystem 350, wie dies auch im gezeigten Beispiel der Fall ist. Im Beispiel wurde aus dem Objektcode 330 zunächst die Funktion f des Laufzeitsystems 350 aufgerufen. Diese rief noch die Funktion g des Laufzeitsystems 350 auf, bei deren Ausführung die Aufforderung zu einer asynchronen Unterbrechung 101 erfolgte. Ausgehend vom frame pointer 540 kann durch Rückverfolgung der Prozedur Segmente 510, 520, 530 die Rückkehradresse raddr in den Objektcode 330 ermittelt werden. Im gezeigten Beispiel ist raddr die Rückkehradresse 522. Diese ist in dem Prozedur Segment 520 enthalten, dessen Zeiger auf den Vorgänger 511 mit dem weiteren Zeiger 541 auf das Prozedur Segment der aktuell ausgeführten Übersetzung übereinstimmt.
In 3 ist in Form eines Flussdiagrammes der Ausschnitt aus dem erfindungsgemäßen Verfahren skizziert, gemäß dem im Falle einer asynchronen Unterbrechung die nächste haltepunkt geeignete Adresse hpaddr zum Setzen des Haltepunkts 331 ermittelt werden kann. Wie in Schritt 600 gezeigt ist, tritt eine Aufforderung zu einer asynchronen Unterbrechung 101 bei einer Unterbrechungsadresse iaddr auf. Falls iaddr innerhalb des Objektcodes 330 liegt (Abfrage in Schritt 610), so wird in Schritt 612 die Adresse des nächsten passenden Haltepunkts hpaddr aus der Liste 340 der möglichen Adressen für Haltepunkte 341 ermittelt. Falls iaddr innerhalb einer Routine des Laufzeitsystems 350 ist (Abfrage in Schritt 620), so wird zunächst in Schritt 621 die Rückkehradresse raddr in den Objektcode 330 ermittelt, z.B. mittels der bereits in Verbindung mit 2 beschriebenen Durchsuchung der Prozedur Segmente 510, 520, 530 auf dem Laufzeitstack 500. Zu dieser Rückkehradresse raddr wird anschließend in Schritt 622 die Adresse hpaddr des nächsten passenden Haltepunkts aus der Liste 340 bestimmt. Falls iaddr weder eine Adresse innerhalb des Objektcodes 330 noch innerhalb des Laufzeitsystems 350 ist, bedeutet dies, dass aktuell keine Übersetzung ausgeführt wird und daher kein Haltepunkt 331 erforderlich ist.
4 erläutert das erfindungsgemäße Setzen des Haltepunkts 331 innerhalb des Objektcodes 330, wobei bei der Erzeugung des Objektcodes 330 durch den Compiler 310 die bereits erwähnten Regeln beachtet sind, wodurch zu jeder Unterbrechungsstelle stets eine folgende, eindeutige haltepunktgeeignete Adresse 341 gegeben ist. In diesem Beispiel tritt bei Ausführung des Objektcodes 330 die Aufforderung zu einer asynchronen Unterbrechung 101 bei der Adresse 0x40002444 auf. Die Liste 340 der möglichen Adressen für Haltepunkte 341 enthält in diesem Beispiel sämtliche haltepunktgeeignete Adressen (hier beispielhaft 341a, 341b, 341c) aufsteigend sortiert. Zur Ermittlung der zur Unterbrechungsadresse iaddr (0x40002444) passende Haltepunktadresse hpaddr wird in der Tabelle nun die kleinste Adresse 341 gesucht, welche gleich oder größer als die Unterbrechungsadresse iaddr ist. Diese Bedingung erfüllt der Eintrag 341b mit der Adresse 0x4000246C. Der Eintrag 341a liegt noch vor der Unterbrechungsadresse iaddr und Eintrag 341c ist nicht die naheste Adresse. Daher wird auf Adresse 0x4000246C als Haltepunktaddresse hpaddr der Haltepunkt 331 gesetzt. Zunächst wird der ursprüngliche Befehl an dieser Adresse 0x4000246C in einer hier nicht gezeigten Datenstruktur gesichert und anschließend durch ein ungültiges Befehlswort ersetzt. Dieses ungültige Befehlswort stellt den Haltepunkt 331 dar. Beim späteren Entfernen des Haltepunkts 331 wird der gesicherte ursprüngliche Befehl wieder an seine ursprünglichen Adresse (0x4000246C) zurückkopiert.
Wie im Zusammmenhang mit 1 beschrieben, kann eine Liste 340, die, wie hier, nur haltepunktgeeignete Adressen 341 enthält, nur dann eingesetzt werden, wenn bei ihrer Erzeugung vom Compiler 310 bestimmte Regeln befolgt werden, durch die garantiert ist, dass die haltepunktgeeigneten Adressen 341 auch durchlaufen werden. Ist dieses nicht der Fall, muss gegebenfalls (z.B. bei Sprungbefehlen) in jedem alternativen Ablaufpfad des Objektcodes 330 ein Haltepunkt 331 gesetzt werden.
5 erläutert das Setzen des Haltepunkts 331 in einem weiteren Ausführungsbeispiel der Erfindung. Diese Ausführungsform kann bevorzugt dann eingesetzt werden, wenn von dem Compiler 310 erstellte Übersetzungen als Objektcode 330 in einem gemeinsamen Speicher (shared memory) abgelegt werden, so dass sie von mehreren Emulatoren 300 parallel verwendet werden können. In solchen Fällen kann der Haltepunkt 330 nicht unmittelbar in dem im gemeinsamen Speicher abgelegten Objektcode 330 gesetzt werden, weil dieser bei allen Emulatoren 300, welche den Objektcode 330 ausführen, eine Aufforderung zu einer synchronen Unterbrechung 102 auslösen würde, und nicht nur bei dem, welcher den Haltepunkt 331 wegen der vorausgegangenen Aufforderung zu einer asynchronen Unterbrechung 101 setzte. Daher wird in dieser Ausführungsform erfindungsgemäß zunächst der Abschnitt des Objektcodes 330 zwischen der Unterbrechungsadresse iaddr (0x40002444) bis zur nächsten haltepunktfähigen Adresse 341b (0x4000246C) in einen privaten Speicherbereich als Objektcodekopie 700 vom Kopierer 710 kopiert (in dieser 5 sind Beispieladressen aus 4 übernommen worden). Privater Speicherbereich ist in diesem Zusammenhang ein Speicher oder ein Teil eines Speichers, der nicht von mehreren Emulatoren 300 gemeinsam benutzt wird. Bei dem Anlegen der Objektcodekopie 700 werden vom Kopierer 710 sowohl ggf. Adressbezüge angepasst als auch die Zuordnung der Adressen der Befehle in der Objektcodekopie 700 zu denen des originalen Objektcodes 330 vermerkt. Fachleuten ist bekannt, dass beim Verschieben von Programmcode im Speicher die Adressangaben in den Adressteilen von Befehlen überprüft und ggf. angepasst werden müssen und nennen diesen Vorgang Relokation. Die Zuordnung kann, wie in diesem Beispiel gezeigt, mittels einer Adresszuordnungstabelle 720 erfolgen, die vom Kopierer 710 erzeugt wird. Ebenfalls ist es möglich, die Zuordnung durch eine einfache Abbildungsfunktion zu realisieren, da es sich i.a. nur um eine Verschiebung mit einer festen Distanz handelt. In der Objektcodekopie 700 wird schließlich der Haltepunkt 331 gesetzt und die weitere Ausführung anschließend fortgesetzt. Dazu wird der Befehlszähler auf die Startadresse der Objektcodekopie 700 (hier 0x10008000) umgesetzt.
Auf diese Weise wird erreicht, dass der Haltepunkt 331 nur bei dem Emulator 300 auslöst, welcher durch die Aufforderung zu einer asynchronen Unterbrechung 101 unterbrochen wurde. Beim Auslösen des Haltepunkts 331 wird zunächst der Haltepunkt 331 in der Objektcodekopie 700 mittels der gespeicherten Adresszuordnungstabelle 720 auf den originalen Objektcode 330 projiziert, d.h., die Adressen der Kopie werden auf die ursprünglichen Adressen des Originals umgerechnet, so dass es erscheint, als sei die Unterbrechung im originalen Objektcode 330 aufgetreten. Anschließend wird, wie in den zuvor beschriebenen Ausführungsbeispielen, für Register und Befehlszähler ein Zustand hergestellt, der dem Zustand entspricht, den sie bei Ausführung des Programms auf dem Ursprungsprozessor an der entsprechenden Stelle im Programm hätten, und die ursprüngliche asynchrone Unterbrechung zur Ausführung gebracht, als sei sie an dieser Stelle aufgetreten.
Auch bei diesem Verfahren ist der Sonderfall zu berücksichtigen, dass die Aufforderung zu einer asynchronen Unterbrechung 101 innerhalb des Laufzeitsystems 350 auftritt. Bei diesem Sonderfall wird zunächst die Rückkehradresse raddr und die dazu passende haltepunktgeeignete Adresse hpaddr ermittelt, wie im Zusammenhang mit 3 beschrieben. Anschließend wird genau der Bereich, der zwischen Rückkehradresse raddr und haltepunktgeeigneter Adresse hpaddr liegt, kopiert und der Haltepunkt 331 in der Objektcodekopie 700 gesetzt. Um zu gewährleisten, dass die Objektcodekopie 700 bei der weiteren Ausführung verwendet wird, wird anstelle des Befehlszählers die Rückkehradresse (hier) 522 innerhalb des entsprechenden Prozedur Segments (hier) 520 auf die Anfangsadresse der Objektcodekopie 700 gesetzt. Damit führt der Rücksprung aus dem Laufzeitsystem 350 automatisch in die Objektcodekopie 700.

100: Zielprozessor
101: Aufforderung zu einer asynchronen Unterbrechung
102: Aufforderung zu einer synchronen Unterbrechung
200: Betriebssystem
210: Unterbrechungsroutine
300: Emulator
310: Compiler
320: Dispatcher
330: Objektcode
331: Haltepunkt
340: Liste möglicher Adressen für Haltepunkte
341: mögliche Adresse für Haltepunkt
350: Laufzeitsystem
360: Unterbrechungsbehandler
370: Liste mit Unterbrechungsinformationen
371: Unterbrechungsinformationen
400: Programm
500: Laufzeitstack
510, 520, 530: Prozedur Segmente
511, 521, 531: Zeiger auf Vorgänger
512, 522, 532: Rückkehradresse
513, 523, 533: lokaler Speicherplatz
540: globaler Zeiger (frame pointer)
541: weiterer Zeiger
700: Objektcodekopie
710: Kopierer
720: Adresszuordnungstabelle
iaddr: Unterbrechungsadresse
raddr: Rückkehradresse
hpaddr: Haltepunktadresse

Claims

Verfahren zur Behandlung von asynchronen Unterbrechungen bei einer Emulation eines für einen Ursprungsprozessor erstellten Programms (400) auf einem Zielprozessor (100) durch einen Emulator (300), bei dem – das Programm (400) dynamisch in Objektcode (330) für den Zielprozessor (100) übersetzt wird und der Objektcode (330) gespeichert wird, – der Objektcode (330) durch den Zielprozessor (100) ausgeführt wird, – beim Auftreten einer Aufforderung zu einer asynchronen Unterbrechung (101), der eine dem Emulator (300) vorgegebene Unterbrechungsroutine (210) zur Ausführung zugeordnet ist, während des Ausführens des Objektcodes (330) die Ausführung des dynamisch übersetzten Objektcodes (330) unterbrochen wird, im Objektcode (330) ein Haltepunkt (331) gesetzt wird, wobei der Haltepunkt (331) ein Befehl im Objektcode (330) ist, bei dessen Abarbeitung durch den Zielprozessor (100) eine Aufforderung zu einer synchronen Unterbrechung (102) hervorgerufen wird, und die Ausführung des Objektcodes (330) fortgesetzt wird und, – falls nachfolgend während des Ausführens des Objektcodes (330) vom Zielprozessor (100) die durch den Haltepunkt (331) hervorgerufene Aufforderung zu einer synchronen Unterbrechung (102) abgegeben wird, die Ausführung des Objektcodes (330) unterbrochen wird, ein Zustand von Befehlszähler und Registern hergestellt wird, der dem Zustand entspricht, den sie bei Ausführung des Programms (400) auf dem Ursprungsprozessor an einer entsprechenden Stelle im Programm (400) hätten, und die zugeordnete Unterbrechungsroutine (210) ausgeführt wird.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass der Haltepunkt (331) im Objektcode (330) an eine Adresse (341) gesetzt wird, bei der sichergestellt ist, dass der Zustand von Befehlszähler und Registern, den sie bei Ausführung des Programms (400) auf dem Ursprungsprozessor an einer entsprechenden Stelle im Programm (400) hätten, hergestellt werden kann.
Verfahren nach einem der Ansprüche 1 oder 2, dadurch gekennzeichnet, dass bei der Übersetzung alle geeigneten Adressen für Haltepunkte (341) bestimmt und in einer Liste (340) abgelegt werden.
Verfahren nach Anspruch 3, dadurch gekennzeichnet, dass zum Setzen eines Haltepunkts (331) aus der Liste (340) aller geeigneten Adressen (341) die gegenüber der Adresse des Befehlszählers, bei der die Aufforderung zu einer asynchronen Unterbrechung (101) abgegeben wurde, nächstgrößere Adresse als Haltepunktadresse (hpaddr) herausgesucht wird und der Haltepunkt (331) an die Haltepunktadresse (hpddr) gesetzt wird.
Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass zum Setzen eines Haltepunkts (331) an die Haltepunktadresse (hpaddr) der Befehl, der an der Haltepunktdresse (hpaddr) im Objektcode (330) steht, zwischengespeichert wird und dann statt diesem Befehl an der Haltepunktadresse (hpaddr) der Haltepunkt (331) gesetzt wird.
Verfahren nach Anspruch 5, dadurch gekennzeichnet, dass vor der Fortsetzung der Ausführung des Objektcodes (330) nach Beendigung der Unterbrechungsroutine (210) der zwischenge speicherte Befehl wieder in den Objektcode (330) an die Adresse (hpaddr) des Haltepunkts (331) zurückgeschrieben wird.
Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass zum Setzen eines Haltepunkts eine Kopie (700) des Objektcodes (330) erstellt wird und an einer geeignete Adresse in der Objektcodekopie (700) der Haltepunkt (331) gesetzt wird, wonach die Objektcodekopie (700) ausgeführt wird.
Verfahren nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, dass als Haltepunkt (331) ein in dem Befehlssatz des Zielprozessors (100) vorhandener Befehl zum Auslösen einer synchronen Unterbrechung eingesetzt wird.
Verfahren nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, dass als Haltepunkt (331) ein in dem Befehlssatz des Zielprozessors (100) ungültiger Befehlscode eingesetzt wird.
Verfahren nach einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, dass bei der Aufforderung zu einer asynchronen Unterbrechung (101) zugehörige Aufrufparameter und weitere, zur Ausführung der Unterbrechung notwendige Informationen als Unterbrechungsinformationen (371) in einer Liste (370) abgelegt werden.
Verfahren nach Anspruch 10, dadurch gekennzeichnet, dass bei der Aufforderung zu einer asynchronen Unterbrechung (101) der Haltepunkt (331) nur dann gesetzt wird, wenn die Liste (370) für die Unterbrechungsinformationen (371) leer ist.
Verfahren nach einem der Ansprüche 10 oder 11, dadurch gekennzeichnet, dass bei der Aufforderung zu einer synchronen Unterbrechung (102) nacheinander alle Unterbrechungen, deren Unterbrechungsinformationen (371) in der Liste (370) abgelegt sind, behandelt werden und danach die Liste (370) geleert wird.
Computerprogramm, das in einem Computer abgearbeitet wird und ein Verfahren nach einem der Ansprüche 1 bis 12 ausführt.