DE69414985T2

DE69414985T2 - Verzweigungsentscheidungskodierung

Info

Publication number: DE69414985T2
Application number: DE69414985T
Authority: DE
Inventors: Ricke Waylan Irvine California 92714 Clark; Dale Eugene Placentia California 92670 Folwell; Donald Dean Placentia California 92670 Harenberg
Original assignee: Rockwell International Corp
Current assignee: Boeing North American Inc
Priority date: 1993-11-23
Filing date: 1994-09-09
Publication date: 1999-07-08
Anticipated expiration: 2014-09-10
Also published as: JP2824828B2; DE69414985D1; US5473754A; EP0655684A1; JPH07200348A; EP0655684B1

Description

Hintergrund der Erfindung

Diese Erfindung bezieht sich auf Mittel zur Verifizierung eines Programmflusses in einem nicht zugänglichen Computerprozessor. Sie sind in einen Entstöranschluß bzw. "Debug"-Anschluß eingebaut bzw. darin aufgenommen, der wiederum in die interne Logik eines Einzelchip-Signalprozessors mit reduziertem Instruktionssatz, die RSP-Vorrichtung genannt, eingebaut ist. Sie werden anstelle eines Logikanalysierers verwendet, da der interne Programmadressenbus der Vorrichtung an ihrer Schnittstelle nicht verfügbar ist.
Bisher wurden Logikanalysierer als das Primärwerkzeug für bzw. beim Fehlersuchen oder "trouble shooting" bei der Digitalcomputerhardware verwendet. Jedoch mit dem Aufkommen von hochparallelen (englisch: highly pipelined) Einzelchipprozessoren mit weiten Daten- und Adreßbussen wird es unausführbar bzw. unpraktisch, alle notwendigen Busse für Hardware- und Programmfehlersuche bzw. "trouble shooting" zu der Schnittstelle der Vorrichtung zu bringen. Des weiteren ist es nicht möglich, all die Daten zu multiplexen bzw. zu vervielfachen, die man an einem Ausgabebus für diesen Zweck als brauchbar finden würde, wenn in einer Echtzeitprogrammumgebung entstört wird.
Diese Probleme werden auch in Vorrichtungen der nächsten Generation aufwarten, die begrenzte externe Leitungen haben, Geschwindigkeiten verwenden, die alle physikalischen Grenzen erreichen und bei denen ein Zugriff zu mehr und weiteren Bussen erforderlich ist.
Weitere Information in Bezug auf den Stand der Technik können in Computer, Vol. 26, no. 5, Mai 1993, Long Beach US, Seiten 52.61, James R. Larus 'Efficient Program Tracing' gefunden werden, wo die historischen Schwierigkeiten und technischen Vorgehensweisen für die Erfassung detaillierter Programmspuren referiert bzw. in Übersicht zusammengefaßt sind und wo des weiteren auf die neuen Techniken und Ergebnisse für effiziente Programmnachvollziehung (program tracing), insbesondere auf Compiler basierendes Programm nachvollziehen, fokussiert wird.

Zusammenfassung der Erfindung

Ein Entstör- bzw. "Debug"-Anschluß ist in der RSP-Vorrichtung aufgenommen, und zwar als ein Hardwareentstör- und Softentwicklungswerkzeug. Er umfaßt viele der Merkmale von herkömmlichen Logikanalysierern, ist jedoch in der internen Logik der Vorrichtung aufgenommen, und zwar primär deswegen, weil die sehr hohen Geschwindigkeitsleistungscharakteristiken der Vorrichtung es erfordern, daß die meisten Operationen auf einer einzelnen Siliciumform bzw. einem einzelnen Siliciumwürfel enthalten sind. Das heißt, das ein Großteil der funktionalen Operation der Vorrichtung intern ist und daher nicht länger verfügbar für externe Entwicklungswerkzeuge ist. Daher sind Schlüsselinformationen innerhalb der internen Register und Speicher schlichtweg nicht verfügbar an den Schnittstellenpins der Vorrichtung und sie sind nicht einfach heraus zu vervielfachen bzw. zu multiplexen, und zwar in einer Echtzeitumgebung.
Der Entstöranschluß hat jedoch nahezu vollen Zugriff zu allen internen Bussen und kann Programmflußdaten ausgeben bzw. ausliefern, sowie auch andere Information, die von Programmierern und Vorrichtungs- bzw. Devicedesignern angefordert wird. Er ist jedoch zum Nachteil bezüglich der Siliciumfläche, jedoch wird erwartet, daß diese Fläche kleiner als 5% der Gesamtfläche der Vorrichtung bzw. des Devices ist.
Der eigens gewidmete Entstöranschluß löst viele der Probleme, die in Verbindung damit auftreten, daß man nicht in der Lage ist, einen angefügten Logikanalysierer zu verwenden, und zwar dahingehend, daß er die Eingabe von Auslöse-Erfassungszuständen zum Erfassen von Daten auf Bussen erlaubt, ohne die Echtzeitverarbeitung der Vorrichtung zu stören; und dahingehend, daß er erlaubt, Instruktionen in den Anweisungs- bzw. Instruktionsfluß der Vorrichtung einzugeben, was im allgemeinen die Inhalte von internen Registern und Speicherstellen auf Entstöranschlußregister zur Ausgabe kopieren kann.
Jedoch hat der Entstöranschluß eine Begrenzung auf eine acht Bit weite Datenbusschnittstelle. Der Acht-Bit-Anschluß ist ein Kompromiß zwischen Entwicklungswerkzeug und Vorrichtungseingabe/-ausgabeerfordernissen. Aufgrund dieser Einschränkung ist es während einer Echtzeitprogrammentwicklung nahezu unmöglich, jeden Zustand des 24- Bit-Programmzählers zu überwachen, der sich bei jedem Instruktionszyklus bzw. Anweisungszyklus ändert, und zwar durch einen Anschluß, der nur ein Drittel so weit ist.
Die vorliegende Erfindung, wie sie in den Ansprüchen 1 und 3 dargelegt ist, löst dieses Problem, indem sie die sequentiellen Charakteristiken von Anwendungsprogrammen vorteilhaft ausnutzt. Da in den Zählschritten des Programmadreßzählers Diskontinuitäten auftreten, und zwar nur in einer begrenzten Anzahl von Situationen (d.h. Verzweigungen, Sprünge, Aufrufe von Subroutinen, Rückkehr von Subroutinen, Ausnahmen, Rückkehr von Ausnahmen, Fallen, Rückkehr von Fallen und Schleifenrückkehr zu den Anfängen von Schleifen), zieht der Entstöranschluß einen Vorteil aus dieser Tatsache und erfaßt Programmflußdaten nur dann, wenn bestimmte Diskontinuitäten auftreten. Als ein Ergebnis sind die Ausgabedaten stark reduziert.
Des weiteren sind alle einfachen Verzweigungen, d.h. jene, welche nur eine mögliche Zweigadresse haben, in ein Zweigentscheidungswort kodiert, und zwar entweder als eine "1" oder eine "0", da die nächste Anweisung, die nach der Verzweigung ausgeführt wird, und die Verzögerungsschlitzinstruktion (engl.: delay slot instruction), die immer folgt, entweder die Instruktion an einer spezifischen Zieladresse ist oder die Instruktion ist, die der Verzögerungsschlitzinstruktion folgt. Zur Beibehaltung der Synchronisation zwischen Anwendung- und Dekompressionsprogrammen wird die 24-Bit-Programmadresse immer dann ausgegeben, wenn ein Zweigentscheidungswort ausgegeben wird.
Der Entstöranschluß bzw. Debug-Anschluß liefert komprimierte Programmfluß- und andere Daten über den zuvor erwähnten 8-Bit-Bus aus. Der Bus erstreckt sich zu einem Schnittstellenmodul, welches die "hereinberstenden" Hochgeschwindigkeitsdaten auf eine niedrigere Rate puffert. Die Daten mit niedrigerer Rate sind dann zum Senden an die Arbeitsstation des Programmierers oder des Vorrichtungsentstörers geeignet, und zwar über einen Kleicomputersystemschnittstellen-(SCSI = small computer system interface)-Bus.
Zum Verständnis, wie Programmflußadreßdiskontinuitäten durch die Programmflußeinheit des Debug-Anschlusses gehandhabt werden, sind all ihre Ursachen in den drei folgenden Tabellen aufgelistet. Tabelle 1: Instruktionen und Merkmale, die Diskontinuitäten verursachen, die nicht von der Programmflußeinheit erfaßt werden

Tabelle 2: Instruktionen, die Diskontinuitäten verursachen, die in ein Zweigentscheidungswort kodiert werden

Verzweigung auf Zustandscode Verzweigung auf Registerübereinstimmung
Verzweigung auf Registerzustand Verzweigung nicht-null; postmodifizieren
Verzweigung auf Bit- Kippschaltung (toggle) und Falle direkt konditional Tabelle 3: Instruktionen/Merkmale, die das Erfassen von Programmflußadressen bewirken
Man beachte zuerst die den drei Tabellen zugewiesenen Titel und betrachte dann die ganz linke Spalte der Tabelle 1. Jede der Instruktionen in Gruppe A der Tabelle 1 bewirkt immer eine Diskontinuität in der Programmadresse, und zwar zur Zieladresse, die in den ausgeführten Verzweigungs-, Sprung-, Aufruf- oder Falleninstruktionen spezifiziert ist. Da die Diskontinuität immer auftritt und die Zieladresse Teil der Verzweigungsinstruktion ist und dem Programm bekannt ist, das die Programmflußdaten für den Benutzer dekomprimiert, werden keine Programmflußdaten erfaßt, wenn irgendeine dieser Instruktionen ausgeführt wird.
Man betrachte nun das automatische Schleifenrückkehrmerkmal, das in Gruppe B enthalten ist. Wenn die Instruktionen in einer Schleife mit n-Durchgängen durchgeführt sind, so gibt es für die ersten n-1-Durchgänge immer eine Diskontinuität nach der letzten Instruktion in der Schleife; und zwar zurück zum Anfang der Schleife. Für den n-ten Durchgang ist die nächste ausgeführte Instruktion immer die nächste sequentielle Instruktion nach der letzten Instruktion in der Schleife. Auch wenn die nächste Instruktion, die nach der letzten Instruktion in der Schleife ausgeführt wird, immer vorhersagbar ist, haben die Designer des Debug-Anschlusses sich entschieden, die Programmadresse nicht zu erfassen, wenn ein Rückschleifen zum Anfang einer Schleife vorliegt, jedoch haben sie sich dafür entschieden, die Programmadresse während des n-ten Durchgangs zu erfassen, wenn die nächste sequentielle Instruktion am Ende der Schleife erfaßt bzw. erhalten wird (siehe Tabelle 3, den Eintrag: Durchfallen am Ende einer Schleife).
Man betrachte nun die Starte-Schleife-Instruktion in Gruppe C. Eine Schleifenstartinstruktion wird zur Definition des Anfangs und der Länge einer Schleife verwendet, sowie der Anzahl der Durchgänge bevor durchgefallen wird. Da eine Schleifenstartinstruktion niemals eine Diskontinuität direkt nach ihrer Ausführung bewirkt (sie tritt am Schluß nach der Ausführung der letzten Instruktion der Schleife auf), werden keine Programmflußdaten erfaßt, wenn diese Instruktion ausgeführt wird.
Die Halt-Instruktion ist in dem RSP aufgenommen, um Leistung zu sparen, wenn die Vorrichtung nicht aktiv sein muß. Auch wenn sie keinen Sprung in der Programmadresse bewirkt, bewirkt sie doch, daß der Programmzähler damit aufhört, fortzuzählen und die Vorrichtung damit aufhört, zu operieren. Programmflußdaten werden nicht erfaßt aufgrund der Ausführung der Halt-Instruktion.
Die Instruktionen in Tabelle 2 sind alle konditionale Instruktionen. Ausführung irgendeiner dieser Instruktionen kann eine Diskontinuität bewirken (und zwar zu einer spezifizierten Zieladresse), wenn eine bestimmte Bedingung angetroffen wird; oder sie kann die Ausführung der nächsten sequentiellen Instruktion bewirken, wenn die Bedingung nicht angetroffen wird. Für diese Instruktionen kodiert der Debug-Anschluß ein Verzweigungsentscheidungswort mit einer "1", wenn eine Diskontinuität auftritt, und mit einer "0", wenn sie nicht auftritt.
Die ganz linke Spalte (Gruppe A) der Tabelle 3 listet alle die indirekten Instruktionen der Vorrichtung auf. Wenn irgendeine dieser Instruktionen ausgeführt wird, wird eine berechnete Adresse aus einem spezifizierten Register ausgelesen und zum Erfassen der Instruktion verwendet, die nach einer Verzögerungsschlitzinstruktion ausgeführt wird. Da die Zieladresse berechnet wird, und in den meisten Fällen nicht leicht vorhersagbar ist, erfaßt die Programmflußeinheit immer die Zieladresse für diese Instruktionen, wenn sie auf den Programmadreßbus gegeben wird.
Die normalen und schnellen Ausnahmen sind in der Gruppe B der Tabelle 3 aufgelistet, treten aufgrund von Signalen auf, die aufgrund von Anfrageservicen von I/O-Einheiten erzeugt werden, und sie treten auf aufgrund von Signalen von arithmetischen Kerneinheiten auf, die das Auftreten von Fehlern signalisieren.
Wenn die RSP-Vorrichtung auf ein Ausnahmesignal von einer I/O-Einheit antwortet, hält sie die Verarbeitung ihrer gegenwärtigen Aufgabe an und springt zu einer nicht in Beziehung stehender Ausnahmeroutine, um möglicherweise Daten von einem Eingaberegister zu lesen, oder Daten auf ein Ausgaberegister zu schreiben bevor sie zur Beendigung der Aufgabe zurückkehrt. In Signalverarbeitungsanwendungen müssen Eingabe/Ausgabeaufgaben für gewöhnlich periodisch durchgeführt werden, um einen Verlust von Daten zu vermeiden.
Wenn die Vorrichtung auf ein Ausnahmesignal von ihrem arithmetischen Kern antwortet, hält sie ebenso an und springt zu einer Ausnahmeroutine. Jedoch wird diese Ausnahmeroutine wahrscheinlich dafür verwendet, um eine Aufgabe durchzuführen, die zu der Bedingung in Bezug steht, die den Aufruf der Ausnahmeroutine bewirkte, sowie die Korrektur des Fehlers oder eine Benachrichtigung eines Benutzers über sein Auftreten.
Da Ausnahmeroutinen in Bezug stehen können oder nicht in Bezug stehen können zu der gegenwärtig durchgeführten Aufgabe, kann der Programmierer die Programmflußdaten als weniger verwirrend finden, wenn er/sie das Erfassen von Ausnahmediskontinuitäten in einigen Situationen ermöglichen kann (im allgemeinen wenn bestimmt werden soll, ob ein arithmetischer Fehler richtig korrigiert ist), und ihre Erfassung in anderen Situationen abgeschaltet werden kann (im allgemeinen, wenn zahlreiche I/O-Ausnahmen auftreten).
In der zweiten Spalte der Tabelle 3 stehen NEXCE und QEXCE für das Ermöglichen der Erfassung von Programmdiskontinuitäten für normale bzw. schnelle Ausnahmen. Man beachte, daß QEXCE die Erfassung von Programmdiskontinuitäten sowohl beim Eintritt als auch beim Verlassen von Schnellausnahmenroutinen einschaltet/ausschaltet, wogegen NEXCE ihr Erfassung nur dann einschaltet/ausschaltet, wenn in Normalausnahmeroutinen eingetreten wird. In der RSP-Vorrichtung wird eine Instruktion verwendet, um die Rückkehr von sowohl Fallen als auch Normalausnahmen zu befehlen. Aufgrund dieser Tatsache haben die Designer des Debug-Anschlusses sich dafür entschieden, Diskontinuitäten immer zu berichten, die auftreten, wenn Normalausnahmeroutinen verlassen werden, um das Vorhandensein von getrennten Instruktionen zu vermeiden, und zwar eine für die Rückkehr von Fallen und eine zweite für die Rückkehr von Normalausnahmen.
Als das Merkmal "automatische Schleifenrückkehr zum Anfang einer Schleife" in Bezug auf Tabelle 1 zuvor beschrieben wurde, wurde bemerkt, daß Programmadreßdiskontinuitäten, die auftreten wenn eine Schleifenrückkehr zum Anfang einer Schleife auftritt, nicht berichtet werden, jedoch die Programmadresse berichtet wird am Ende der Schleife, wenn die Verarbeitung der Schleife vervollständigt ist.
Weder die Warte- noch die Pausenanweisung, und zwar in Gruppe D der Tabelle 3, bewirken eine Veränderung der Programmadresse, wenn sie durchgeführt werden; jedoch bewirken sie, daß der Programmzähler angehalten wird. Eine Warteanweisung ist ähnlich zur Halteanweisung, und zwar in Bezug darauf, daß sie Leistung spart. Die Warteanweisung bewirkt ein Anhalten der Taktgeber des arithmeti schen Kerns (Phase 1 bleibt an); jedoch werden die Taktgeber der I/O-Einheit laufen gelassen. Der Debug-Anschluß wird die Programmadresse erfassen, wenn eine Warteinstruktion ausgeführt ist.
Eine Pauseninstruktion wird während einer Programmentstörung verwendet, um eine Ausführung anzuhalten, so daß eine Anzahl von Registern/Speicherstellen geprüft werden kann, um ihre Werte/Zustände an diesem Punkt im Programm zu bestimmen. Der Debug-Anschluß erfaßt ebenso die Programmadresse, wenn eine Pauseninstruktion ausgeführt wird.
Die Programmflußeinheit des Debug-Anschlusses umfaßt 6 wesentliche Register. Dies sind: Das 24-Bit-Programmadresserfassungsregister (PAC = program address capture); das 32-Bit-Zweigentscheidungsverschiebungsregister (BDR = branch decision register); das 8-Bit-Statusregister (STR.); der 24-Bit-Programmadresspuffer (PAB = program address buffer); der 32-Bit-Zweigentscheidungspuffer (BDB = branch decision buffer); und der 8-Bit-Statuspuffer (STB = status buffer).
Die PAB, BDB und STB sind Pufferregister. Sie halten Daten, die von den PAC-, BDR- bzw. STR-Registern kopiert wurden, und zwar bis die Daten auf den Debug-Anschlußausgabebus multiplext bzw. vervielfacht werden können zur Übertragung an den Ausgabefifo des Debug-Anschlusses.
Der PAB kopiert immer den gegenwärtigen Inhalt des PAC- Registers, und zwar gerade bevor das PAC-Register die Adresse am Programmadreß-(PA)-Bus der Vorrichtung erfaßt. Das PAC-Register erfaßt die Programmadresse, wenn einer der folgenden Fälle auftritt:
1. Eine Anweisung bzw. Instruktion ist ausgeführt oder eine Bedingung tritt ein, die den Pro grammfluß in einer unvorhersehbaren Weise ändert.
2. Das Zweigentscheidungsverschiebungsregister (BDR) füllt sich.
3. Eine Eingabenachricht spezifiziert, daß die Programmadresse erfaßt werden soll.
Die Kopier/Erfassungs-Steuerlogik für den PAB und PAC empfängt sieben Eingaben von benachbarten Logiken. Fünf der sieben Eingaben sind von der Instruktionsdekodiereinheit der RSP-Vorrichtung. Diese Eingabe sind in der nachfolgenden Tabelle 4 aufgelistet.

Tabelle 4

Definition von Eingaben an die PAB/PAC-Kopier/Erfassungs- Steuerlogik

Signal Anweisung/Bedingung, die dekodiert wurde
rtn et Rückkehr von Normalausnahme oder Falle
exc sig Ausnahmesignal
gexc sig Schnellausnahmesignal
rt-qk Rückkehr von Schnellausnahme/Rückkehrsignal von Schnellausnahme
cp pa Indirekter Sprung/
Indirekter Sprung, ge-oder-te Registeradresse/
Indirekter Sprung, kombinierte Fahnenadresse/
Indirekter Sprung, ge-oder-te Registeradresse, konditional/
Indirekter Sprung, kombinierte Fahnenadresse, konditional/
Sprung durch Tabelle, ge-oder-te Registeradresse/
Sprung durch Tabelle, kombinierte Fahnenadresse/
Sprung durch Tabelle, ge-oder-te Registeradresse, konditional/
Sprung durch Tabelle, kombinierte Fahnenadresse, konditional/
Indirekter Aufruf/
Indirekte Falle/
Indirektekte Falle, konditional/
Rückkehr von Subroutinenaufruf/
Durchfallen am Ende einer Schleife/
Warten/Pause
Tabelle 4 zeigt, welche Instruktionen oder Bedingungen, die ein jedes der fünf Signale bewirken, die geltend gemacht werden sollen. Diese Instruktionen/Bedingungen sind auch in der Tabelle 3 aufgelistet und sind jene, die den Programmfluß dazu veranlassen in einer unvorhersehbaren Weise sich zu verändern.
Die zwei anderen Signale, die in die PAB/PAC-Steuerlogik eingegeben werden, sind später in der Fig. 2 gezeigt.
Es werden fünf Signale anstatt einem in die PAB/PAC-Kopier/Erfassungs-Steuerlogik eingegeben, weil einige ebenso als Statussignale durch das STR-Register eingegeben werden.
Das STR-Register enthält Information darüber, warum eine Programmadresse erfaßt wurde, und ob bestimmte Ereignisse seit der letzten Erfassung aufgetreten sind. Tabelle 5 listet die Bedeutung der Bits im STR-Register auf; und Tabelle 6 erstreckt sich über die Bedeutung der PFT-Bits in Tabelle 5. Tabelle 5 Tabelle 6 PFT-Bitdefinitionen
Das BDR-Register wird durch zwei Eingaben von der Instruktionsdekodiereinheit gesteuert. Das Signal sbr inst (simple branch instruction = einfache Zweigentscheidung) bewirkt, daß das BDR nach links verschiebt, wenn irgendeine einfache Zweigentscheidung ausgeführt wird. Das zweite Signal sbr tkn (simple branch taken = einfacher Zweig genommen) wird durch das letzte signifikante Bit des BDR kopiert, und ist eine "1", wenn der Zweig genommen ist, und eine "0", wenn er nicht genommen wurde.
Das BDR-Register wird durch den Reset bzw. das Rücksetzen der Vorrichtung bei einem Einschalten der Leistung initialisiert, und zwar mit den Bits 31-1 allen auf "0" und dem Bit 0 gleich "1". Es wird auf den selben Zustand reinitialisiert, wann immer sein Inhalt durch den BDC kopiert wurde. Das BDR ist voll, wenn die einzige "1", welche in das Bit 0 initialisiert wurde, bis zum Bit 31 verschoben wurde.
Jedesmal, wenn eine Programmflußerfassung eintritt, geschieht das folgende:
1. Der vorhergehende Inhalt des PAC wird in den PAB kopiert.
2. Der Inhalt des BDR wird in den BDB kopiert.
3. Der Inhalt des STR wird in den STB kopiert.
4. Das BDR wird reinitialisiert.
5. Die RC-(reference counter = Referenzzähler)- Bits im STR werden inkrementiert.
6. Einer der Serviceanfragen bd16.sr oder bd32.sr wird gesetzt, um Zeitschlitze am Ausgabebus des Debug-Anschlusses anzufordern, und zwar zur Bewegung der erfaßten Daten zum Ausgabe-FIFO.
Die 2-Serviceanforderungsausgaben bd16.sr und bd32.sr werden verwendet, um dem Ausgabebusschiedsrichter bzw. Ausgabebusentscheider des Debug-Anschlusses anzuzeigen, ob irgendwelche Zweigentscheidungsbits zuvor in die 16 signifikantesten Bits des BDR verschoben wurden. Wenn keine Bits in die obere Hälfte des BDR verschoben wurden, werden nur die 16 am wenigsten signifikanten Bits des BDB zum Ausgabe-FIFO kopiert.
Nachdem die Programmflußdaten in den Ausgabe-FIFO geschrieben wurden, werden sie dann zuerst zu einem Schnittstellenmodul geschickt und dann zur Festplatte einer Host-Workstation. Die Workstation dekomprimiert die Daten von ihrer Festplatte und zeigt die resultierenden Programmflußadressen zusammen mit dem Programmquellencode an.
Die Bitnummern, die in dieser Beschreibung verwendet werden, sind nur beispielhaft. Andere Registerweiten, Busweiten, usw. können leicht designt werden, um verschiedene Konfigurationen handzuhaben.

Kurze Beschreibung der Zeichnungen

Fig. 1 zeigt in Blockform den Debug-Anschluß, der in der RSP-Vorrichtung bzw. dem RSP-Device aufgenommen ist, und zwar mit einer Verbindung, die zu einer Host-Workstation über ein Schnittstellenmodul und zwei Verbindungsbusse führt.
Fig. 2 zeigt das RSP-Device, und zwar mit bedeutungsvollen Verbindungen zwischen dem Debug-Anschluß, Instruktionserfassungs-, Instruktionsspeicher- und Instruktionsdekodiereinheiten.
Fig. 3 zeigt den Debug-Anschluß, und zwar mit bezeichneten bzw. bedeutungsvollen Eingängen von externen Einheiten und mit bedeutungsvollen Verbindungen zwischen seinen Kommunikations-, Befehls- und Programmflußeinheiten.
Fig. 4 zeigt die Programmflußeinheit des Debug-Anschlusses, und zwar mit bedeutungsvollen Verbindungen zwischen ihren 6 Registern, der Steuerlogik, dem Ausgangsdatenmultiplexer und dem Ausgangsdatensequentierer.

Beschreibung eines bevorzugten Ausführungsbeispiels

In Fig. 1 ist die RSP-Vorrichtung bzw. das RSP-Device bei 11 gezeigt, und zwar mit dem Debug-Anschluß innerhalb des RSP-Devices bei 13 gezeigt.
Aufgrund der Hardwareeinschränkungen ist es nicht möglich, jede Programmadresse, die auf dem internen Programmadressenbus des RSP's auftritt, zu erfassen und auszugeben. Daher ist eine Primärfunktion des Debug-Anschlusses das Kodieren und Erfassen nur von den am meisten benötigten Mengen der Programmflußdaten, und zwar zur Übertragung zurück zur host work station des Programmierers.
In Fig. 1 werden die Programmflußdaten zur Workstation des Programmierers bei 17 über den Debug-Bus bzw. Ent störbus bei 14 durch das Schnittstellenmodul bei 15 und über den SCSI (small computer System interface = Kleincomputersystemschnittstelle)-Bus bei 16 gesendet. Nachdem die Programmflußdaten verarbeitet wurden, versucht die Workstation jede Programmadresse und den Quellencode des Programmierers bei 19 darzustellen, der den dargestellten Adressen entspricht, so daß er/sie feststellen kann, ob das Programm korrekt funktioniert.
Weil Programme mehrere komplexe Verzweigungsinstruktionen aufweisen können, und zwar eine direkt nach der anderen, ist es möglich, daß die Programmflußeinheit des Debug-Anschlusses nicht in der Lage ist, alle notwendigen Daten für die Workstation zu erfassen, um das Programm komplett zu rekonstruieren. Wenn dies eintritt, wird die Programmflußeinheit ein Überschreibungsbit in einem Ausgabestatusbyte markieren. Wenn das Rekonstruktionsprogramm das Überschreibungsbit sieht bzw. erkennt, wird es eine Diskontinuität in den dargestellten Daten zeigen.
Fig. 2 ist vorgesehen, um die bedeutungsvollen Schnittstellen zwischen dem Debug-Anschluß und anderen RSP-Einheiten zu zeigen, die verwendet werden, wenn Programmflußdaten kodiert und erfaßt werden. Die Instruktionserfassungseinheit bzw. Instruktionsholeinheit bei 20 erzeugt die Adresse der nächsten Instruktion, die ausgeführt werden soll. Diese Adresse wird auf dem Programmadreßbus bei 23 gegeben und vom Instruktionsspeicher bei 21 verwendet, um die nächste Instruktion zu holen. Der Instruktionsspeicher gibt die Instruktion auf den Programmdatenbus bei 24 aus. Der Instruktionsdekodierer bei 22 dekodiert die Instruktion und steuert ihre Ausführung in anderen Einheiten, die nicht gezeigt sind. Der Instruktionsdekodierer dekodiert ebenfalls bestimmte Instruktionen für den Debug-Anschluß und weist die geeigneten Leitungen zwischen den Einheiten zu, wenn diese Instruktionen auf dem Programmdatenbus vorliegen. Der L-Bus bei 25 wird für Befehle und Datenübertragung zwischen dem Debug-Anschluß und dem RSP-Kern verwendet.
Fig. 3 ist vorgesehen, um die 3 Einheiten innerhalb des Debug-Anschlusses zu zeigen, die in der Programmflußfunktion involviert sind.
Von den 3 Einheiten ist die Befehlseinheit bei 31 am wenigsten involviert. Die Befehlseinheit leistet zwei Funktionen. Eine ist das Einschalten/Ausschalten der Programmflußeinheit über die en pfu-(enable program flow unit = Programmflußeinheit einschalten)-Leitung. Die Befehlseinheit empfängt Einschalt- und Ausschalt-PFU-Befehle entweder vom Programmierer über den Debug-Anschlußeingangbus bei 40, dem Eingangsynchronisierer bei 33 und dem Debug-Bus bei 14; oder vom RSP-Kern (als ein Ergebnis einer Instruktionsausführung) auf dem L-Bus bei 25.
Die Befehlseinheit kann ebenso die Programmflußeinheit dazu anweisen, Programmadressen zu irgendeiner Zeit über die cap pa-Leitung zu erfassen. Sie dekodiert Erfassungsprogrammadreßbefehle (engl.: capture program address commands), die entweder vom Programmierer oder vom L-Bus eingegeben werden, und zwar über die selben Wege wie die Einschalt- und Ausschalt-PFU-Befehle.
Die Kommunikationseinheit bei 32 wird sowohl für die Eingabe von Befehlen und Daten zum Debug-Anschluß als auch für die Ausgabe von Programmfluß- und anderen Daten verwendet. Da der Debug-Bus bidirektional ist, wird ein Ausgangs-FIFO bei 35 mitaufgenommen, um Ausgangsdaten zu speichern, bis das Schnittstellenmodul bei 15 in Fig. 1 bereit ist, sie zu akzeptieren.
Weil mehrere Datenquellen möglicherweise Daten auf den Debug-Anschlußausgangsbus bei 41 simultan kopieren wol len, umfaßt die Kommunikationseinheit auch einen Ausgangsbusschiedsrichter bzw. Ausgangsbusentscheider bei 34. Sein Zweck ist es, alle erklärten Serviceanforderungen zu betrachten und jeder einen Zugang zum Bus zu gewähren, und zwar jeweils eine. Die Erlaubnis, Daten auf den Bus zu kopieren, wird über einen 5-Bitcode zugewiesen, der auf den Datenauswahlbus bei 42 geschrieben ist.
Fig. 4 zeigt die Programmflußeinheit selbst. Das BDR- (Branch Decision shift Register = Zweigentscheidungsverschiebungsregister)-Register bei 50 ist ein 32-Bit-Schieberegister, das nach links verschiebt, und zwar jedes Mal, wenn sein spr instr-Eingang erklärt wird. Wenn es verschiebt, kopiert es den Status des spr tkn-Eingangs. Daher, wenn eine einfache Zweigentscheidung (simple branch instruction, d.h. eine Instruktion in Tabelle 2) ausgeführt wird, wird eine "1" in das Register kodiert, wenn der Zweig genommen wird, und eine "0", wenn er nicht genommen wird.
Da Daten verloren gehen würden, wenn zu viele Zweigentscheidungen kodiert werden, werden Mittel vorgesehen, und zwar zur Detektion wenn das BDR voll ist. Das BDR wird initialisiert mit seinen 31-Bits ganz links als "0"-en und seinem ganz rechtem Bit bei "1". Wenn die anfängliche "1" detektiert wird, und zwar am bdr full-Ausgang an seinem linken Ende bei 60, weiß die Steuerlogik bei 56 dann, daß 31 Verschiebungen durchgeführt wurden, und seine Inhalte müssen auf den BDB (Branch Decision Buffer = Zweigentscheidungspuffer) bei 51 kopiert werden. Auch wenn das signifikanteste Bit des BDR niemals für die Speicherung von Zweigentscheidungen verwendet wird, schließt die Verwendung dieses Verfahrens eine Verwendung eines Zählers aus, um mit der Zahl der durchgeführten Verschiebungen Schritt zu halten. Und, da der Inhalt des BDR ebenso zu jeder Zeit auf den BDB kopiert werden kann, zeigt die Detektion der Position der anfänglichen "1" in den Ausgangsdaten an, wie viele Zweigentscheidungen umfaßt sind.
Da der Inhalt des BDR zu jeder Zeit auf den BDB kopiert werden kann, ist eine bdr half full-Anzapfung bzw. -Abzweigung bei 61 ebenso vorgesehen, um anzuzeigen, wenn 15 oder weniger Zweigentscheidungen kodiert wurden. Wenn dies der Fall ist, dann werden nur die 16 am wenigsten signifikanten Bits des BDR zur Workstation gesendet. Botschaften, die 16 Bits mit Zweigentscheidungsdaten enthalten, werden von jenen mit 32 Bits unterschieden, und zwar durch die Kopfzeile bzw. den Header, der der Botschaft durch einen Kopfzeilengenerator bei 36 in Fig. 3 vorangestellt ist. Die Programmflußeinheit signalisiert die Datenlänge an die Kommunikationseinheit bei 32, und zwar indem entweder die bd16 sr- oder die bd32 sr-Serviceanforderungsleitung bei 43 oder 44 erklärt bzw. zugewiesen werden, wenn die BDB, PAB & STB-Puffer Daten für die host work station enthalten.
Das PAC-(Program Address Capture = Programmadreßerfassung)-Register bei 52 wird zum Kopieren der Programmadresse vom Programmadreßbus bei 45 verwendet, wenn eine unvorhersagbare Diskontinuität im Programm eintritt (d.h. wann immer eine Instruktion oder Bedingung eintritt, die in Tabelle 3 aufgelistet ist).
Die 5 Eingänge bei 26 von der Instruktionsdekodiereinheit werden verwendet, um das Auftreten einer unvorhersagbaren Diskontinuität zu signalisieren. Wenn irgendeiner dieser Eingänge aktiv bzw. erklärt ist, bewirkt die Steuerlogik zuerst, daß der gegenwärtige Inhalt des PAC in den PAB kopiert wird, sowie der gegenwärtige Inhalt des BDR in den BDB kopiert und der gegenwärtige Inhalt des STR in den STB kopiert wird; dann bewirkt der PAC, daß der Programmadreßbus kopiert wird. Die Steuerlogik weist dann entweder die bd16 sr oder bd32 sr an, um zu signalisie ren, daß Daten bereit für die Ausgabe auf den Debug-Anschlußausgangsbus sind.
Die PAB-, BDB- und STB-Daten werden auf den Debug-Anschlußausgangsbus unter der Steuerung des Ausgangsdatensequenzierers bei 57 kopiert, wenn einer von zwei Codes auf dem Datenauswahlbus detektiert wird. Ein Code bewirkt, daß der Sequenzierer den PAB, STB und beide Hälften des BDB auf den Ausgangsbus kopiert, wogegen der zweite Code bewirkt, daß der PAB, STB und nur die untere Hälfte des BDB auf den Bus kopiert werden.
Da Daten von der Programmflußeinheit ausgegeben werden, entweder weil das BDR-Register voll wird, oder weil eine unvorhersagbare Diskontinuität eintritt, wird das 8-Bit- Statusbyte vom STR bei 55 immer mit den BDB- und PAC-Daten ausgegeben, um anzuzeigen, warum die Nachricht ausgegeben wird.
Die STR-Registerbits (die in den Tabellen 5 & 6 beschrieben wurden) umfassen auch ein Überschreibungsbit, das anzeigt, ob der PAB-Puffer überschrieben wurde, bevor seine Daten auf den Debug-Anschlußausgangsbus kopiert werden konnten, und weiter umfassen sie einen 2-Bitzähler, der inkrementiert wird, und zwar jedes Mal, wenn das PAC-Register eine Programmadresse kopiert. Der Zähler zeigt an, wie viele Überschreibungen aufgetreten sein können.
Während ein besonderes Ausführungsbeispiel in einigem Detail beschrieben wurde, ist der Umfang der vorliegenden Erfindung nicht darauf beschränkt, sondern er ist nur durch die angefügten Ansprüche umgrenzt.

Claims

1. Verfahren zum Erfassen und Kodieren von Programmflußdaten in einem Prozessor (11) über einen "debug"- oder Entstör-Anschluß (13) integriert in dem Prozessorchip (11) und verbunden mit seinem internen Programmadressenbus (23) und seinem Befehls- oder Instruktionsdekoder (22);

wobei der "debug"-Anschluß (13) nur diejenigen Programmflußdaten einfängt oder erfaßt, die zur Rekonstruktion des kompletten Programmflußes des Prozessors (11) an einer entfernt gelegenen Arbeitsstation (17) notwendig sind; wobei das Verfahren die folgenden Schritte vorsieht:

- wenn der Instrukionsdekoder (22) einen einfachen konditionellen Zweig der nur eine mögliche Zweigadresse besitzt signalisiert, so kodiert der "debug"-Anschluß (13) einen logischen Pegel in einer freien Bitposition eines Zweigentscheidungsregisters (50) wenn eine Diskontinuität auftritt, und den entgegengesetzten logischen Pegel, wenn dies nicht auftritt, wobei der Inhalt des Zweigentscheidungsregisters (50) zu der Arbeitsstation (17) übertragen wird, bevor alle Bit-Positionen gefüllt sind;

- wenn der Instruktionsdekoder (22) einen indirekten konditionalen Zweig oder eine Ausnahme signalisiert, dann erfaßt der "debug"- Anschluß (13) die entsprechenden Adressendaten von dem Programmadressenbus (45) und überträgt diese zu der Arbeitsstation (17);

- Ignorieren der nicht-konditionellen Zweige für eine feste Ziel- oder Targetadresse; und

- Akkummulieren der Zeigentscheidungsdaten und der Programmadressendaten an der Arbeitsstation (17) als komprimierte Programmadressendaten.

2. Verfahren nach Anspruch 1, wobei ferner der Schritt des Akkumulierens einer absolut neuen Adresse in einem weiteren Register (52) vorgesehen ist, immer dann, wenn ein Signal für das Erfassen oder Einfangen der Programmadressendaten empfangen wird.

3. Vorrichtung zum Erfassen oder Einfangen und Kodieren von Programmflußdaten in einem Prozessor (11), wobei die Vorrichtung folgendes aufweist:

einen "debug"- oder Entstörungsanschluß (13) integriert in dem Prozessorchip (11) und verbunden mit seinem internen Programmadressenbus (23) und seinem Befehls- oder Instruktionsdekoder (22);

wobei der "debug"-Anschluß (13) nur diejenigen Programmflußdaten erfaßt, die notwendig sind für die Rekonstruktion des kompletten Programmflußes des Prozessors (11) an einer entfernt gelegenen Arbeitsstation (17), wobei der "debug"-Anschluß folgendes aufweist:

- Mittel, wenn der Instrukionsdekoder (22) signalisiert, daß ein einfacher konditioneller Zweig nur eine mögliche Zweitadresse besitzt, zum kodieren eines logischen Pegels in einer freien Bitposition eines Zweigentscheidungsregisters (50) wenn eine Diskontinuität auftritt, und des entgegengesetzten logischen Pegels, wenn diese nicht auftritt, und zum Übertragen des Inhalts des Zweigentscheidungsregisters (50) zu der Arbeitsstation (17), bevor alle Bit-Positionen gefüllt sind;

- Mittel, wenn der Instruktionsdekoder (22) einen indirekten konditionalen Zweig oder eine Ausnahme signalisiert, zum Einfangen der entsprechenden Adressendaten von dem Programmadressenbus (45) und Transfer derselben zur Arbeitsstation (17);

- wobei die Mittel die nicht-konditionellen Zweige zu einer feste Zieldresse ignorieren;

und wobei die Vorrichtung ferner folgendes aufweist:

- Mittel zum Akkumulieren der Zweigentscheidungsdaten und der Programmadressendaten an der Arbeitsstation (17) als komprimierte Programmadressendaten.

4. Vorrichtung nach Anspruch 3, wobei ferner ein Programmzählerreferenzregister zum Empfang einer neuen Adresse als Bit-Formdaten angeschaltet ist, wenn ein Signal zum Einfangen oder Erfassen einer Adresse auftritt.

5. Vorrichtung nach Anspruch 4, wobei ferner Mittel (35) vorgesehen sind zum Akkumulieren der Bit-Formdaten zur Aufzeichnung.

6. Vorrichtung nach Anspruch 5, wobei ferner Registermittel (52), zum Akkumulieren einer absoluten neuen Adresse vorgesehen sind, wenn ein Befehl oder eine Instruktion zum Erfassen einer Adresse zum Einschluß in die komprimierten Adressendaten abgefühlt wird.