DE68924507T2

DE68924507T2 - Verfahren und Gerät zur Markierung von Emulationsanalysezuständen.

Info

Publication number: DE68924507T2
Application number: DE68924507T
Authority: DE
Inventors: Robert D Morrison
Original assignee: Hewlett Packard Co
Current assignee: Agilent Technologies Inc
Priority date: 1988-08-09
Filing date: 1989-06-26
Publication date: 1996-04-04
Anticipated expiration: 2009-06-27
Also published as: DE68924507D1; EP0354654A3; EP0354654A2; US5073968A; JP2886191B2; JPH0281140A; EP0354654B1

Description

Hintergrund der Erfindung

Diese Erfindung bezieht sich auf Emulationssysteme (Emulatoren), die zur Entwicklung von auf Mikroprozessor basierenden Systemen verwendet werden, und insbesondere auf Techniken und auf Hardware zum Schaffen einer zusätzlichen Markierung in einem Speicher auf Emulationsanalysezuständen, die in Emulatoren zu Analysezwecken während Warteschlangenauflösungs- und Verfolgungs-Operationen verwendet werden.
Emulatoren unterstützen die Entwicklung von auf Mikroprozessoren basierenden Systemen (Zielsystemen), indem Entwicklern eine Einrichtung bereitgestellt wird, um Software (Zielprogramme) zu laden und auszuführen, bevor irgendeine Hardware aufgebaut wird. Der Emulator kann das Zielsystem entweder teilweise oder ganz ersetzen. Emulatoren können an einem beliebigen Punkt bei der Systementwicklung mit dem Zielsystem verbunden werden. Fig. 1 ist ein Blockdiagramm eines typischen auf einem Mikroprozessor basierenden Systems mit einem Mikroprozessor 10, einem Speicher 12 und einer Eingabe/Ausgabe-Vorrichtung 14. Fig. 2 ist ein Blockdiagramm eines Emulationssystems mit einem Emulator 18, einem Zentralrechner 20 und einem Benutzerterminal 22. Fig. 3 ist ein Blockdiagramm eines Emulators, der mit einem auf einem Mikroprozessor basierenden System verbunden ist. Der Emulator ist anstelle des Mikroprozessors 10, der in Fig. 1 gezeigt ist, in den Mikroprozessorsockel 16 in dem Zielsystem gesteckt und wird von dem Zentralrechner 20 unterstützt. Der Emulator liefert die Funktionen des Mikroprozessors und einige des Speichers für das Zielsystem, da der Benutzer nicht eine beliebige oder alle Speicherfunktionen des Zielsystems besitzen muß. Wenn sich die Entwicklung dem Abschluß nähert, werden die Funktionen, die von dem Emulator ausgeführt werden, allmählich zu dem Zielsystem übertragen. Während der Entwicklung liefert der Emulator zusätzliche Mikroprozessorsteuerungen, die üblicherweise nicht verfügbar sind und bei der Störungssuche von Zielsoftwareproblemen nützlich sind, welche folgende einschließen: Einzelschrittbetrieb, Unterbrechungspunkte für bestimmte Speicheradressen, Unterbrechungspunkte auf unsachgemäßen Speicherzugriffen, Anzeigen und Modifizieren interner Register, usw..
Eine spezielle Mikroprozessorsteuerung, die nützlich ist, wird "Befehlsanalyse" genannt. Die Befehlsanalyse besteht aus einer "Verfolgung", welche die Erfassung einer Ansammlung von Zuständen während der Ausführung eines Zielprogramms ist; und einer Zerlegung, welche die Analyse der erfaßten Sammlung von Zuständen ist, die der Ausführung des Zielprogramms durch den Mikroprozessor folgen. Die Befehlsanalyse versucht, den tatsächlichen Befehlsprozess wiederherzustellen. Das Standardverfahren der Erfassung untersucht die Befehle, die vor der Ausführung abgerufen werden, um Zustandsinformationen zu erhalten, welche üblicherweise die Adresse, Daten und Zustandsinformationen eines einzelnen Mikroprozessorzyklusses einschließen. Jedoch kann ein signifikanter Unterschied zwischen den Befehlen, die abgerufen werden, und den Befehlen, die ausgeführt werden, existieren. Das Verfahren des Versuchens, eine Befehlsausführung aus den Befehlsabrufen wiederherzustellen, wird "Warteschlangenauflösung" ("Dequeueing") genannt.
Ein Warteschlangenauflösungsverfahren, das früher gelehrt wurde, wurde "Hardware-Warteschlangenauflösung" genannt. Dieses Warteschlangenauflösungsverfahren war ein Versuch, die Mikroprozessor-Warteschlange mit Schaltungstechnik wiederherzustellen. Dies war schwierig zu erreichen und daher zeitverbrauchend, aufwendig und nicht immer genau. Jede Hardware-Warteschlangenauflösungs-Vorrichtung war von der Architektur des Zielprozessors abhängig, weshalb diese schwierige Aufgabe für jeden Entwurf eines neuen Emulators wiederholt wurde. Kritische Informationen über die Mikroprozessor-Architektur, die zum Entwurf erforderlich war, war oft nicht verfügbar, wobei viele andere Prozessoren Warteschlangen aufwiesen, die nicht auf diese Art und Weise wiederhergestellt werden konnten.
Ein zweites Warteschlangenauflösungs-Verfahren, das gemäß dem Stand der Technik gelehrt wurde, war als "Software-Warteschlangenauflösung" bekannt. Dieses Warteschlangenauflösungsverfahren versucht, die Warteschlange des Mikroprozessors durch Decodieren der Befehlsabrufinformationen, die in einer Verfolgung eingefangen werden, wiederherzustellen. Dieses Verfahren war im wesentlichen billiger zu implementieren als das Hardware-Verfahren der Warteschlangenauflösung, wies jedoch schwerwiegende Genauigkeitsprobleme auf. Ein Hauptgrund für die Verschlechterung der Genauigkeit war die Schwierigkeit bei der Warteschlangenauflösung von Befehlen einer Verzweigung oder einer bedingten Verzweigung, da Verzweigungen in einem Warteschlangen-Mikroprozessor mehrere unbenutzte Befehlsabrufe verursachten, was die Ausführung von Befehlen in einer von der Befehlsabrufreihenfolge unterschiedlichen Reihenfolge zur Folge hatte. Andere Befehle schlossen Einzelworte, Doppelworte oder lange Worte (Vierfachworte) und Befehle ein, die ein Argument (einen Operand), der zu dem Befehl gehört, aufwiesen (wie in einem Befehl "addiere Konstante"). Da die Decodierung der Befehlsabrufinformationen typischerweise an einem Punkt begann, der von dem Benutzer in dem Zielprogramm ausgewählt wurde, gab es kein Verfahren zum Bestimmen dessen, daß das erste Wort auch der Beginn eines Befehls war. Wenn das erste Wort nicht der Beginn eines Befehls war, würde die Warteschlangenauflösungs-Vorrichtung dasselbe ungeachtet dessen als den Beginn eines Befehls interpretieren. Das häufige Ergebnis bestand darin, daß die decodierten Befehlsabrufinformationen wenig Ähnlichkeit mit dem trugen, was tatsächlich in dem Zielprogramm von dem Prozessor ausgeführt wurde. Folglich war die "Software-Warteschlangenauflösungs"-Lösung extrem unzuverlässig, obwohl dieselbe weniger aufwendig als die "Hardware-Warteschlangenauflösungs"-Lösung war.
Die US-A-4205370 offenbart ein Datenverarbeitungssystem, das Einrichtungen aufweist, die wirksam sind, wenn das System während der Verarbeitung von Programmbefehlen in einem Verfolgungsmodus konditioniert ist, um den Operationscode jedes Befehls aufzuzeichnen, der durch den Bitinhalt einer Tabelle, auf die vor dem Beginnen der Befehlsausführung verwiesen wurde, als ausführbar bezeichnet wurde. Wenn der Operationscode eines Befehls durch die Tabelle als nicht ausführbar bezeichnet ist, fängt das System den Befehl ein und erzeugt einen Aufruf an die Betriebssystemsoftware, ohne den Operationscode desselben aufzuzeichnen. Das selektive Aufzeichnen und Einfangen von Befehls-Operationscodes erleichtert die Diagnose von Programmfehlern oder Fehlern in dem System. Dies ist besonders wertvoll, wenn das System eine Emulationsvorrichtung einschließt, die nicht in jedem Detail mit dem System, das emuliert wird, kompatibel sein muß.

Zusammenfassung der Erfindung

Die Merkmale der Erfindung sind durch die jeweiligen Ansprüche 1 und 5 definiert.
Gemäß dem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung ist die verbesserte Befehlsanalyse in Emulatoren die Folge des Vorsehens eines zusätzlichen Speichers in einem Emulator, der Marken hält, die gemäß einem vorbestimmten Codierschema, das den Instruktionen von einem Zielprogramm entspricht, bestimmt sind; die Marken liefern der Zentralsteuerung des Emulators während der Befehlsanalyse zusätzliche Zustandsinformationen für eine genauere Umwandlung der Zustandsinformationen, die während der Zielprozessorausführung des Zielprogramms erzeugt werden, in eine Liste von Zuständen, die dem Testprogramm entsprechen, das von der Zielprozessoreinrichtung ausgeführt wird.
Das Markierungssystem kann auf einen beliebigen Prozessor und gemäß einem beliebigen vorbestimmten Codierungsschema angewendet werden, derart, daß die maximalen Ergebnisse mit einem minimalen zusätzlichen Aufwand erreicht werden können.
Der zusätzliche Speicheraufwand und die notwendige Software zur Markierung sind gering, wodurch ein Vorteil über die bekannte Hardware-Warteschlangenauflösungs-Lösung, die einen relativ hohen Aufwand aufweist, geschaffen wird; während die Genauigkeit der resultierenden Verfolgungsinformationen der der Hardware-Warteschlangenauflösungs-Lösung nahekommt, liefert dieselbe einen Vorteil über die bekannte Software-Warteschlangenauflösungs-Lösung.

Kurze Beschreibung der Zeichnungen

Fig. 1 ist ein Blockdiagramm eines typischen auf einem Mikroprozessor basierenden Entwicklungssystems (Zielsystem).
Fig. 2 ist ein Blockdiagramm eines Emulationssystems (Emulator).
Fig. 3 ist ein Blockdiagramm, das ein Emulationssystem zeigt, welches mit einem auf einem Mikroprozessor basierenden Entwicklungssystem verbunden ist.
Fig. 4 zeigt ein Blockdiagramm des bevorzugten Ausführungsbeispiels eines Emulators mit einer Markierungshardware.
Fig. 5 zeigt ein Flußdiagramm des Markierungssoftware-Optionsmoduls.
Fig. 6 zeigt ein Flußdiagramm des Markierungssoftware-Syntax-Moduls.
Fig. 7 zeigt ein Flußdiagramm des Markierungssoftware-Zustandsmaschinenmoduls.
Fig. 8 zeigt ein Flußdiagramm des Markierungssoftware-Zerlegungsmoduls.

Detaillierte Beschreibung des bevorzugten Ausführungsbeispiels

Fig. 4 zeigt ein Blockdiagramm des bevorzugten Ausführungsbeispiels eines Emulators mit einer Markierungshardware. Die Beschreibung jedes Blocks wird nachfolgend geliefert.

Zentralsteuerungs-Decodierugsblock 24

Dieser Block empfängt Zentralsteuerungsbefehle und erzeugt geeignete Signale für verschiedene Blöcke in dem Emulator. Wenn z.B. ein Marken-Laden-Befehl zu diesem Block gesendet wird, wird derselbe ein Schreiben-Übernahmesignal zu einer Dualtor-Zugriffssteuerung 34, ein Markenadreß-Blocksignal zu dem Adreßauswahlblock 40 und ein Freigabesignal zu dem Markenspeicherblock 38 erzeugen. Dieser Block liest ferner den Zustand von dem Steuerregister und dem Zustandsblock 28 und kann Informationen in das Steuerregister desselben Blocks schreiben.

ROM-Modul 26 (Emulator-spezifisch)

Dieser Block enthält die gesamte Emulator-spezifische Software, die notwendig ist, um den Emulator zu betreiben. Z.B. liegt die gesamte Markierungs-spezifische Software in diesem ROM vor, ebenso wie die Software, um Unterbrechungen zu erzeugen, Register zu lesen, den Emulator zu konfigurieren, usw..

Steuerregister und Statuspuffer 28

Dieser Block enthält das Emulatorsteuerregister, das den Emulator für verschiedene Betriebsmodi konfiguriert. Z.B. enthält derselbe das Rücksetzsignal, welches den Emulator in einen initialisierten (rückgesetzten) Zustand versetzt, wenn das Signal aktiv ist. Dieser Block enthält ferner das Statusregister, das zu einer beliebigen Zeit von dem Zentralsteuerungs-Decodierblock 24 gelesen werden kann, um zu bestimmen, in welchem Zustand der Emulator ist (z.B. im Vordergrund laufend oder in den Hintergrund zurückgesetzt).

Analysator 30

Dieser Block empfängt die Adressen, Daten und den Status, die von dem Prozessor 52 (80C196) ausgegeben werden, zur Speicherung und späteren Ausführung. Er empfängt ferner die Marken, die von dem Markenspeicher ausgegeben werden, welche wesentliche Informationen über den Operationscode-Standort liefern.

Zentraldaten-Puffer/Latchs 32

Dieser Block arbeitet in Verbindung mit der Dualtor-Speicherzugriffssteuerung, um zu ermöglichen, daß die Zentralsteuerung auf den gleichen Speicher zugreift, auf den der Prozessor 52, der bei diesem Ausführungsbeispiel ein 80C196 ist, zugreifen kann. Er puffert und speichert Zentralsteuerungsdaten zu den verschiedenen Speicherblöcken zur Verwendung zur geeigneten Zeit zwischen.

Dualtor-Zugriffssteuerung 34

Dieser Block bestimmt die Zugriffe von der Zentralsteuerung und dem Prozessor 52, derart, daß beide einen Zugriff zu den verschiedenen Speicherblöcken, wie z.B. dem Emulationsspeicher 36 und dem Überwachungsspeicher 42, erlangen können. Er erzeugt die Lesen- und Schreiben-Übernahmesignale zu den Speicherblöcken und erzeugt ferner die erforderlichen Zeitgebungs-Wartesignale zurück zu den abfragenden Blöcken.

Emulationsspeicher 36

Dieser Block enthält den Speicher, der verwendet wird, wenn der Prozessor im Vordergrund-Emulationsspeicher läuft.

Markenspeicher 38

Dieser Block enthält den Speicher, der verwendet wird, um die Markenkennungen zu halten. Dieser Speicher wird ausschließlich durch den Zentralsteuerungs-Decodierblock 24 geladen (der 80C196-Prozessor 52 kann nicht auf denselben schreiben) und wird ausschließlich durch den Analysator 30 gelesen. Der Zentralsteuerungs-Decodierblock 24 lädt die Markenkennungen in spezifische Adressen des Markenspeichers 38, derart, daß, wenn der Prozessor 52 identische Adressen ausgibt, die gewünschten Markenkennungen zu dem Analysator 30 gesendet werden. Der Markenspeicher 38 wird auf Null-Kennungswerte (unmarkiert) initialisiert, wenn der Emulator initialisiert wird, oder wenn ein Emulationsspeicherort modifiziert wird, nachdem er markiert wurde.

Adreßauswahlblock 40

Dieser Block arbeitet in Verbindung mit der Dualtor-Zugriffssteuerung 34, um den verschiedenen Speicherblöcken zu den geeigneten Zeiten gültige Adressen zu liefern. Er wird den richtigen Speicherblock, um in denselben zu schreiben, und die für diesen Block geeignete Adresse auswählen.

Überwachunasspeicher 42

Dieser Block enthält den Speicher, der verwendet wird, wenn der Prozessor 52 im Hintergrund-Emulationsspeicher läuft. Dieser Speicher enthält den Überwachungscode und enthält den Kommunikationsspeicherbereich, der verwendet wird, um mit der Zentralsteuerungs-Decodierung 25 in Verbindung zu treten.

Überwachungsmarkenspeicher 44

Dieser Block enthält Marken, die für einen ordnungsgemäßen Betrieb des Überwachungsgeräts verwendet werden. Signale in diesem Speicher 44 steuern Zugriffe zu dem Vordergrundspeicher während sie in dem Überwachungsgerät sind, und steuern ferner das Verlassen des Überwachungs-(Hintergrund-)Zustands.

Abdeckungsspeicher 46

Dieser Speicherblock enthält Informationen über den Adreßstandort-Zugriffsstatus. Er kann durch den Zentralsteuerungs-Decodierungsblock 24 rückgesetzt werden.

Prozessor-Daten-Puffer/Latchs 48

Dieser Block arbeitet in Verbindung mit der Dualtor-Speicherzugriffssteuerung 34, um zu ermöglichen, daß der 80C196-Prozessor 52 auf den gleichen Speicher zugreift, auf den die Zentralsteuerungs-Decodierung 24 zugreifen kann. Er puffert und speichert Daten des Prozessors 80C196 zu den verschiedenen Speicherblöcken zur Verwendung zu der geeigneten Zeit zwischen.

Prozessorübernahmesignal-Generator 50

Dieser Block fängt die Prozessorübernahmesignale ab, um Übernahmesignale mit einer geeigneteren Zeitgebung und Funktion zur Verwendung durch den Emulator zu erzeugen, wie z.B. Zeitgebungs-Übernahmesignale für die Dualtor-Zugriffssteuerung 34 und für den Analysator 30.

Prozessor 52 (80C196)

Dies ist der Zielprozessor, der das Zielprogramm ebenso wie die Überwachungs- und weitere Funktionen ausführt.

Unterbrechungssteuerung

Dieser Block kann eine Unterbrechung der Ausführung des Benutzercodes zu gewünschten Zeiten bewirken, um eine Überwachung der Register und des Speichers durchzuführen, oder um eine Modifikation des gegenwärtigen Zustands des 80C196-Prozessors 52 durchzuführen. Die Unterbrechung wird sorgfältig ausgeführt, so daß eine Wiederherstellung des gegenwärtigen Zustands erreicht werden kann, wenn der Überwachungs-(Hintergrund-)Zustand verlassen wird.

Torwiederholung 54

Dieser Block simuliert den Betrieb der Toranschlußstifte des Prozessors 80C196, indem die interne Funktionalität des Prozessors 52 vervielfältigt wird. Dies ermöglicht es, daß die Emulator-Benutzersonde funktionsmäßig genauso wirkt wie der 80C196-Prozessor 52, während andere Funktionen in dem Emulator intern tatsächlich weiterlaufen.

Benutzersonde-Puffer/Latchs 58

Dieser Block führt die notwendige Speicheradreß/Datenbus- Steuerung durch, um eine Ausführung des Codes zu ermöglichen, der auf dem Zielsystem des Benutzers vorliegt (dem System, in das der Emulator eingesteckt ist).

Benutzersonde 60

Diese ist die physikalische Einheit, die eine Steckverbindung in das Zielsystem des Benutzers herstellt. Der Benutzer entfernt den Prozessor 80C196 von seinem Zielsystem und steckt die Benutzersonde 60 des Emulators an dessen Stelle.
Das bevorzugte Ausführungsbeispiel der Markierungshardware verwendet vier verschiedene Softwareblöcke zum Erzeugen und Interpretieren von Marken. Ein Optionsmodul ist verwendet, um verschiedene Optionen zur Verwendung bei der Erzeugung der Marken zu definieren. Zwei Module werden beim Erzeugen der Marken verwendet: ein Syntax-Modul zum Testen geeigneter Adreßbereiche; und ein Zustandsmaschinenmodul zum Gewinnen der Operationscode-Informationen, zum Erzeugen der Marken und zum Speichern der Marken an den geeigneten Orten im Speicher. Ein Markierungssoftware-Zerlegungsmodul ist das vierte Modul und wird zum Gewinnen der Marken und zum Verwenden derselben verwendet, um zerlegte Operationscode-Informationen zu erzeugen.
Fig. 5 zeigt ein Flußdiagramm des Optionsmoduls. Dieses Modul wird vor dem Zerlegen der Analysezustände durch den Inversassembler aufgerufen, um die verschiedenen Optionen, die von dem Benutzer ausgewählt werden, zu implementieren. Nach dem Zugreifen des Benutzers auf das Modul (Block 62), werden die Optionsvariablen überprüft, um zu bestimmen, ob eine Änderung der Inversassembler-Konfiguration (Block 64) durchgeführt wurde. Wenn die Optionsvariablen nicht gesetzt sind, wurde die Inversassembler-Konfiguration (Block 68) nicht geändert und das Optionsmodul endet (Block 70). Wenn die Optionsvariablen gesetzt sind, werden die Variablen überprüft, um zu bestimmen, ob die Optionen zulässig sind (Block 66). Wenn die Optionsvariablen nicht zulässig sind, wird die Inversassembler-Konfiguration nicht geändert (Block 72), wird dem Benutzer ein Fehler angezeigt und das Optionsmodul endet (Block 74). Wenn die Optionsvariablen gültig sind, werden die entsprechenden Inversassembler-Flag-Variablen geändert (Block 76) und das Optionsmodul endet (Block 78).
Fig. 6 zeigt ein Flußdiagramm des Syntax-Moduls. Wenn ein Markenbefehl implementiert ist, wird das Syntax-Modul aufgerufen (Block 80). Zuerst werden die Parameter des Befehls erfaßt (Block 82) und eine Überprüfung nach gültigen Adreßbereichen wird durchgeführt (Block 84). Wenn die Bereiche nicht gültig sind, wird der Befehl abgebrochen, dem Benutzer wird ein Fehler angezeigt, und das Syntax-Modul endet (Block 86). Wenn die Bereiche gültig sind, wird das Markierungssoftware-Zustandsmaschinenmodul aufgerufen (Block 88). Wenn das Zustandsmaschinenmodul von einem Problem in dem Zustandsmaschinenmodul eine Fehlerbedingung zurückgibt, wird dem Benutzer ein Fehler angezeigt und der Befehl wird abgebrochen (Block 90). Wenn von der Zustandsmaschine kein Fehler zurückgegeben wird, springt das Zustandsmaschinenmodul nach dem Plazieren der geeigneten Marken im Speicher für den Adreßbereich zurück. Das Syntax-Modul bestimmt, ob zusätzliche Speicherbereiche spezifiziert sind, die markiert werden sollen (Block 92). Wenn zusätzliche Speicherbereiche markiert werden sollen, wird die Gültigkeit der Bereiche bestimmt (Block 84). Wenn keine zusätzlichen Speicherbereiche markiert werden sollen, zeigt das Syntax-Modul dem Benutzer keinen Fehler und endet (Block 94).
Fig. 7 zeigt ein Flußdiagramm des Markierungssoftware-Zustandsmaschinenmoduls. Nachdem dieses Modul durch das oben beschriebene Syntax-Modul aufgerufen ist (Block 96), wird der Markenzeiger auf die Anfangsadresse für den Bereich der Adressen, die markiert werden sollen, oder die Startadresse initialisiert (Block 98). Der Lesezeiger wird ebenfalls auf die Startadresse initialisiert (Block 100). Die Operationscode-Informationen werden aus dem Standort gewonnen, der durch den Lesezeiger angezeigt wird (Block 102), und der geeignete Markencode wird durch Bezugnahme auf eine Nachschlagtabelle erzeugt (Block 104). Diese Nachschlagtabelle enthält ein vorbestimmtes Codierungsschema zum Markieren von Emulationsanalysezuständen. Bei diesem Ausführungsbeispiel wird angenommen, daß der Prozessor zwei Bytes für einen Befehlsabruf maximaler Größe verwendet, wobei drei Bits mit folgenden Definitionen zum Markieren verwendet werden:
000 - Null (wurde nicht markiert oder wurde beeinflußt)
001 - das niederwertige Byte ist der einzige Operationscode
010 - das höherwertige Byte ist der einzige Operationscode
011 - beide Bytes sind Operationscodes
100 - kein Byte ist ein Operationscode, sondern ist markiert (Operand)
Die übrigen Definitionen werden nicht verwendet. Wenn der Operationscode nicht gültig ist, wird der Markenbefehl abgebrochen, wobei dem Syntax-Modul ein Fehler zurückgegeben wird (Block 106). Wenn der Operationscode gültig ist, wird die bezeichnete Marke an dem Ort des Markenzeigers (Block 108) in den Markenspeicher geladen. Wenn die gewonnenen Operationscode-Informationen ein gültiger Nicht-Operationscode (Operand) sind, werden die Nicht-Operationscode-Markeninformationen an dem Ort des Markenzeigers in den Markenspeicher geladen (Block 108). Die Zeiger werden um den geeigneten Betrag, wie er in der Nachschlagtabelle vorgesehen ist, inkrementiert, welcher von der Byte-Größe des Operationscodes und des Operands abhängt, wenn einer vorliegt (Block 110). Dann werden die Zeiger mit dem Adreßbereich verglichen, um zu bestimmen, ob der Markenbefehl beendet werden soll (Block 112). Wenn der Bereich nicht abgeschlossen ist, springt das Zustandsmaschinenmodul zu dem früheren Schritt des Gewinnens der Operationscode-Informationen aus dem Leseort, der durch die gegenwärtige Position des Lesezeigers spezifiziert ist, zurück (Block 102) und fährt auf die gleiche Art und Weise fort, die oben aufgeführt ist. Wenn der Bereich abgeschlossen ist, zeigt das Zustandsmaschinenmodul dem Benutzer einen erfolgreichen Abschluß an und beendet den Markenbefehl und das Zustandsmaschinenmodul, wobei zu dem Syntax-Modul zurückgekehrt wird (Block 114).
Fig. 8 zeigt ein Flußdiagramm eines Markierungssoftware- Zerlegungsmoduls. Dieses Modul wird von dem Benutzer aufgerufen, wenn eine Verfolgung implementiert ist (Block 116). Das Zerlegungsmodul wird verwendet, um einen einzelnen Zustand zu zerlegen und wird durch ein Modul aufgerufen, das das Zerlegungsmodul für eine Reihe von Zuständen wiederholt aufrufen würde. Zuerst wird der Inversassembler initialisiert (Block 118). Die Options-Flag-Einstellungen werden gewonnen und überprüft, um zu bestimmen, ob für diesen Befehl eine Markierung freigegeben ist (Block 120). Wenn keine Markierung freigegeben ist, wird ein Software-Warteschlangenauflösungs-Verfahren (oder eine Busmodus-Zerlegung) angewendet, um den Operationscode oder den Operanden zu bestimmen (Block 122), und das Zerlegungsmodul wird beendet (Block 124). Wenn für diese Adresse eine Markierung freigegeben ist, werden die Markeninformationen gewonnen (Block 126). Wenn die gewonnenen Markeninformationen zeigen, daß für diese spezielle Adresse keine Marke vorliegt, wird die Busmodus-Zerlegung wie oben erörtert wurde, angewendet (Block 122). Wenn die gewonnenen Markeninformationen zeigen, daß für diese spezielle Adresse eine Marke vorliegt, wird bei diesem speziellen Ausführungsbeispiel die Marke überprüft, um zu bestimmen, ob es eine Nicht-Operationscode-Marke, eine normale Operationscode-Marke oder eine spezielle Operations-Marke ist (Block 126). Wenn die Marke eine Nicht-Operationscode-Marke ist, wird der Operanden-Abrufzustand gezeigt (Block 128) und das Modul endet (Block 130). Wenn die Marke eine spezielle Operationscode-Marke ist, z.B. eine Null-Operationscode-Marke, wird eine spezielle Markenzerlegung angewendet, um den Operationscode zu bestimmen und zu zeigen (Block 132) und das Modul wird beendet (Block 134). Wenn die Marke eine Standard-Operationscode-Marke ist, wird eine Operationscode-Zerlegung angewendet, der zerlegte Operationscode wird gezeigt (Block 136) und das Modul wird beendet (Block 138).
Ein Beispiel einer Markierung ist geschaffen, das den Code (in "C" programmiert), der verfolgt wird, zeigt, dann die tatsächliche Sequenz von Befehlen, die ausgeführt wird, eine Verfolgungslistenanzeige mit einer freigegebenen Markierung und eine Verfolgungslistenanzeige mit einer nicht freigegebenen Markierung, ähnlich der bekannten Software-Warteschlangenauflösungs-Lösung.
Die zwei gezeigten Verfolgungsprotokolle stammen von identischen Prozessorschritten, wobei bei dem ersten eine Markierung freigegeben ist, und bei dem zweiten eine Markierung nicht freigegeben ist. Der Code, der verfolgt wird, lautet wie folgt:
Die tatsächliche Befehlssequenz lautet:
Beispiel der Verfolgung mit freigegebener Markierung
Beispiel der Verfolgung mit nicht freigegebener Markierung
Das Verfolgungsprotokoll mit freigegebener Markierung liefert eine sehr genaue Darstellung der tatsächlichen Befehle, die in der ordnungsgemäßen Sequenz ausgeführt werden. Die Narkierungskennungen liefern zusätzliche Zustandsinformationen für eine Verwendung während der Umwandlung in eine Liste von Zuständen, die dem Testprogramm entspricht, das von der Zielprozessoreinrichtung ausgeführt wird.
Im Gegensatz zu dem Verfolgungsprotokoll mit freigegebener Markierung fehlen dem Verfolgungsprotokoll mit nicht freigegebener Markierung ausreichende Informationen, um die Zustandsinformationen korrekt in eine Liste von ausgeführten Befehlen umzuwandeln. Die Verfolgung begann bei einem Nicht-Operationscode-Abruf in Zeile 4 und zerlegt das unausgeführte Byte als einen ausgeführten AND-Befehl und überspringt den ersten Befehl JE (jump if equal = springe wenn gleich). Schließlich erholt sich das Verfolgungsprotokoll in Zeile 8 und identifiziert den Befehl LDB (load register = lade Register) korrekt. Jedoch treten in den Zeilen 13 und 14 erneut Fehler auf. Das Ergebnis besteht darin, daß es für den Benutzer schwierig ist, Kenntnis davon zu haben, wann das Verfolgungsprotokoll zuverlässig ist und wann nicht. Die Verwendung der Markierung liefert eine stark verbesserte, wenn auch nicht perfekte, Zuverlässigkeit.

Claims

1. Vorrichtung zur Verwendung bei der Befehlsanalyse, die eine Verfolgung, um Zustandsinformationen für jeweilige Befehle zu erfassen, die in einem zu testenden Programm ausgeführt werden, und eine Warteschlangenauflösung, um aus den Zuständen, die durch die Verfolgung erfaßt werden, eine Befehlsausführung wiederzugewinnen verwendet, wobei die Vorrichtung folgende Merkmale aufweist:

einen Speicher (38) zum Speichern von Marken, die die Orte der Codes darstellen, die den jeweiligen Befehlen in dem Programm zugeordnet sind;

einen Zielprozessor (52) zum Ausführen des Programms;

eine Einrichtung (30) zum Empfangen verfolgter Informationen von dem Zielprozessor (52) und von Marken von dem Speicher (38); und

eine Zentralsteuerung (24), die mit der Einrichtung (30) zum Empfangen der verfolgten Informationen und dem Speicher (38) verbunden ist; wobei die Zentralsteuerung (24) zum Zerlegen der verfolgten Informationen, zum Zuordnen von Marken zu den jeweiligen Befehlen und den auf dieselben bezogenen Zustandsinformationen und zum Speichern der Marken in dem Speicher (38) vorgesehen ist; wobei die Zentralsteuerung (24) ferner die Warteschlangenauflösung mit der Unterstützung der Zustandsinformationen, die den Marken, die in dem Speicher (38) gespeichert sind, zugeordnet sind, durchführt.

2. Die Vorrichtung gemäß Anspruch 1, bei der die Zustandsinformationen eine Adresse, Daten und Statusinformationen aufweisen.

3. Die Vorrichtung gemäß Anspruch 1, bei der die Codes Operationscodes sind.

4. Vorrichtung gemäß Anspruch 2, bei der jeder Zustand mindestens zwei Bytes aufweist und bei der die Marken eine Anzeige der Anzahl von Bytes, die einen Zustand bilden, liefert.

5. Ein Verfahren zur Verwendung bei einer Befehlsanalyse, das eine Verfolgung, um Zustandsinformationen für jeweilige Befehle, die in einem zu testenden Programm ausgeführt werden, zu erfassen, und eine Warteschlangenauflösung verwendet, um eine Befehlsausführung aus den Zuständen, die durch die Verfolgung erfaßt werden, wiederzugewinnen, wobei das Verfahren folgende Schritte aufweist:

Zuordnen von Marken, die die Orte von Codes darstellen, zu jeweiligen Befehlen und den auf dieselben bezogenen Zustandsinformationen;

Speichern der Marken;

Durchführen der Verfolgung während der Ausführung des Programms;

Zerlegen der verfolgten Informationen; und

Durchführen der Warteschlangenauflösung mit der Unterstützung der Zustandsinformationen, die den gespeicherten Marken zugeordnet sind.

6. Das Verfahren gemäß Anspruch 5, bei dem die Zustandsinformationen eine Adresse, Daten und Statusinformationen aufweisen.

7. Das Verfahren gemäß Anspruch 5, bei dem die Codes Operationscodes sind.

8. Das Verfahren gemäß Anspruch 6, bei dem jeder Zustand mindestens zwei Bytes aufweist, und bei dem die Marken erzeugt werden, um eine Anzeige der Anzahl von Bytes, die einen Zustand bilden, zu liefern.