DE69226404T2

DE69226404T2 - Verfahren und Gerät zum Umwandlen von abstrakten Syntaxen auf hohem Niveau in eine Zwischenform

Info

Publication number: DE69226404T2
Application number: DE1992626404
Authority: DE
Inventors: Kiran Kumar Acton Massachusetts 01720 Sumalwar
Original assignee: Digital Equipment Corp
Current assignee: Digital Equipment Corp
Priority date: 1991-06-28
Filing date: 1992-06-19
Publication date: 1999-04-15
Anticipated expiration: 2012-06-20
Also published as: EP0520708A3; DE69226404D1; JPH05224949A; EP0520708B1; EP0520708A2

Description

GEBIET DER ERFINDUNG

Die vorliegende Erfindung betrifft allgemein eine Vorrichtung und ein Verfahren zum Umwandeln von Informationen von einer hohen Ebene einer Befehlscodierung zu einer mittleren Ebene bzw. einer Zwischenebene einer Befehlscodierung, und insbesondere eine Vorrichtung und ein Verfahren zum Umwandeln einer Abstrakt- Syntax-Form auf hoher Ebene, die auch Definitionen vom abstrakten Typ genannt werden und unter Verwendung der Abstrakt-Syntax-Notation-Eins (ASN.1)- Datentypspezifikationssprache beschrieben sind, in eine dazwischenliegende bzw. mittlere Form. Die mittlere Form wird dann auf eine interpretierende Weise in Anwenderprogrammen durch eine Berechnungsvorrichtung ausgeführt und/oder wird alternativ dazu in die ursprüngliche Form von abstrakten Typendefinitionen auf hoher Ebene zurückgewandelt.

HINTERGRUND DER ERFINDUNG

Es ist wünschenswert, Computerprogrammierern Programmierwerkzeuge an die Hand zu geben, welche die Fähigkeit bereitstellen, Computerbefehle in einer Form auf hoher Ebene zu schreiben. Die mit Programmierbefehlen in Form auf hoher Ebene verbundenen Vorteile werden durch derartige wohlbekannte Programmiersprachen auf hoher Ebene wie BASIC, PASCAL, FORTRAN, COBOL und C zur Verfügung gestellt. Aus der Sicht eines Programmierers sind Programmbefehle in der Form auf hoher Ebene für einen Menschen besser lesbar, weil sie allgemein mehr verkettete Programminformationen enthalten und typischerweise unserer gesprochenen Sprache enger folgen als niedrigere Formen codierter Befehle. Programme in der Form auf hoher Ebene sind daher einfacher zu überblicken. Weiterhin ermöglichen die konzentrierteren Informationen einem Programmierer, eine gegebene Funktion oder Prozedur derart zu spezifizieren, daß sie durch einen Computer unter Verwendung einer kürzeren Sequenz von Befehlen ausgeführt wird. Somit wird eine Anwenderprogramm-Eingabezeit reduziert. Aus diesen Gründen bevorzugen Programmierer allgemein die Verwendung der Formen hoher Ebene von Programmierbefehlen, die gemeinhin verwendete Sequenzen von weniger konzentrierten Befehlen auf niedrigerer Ebene darstellen.
Vom Gesichtspunkt einer Ausführung her ist es wünschenswert, eine Form eines Computerprogrammierbefehls zu schaffen, der der Form so nahe wie möglich kommt, die von der Computer-Hardware direkt zum tatsächlichen Durchführen der Sequenz von Befehlen verwendet wird, die durch das Programm bereitgestellt werden. Die niedrigste Form eines Computerprogrammierbefehls ist eine Gruppe von Bool'schen Werten, die in Gruppen von vorbestimmter Länge in Übereinstimmung mit der spezifischen Hardwarekonfiguration und dem Betriebssystem, die die Anwenderprogramme ausführen. Je näher die Form der Computer- Programmierbefehle dieser Form zur Verwendung im Computer kommt, um so schneller läuft das Programm auf dem Computer, da weniger Umwandlungen nötig sind, um die maschinenlesbare Form eines Befehls zu erhalten. Weiterhin verringert sich allgemein die Komplexität des Befehlsinterpretierersystems, das die Sequenz von Befehlen ausführt, wenn die codierten Computer-Programmierbefehle in niedrigere Formen aufgeteilt sind. Codierte Computer-Programmierbefehle auf niedrigerer Ebene sind auch in bestimmten Diagnoseprogrammsituationen wünschenswert, weil die niedrigere Form auch detaillierte Steuerinformationen zur Verfügung stellt, die sonst von der Form eines Codierens auf hoher Ebene nicht verfügbar sind.
Aus der vorangehenden Beschreibung bietet jede der verschiedenen Ebenen beim Codieren bei Computer-Programmierbefehlen einzigartige Vorteile, die die anderen nicht haben. Daher ist es für Programmierer vorteilhaft, Anwenderprogramme in der Form von Sprachen auf hoher Ebene zu erzeugen und dann die Beschreibung der Anwenderprogramme auf hoher Ebene in eine niedrigere Form für eine schnellere Ausführung der Anwenderprogramme auf einer spezifizierten Computer- Hardware und für verbesserte Diagnoseprogrammverfahren umzuwandeln. Aus diesem Grund sind Compiler formuliert worden, um codierte Programmierbefehle auf hoher Ebene in Befehle auf niedrigerer Ebene umzuwandeln. Jeder der zuvor aufgelisteten Programmiersprachen auf hoher Ebene ist ein Compiler oder Interpretierer zugeordnet, der die Programmierbefehle auf hoher Ebene in eine niedrigere Form zur Ausführung auf einem Computer umwandelt.
Umkehrungs-Compiler, nämlich Programme, die Computer-Programmierbefehle auf niedrigerer Ebene auf eine höhere Ebene umwandeln, sind ebenso bis zu einem eingeschränkten Ausmaß formuliert worden. Diese Umkehr-Compiler besitzen die Fähigkeit, ein erkanntes Muster von Computer-Programmierbefehlen auf niedrigerer Ebene in eine höhere Form umzuwandeln. Jedoch erzeugen viele Umkehr- Compiler eine Form auf höherer Ebene, die nicht identisch zu der Form auf höherer Ebene ist, die anfangs die Form auf niedrigerer Ebene erzeugte.
Codierschemen nach dem Stand der Technik sind zum Umwandeln von ASCII- codierten BASIC-Befehlen in einen Maschinencode formuliert worden, der wiederum auf eine Anfrage hin zurück zum ASCII-code umgewandelt wird. Dieses Codierschema ändert lediglich die Darstellung des Befehls und zerlegt oder ändert die Struktur oder das Format irgendeiner der Informationen nicht in eine effizientere Form zur Ausführung. Dieses Schema nach dem Stand der Technik zeigt lediglich ein Übersetzer- und nicht ein Compiler-Schema, welches Bezugsinformationen zusätzlich zum tatsächlichen übersetzten ASCII-Text speichert.
Es sind Compiler bekannt, die ASN.1-Abstrakt-Syntaxen in eine Zwischenform compilieren, wie beispielsweise Parser- bzw. Zerlegungstabellen. Die Parser- Tabelle ist die Datenstruktur, in der ein Parser-Baum gespeichert ist. Die Parser- Tabelle läßt man dann direkt unter der Steuerung von Laufzeitbibliotheken- und Unterprogrammen laufen. Ein weiterer bekannter Compiler wandelt ASN.1- Abstrakt-Syntaxen in C-Datenstrukturen um und erzeugt auch einen C- Programmiersprachencode, um die C-Datenstrukturen von und zu ASN.1- Grundcodierregel-(BER)-Werten zu codieren und zu decodieren. Jedoch wandeln diese früheren ASN.1-Compiler die Form auf hoher Ebene nicht in eine geeignete Zwischenform zum Ableiten der ursprünglichen Textform auf hoher Ebene aus der Zwischenform um.
Bei bekannten Syntaxen nach dem Stand der Technik erfordert das Compilieren von Sequenzen von Befehlen das Halten von wenigstens zwei Kopien der Programmsequenz - eine Kopie für jede Ebene des Programms - da es, mit wenigen Ausnahmen, allgemein nicht möglich ist, die ursprüngliche Form aus der compilierten Form wiederherzustellen. Die Unfähigkeit, die niedrigere maschinenausführbare Form wieder in die ursprüngliche höhere Ebene herzustellen, ist eine Folge des Nichtvorhandenseins spezifischer Strukturinformationen in der Zwischenform. Den früheren maschinenausführbaren Versionen fehlen Informationen, die die Beziehungen der Elemente der Zwischenform-Darstellung zu einer anderen definieren.
Bei Systemen nach dem Stand der Technik ist keine Einrichtung zum Umwandeln von Abstrakttypendefinitionen einer Form auf hoher Ebene vorgesehen, und insbesondere von ASN.1-spezifizierten Abstrakttypdefinitionen in eine Zwischenform bzw. eine mittlere Form zur Verwendung in Zusammenhang mit einem Interpretierer, so daß die mittlere Form in die ursprüngliche Form auf hoher Ebene aus der mittleren Form umgekehrt bzw. zurück compiliert werden kann.
Es ist beim Verwenden von ASN.1-codierten Abstrakttypendefinitionen wünschenswert, daß sie Werte direkt anzeigen können, die zu einem gegebenen benannten Objekt gehören, und zwar unter Verwendung eines interpretierenden Programmierwerkzeugs, wie beispielsweise die von Digital Equipment Corporation vertriebene Einrichtung mit dem Namen Service-Browser (DECdns Browser), die von Digital Equipment Corporation hergestellt wird und Fachleuten auf dem Gebiet bekannt ist. Es ist ebenso wünschenswert, Werte direkt anzeigen und modifizieren zu können, die zu einem gegebenen Objekt gehören, ohne die entsprechende Abstrakttypendefinition neu zu compilieren. Weiterhin ist es wünschenswert, Abstrakttypendefinitionen umgekehrt compilieren zu können, um erneut die Abstrakttypendefinitionen einer höheren Form aus codierten Abstrakttypendefinitionen auf einer mittleren Ebene zu erzeugen.
DE-35 18 139-A beschreibt einen Text-Compiler, der eine Umwandlung von einer BASIC- zu einer ASCII-Codierung und umgekehrt zur Verfügung stellt.
IEEE Transactions an Software Engineering 16, No. 10; G W Neufeld et al. "The Design and Implementation of an ASN.1-C Compiler" beschreibt ein System zum automatischen Übersetzen von eingegebenen ASN.1-Modulen in C und zum Erzeugen von BER-Codierern und Decodierern für protokolldefinierte Datentypen.

ZUSAMMENFASSUNG DER ERFINDUNG

Die vorliegende Erfindung schafft ein Verfahren zum Umwandeln einer abstrakten Syntax von einer hohen Ebene zu einer mittleren Ebene, die zur Verwendung auf eine interpretierende Weise geeignet ist. Die Form der hohen Ebene bietet die zeitsparenden Programmiervorteile normaler Programmsprachen auf hoher Ebene. Die Abstrakttypendefinitionen auf hoher Ebene sind nicht zum Laufen auf einer Hardware auf eine interpretierende Weise geeignet; jedoch bietet die mittlere Form eine Form zum Codieren einer Abstrakttypendefinition, die im ASN.1-Text spezifiziert ist, der durch wohlbekannte ASN.1-Interpretierer auf eine interpretierende Weise verwendet wird.
Ein "Objekt" ist alles, was identifizierbar ist und was dafür von Interesse ist, um Informationen in der Directory-Datenbank zu halten. Eine "Klasse" von Objekten ist eine Gruppe von Objekten, die eine gemeinsame Eigenschaft teilen.
Ein "Attribut" ist eine Information von einem bestimmten Typ, die ein Objekt betrifft und in einem Eintrag erscheint, der jenes Objekt beschreibt. Der "Attributentyp" zeigt die Komponenten eines Attributs, die die Klasse von Informationen anzeigen, die durch das Attribut angegeben werden. Ein "Attributenwert" ist ein besonderes Beispiel für die Klasse von Informationen, die durch einen Attributentyp angezeigt werden. Eine "Attributensyntax" im Zusammenhang mit dem Compiler der vorliegenden Erfindung ist eine Gruppe von Definitionen, die für jedes Attribut den zugrundeliegenden ASN.1-Datentyp beschreiben.
Die hierin beschriebene Vorrichtung betrifft eine Modifikation in bezug auf einen existierenden ASN.1-Compiler, der einem Anwender ermöglicht, Abstrakttypendefinitionen anzuzeigen und/oder abzuändern. Ein Anwender eines Anwenderprogramms, das die vorliegende Erfindung verkörpert, kann diese Modifikationen zu den Abstrakttypendefinitionen eingeben, die in einem Anwenderprogramm enthalten sind, während das Anwenderprogramm in einem interpretierenden Mode arbeitet.
Die Vorrichtung und das Verfahren, die hierin beschrieben sind, sind zur Verwendung mit einem Directory von Objekten geeignet, um eine spezielle Eigenschaft zur Verfügung zu stellen, die "Soft-Schema" genannt wird. Ein Soft-Schema läßt zu, daß Abstrakttypendefinitionen in einem Format dargestellt werden, das zur Ausführung in einem Computer geeignet ist, der in einem interpretierenden Mode arbeitet, und auf eine derartige Weise, daß die Abstrakttypendefinitionen nicht erneut compiliert oder gebunden werden müssen, wenn ein Programmierer entweder eine existierende Abstrakttypendefinition ändert oder eine neue Abstrakttypendefinition zum System hinzufügt. Dieser Vorteil der vorliegenden Erfindung gegenüber compilierten Formen, die ein erneutes Compilieren und ein erneutes Binden der Anwendung erfordern, wann immer die Abstrakttypendefinition für neue Attribute spezifiziert wird oder die Abstrakttypendefinition für zuvor existierende Attribute für Objekte modifiziert wird, bietet wesentliche Zeiteinsparungen für Programmierer, wenn sie existierende Attribute für Objekte austesten und abändern. Es kann sein, daß es nicht immer möglich ist, die Anwendung erneut zu compilieren und erneut zu binden, wie beispielsweise dann, wenn die Anwendung bereits beim Kunden verwendet wird. Daher liefert das Soft-Schema wesentliche Vorteile für einen Benutzer des oben beschriebenen Netzwerk-Directories.
Die Erfindung in ihrer allgemeinen Form besteht in einem Verfahren und einer Vorrichtung gemäß den Ansprüchen 1 und 3. Gemäß einem Aspekt schafft die Erfindung eine Einrichtung zum Umwandeln einer Abstrakt-Syntax-Notation-Eins- (ASN.1)-Definition von einer codierten Form auf mittlerer Ebene zu einer ASN.1- Definition einer Textform auf hoher Ebene, welche Einrichtung folgendes aufweist:
eine Speichereinrichtung zum Empfangen und Speichern der ASN.1-Definition der codierten Form auf mittlerer Ebene;
eine Umkehrungs-Compilereinrichtung zum Umwandeln der codierten ASN.1- Definition auf mittlerer Ebene in die ASN.1-Definition der Textform auf hoher Ebene; und
eine Buseinrichtung zum Koppeln der Speichereinrichtung und der Umkehrungs-Compilereinrichtung.
Die besondere Programmiersprache, die bei der vorliegenden Erfindung verwendet wird, ist auf dem Gebiet der Computerprogrammierung als Abstrakt-Syntax- Notation-Eins-(ASN.1) bekannt. ASN.1 wird als ein formales Programmierwerkzeug zum Definieren von abstrakten Datentypen verwendet. ASN.1 unterscheidet sich von wohlbekannten Programmiersprachen, wie beispielsweise C und PASCAL, durch die Tatsache, daß sie nur dazu verwendet wird, Abstrakttypendefinitionen zu definieren, und sie enthält nur ein Vokabular, das groß genug ist, um Typen und Werte zu definieren.
Eine Übertragungssyntax stellt eine Gruppe von Regeln zum Codieren von Werten der in einem abstrakten Typ enthaltenen Typen zur Verfügung, wobei jede Abstrakttypendefinition in der ASN.1-Sprache spezifiziert wird. Eine derartige Übertragungssyntax ist die wohlbekannte Basiscodierregel-(BER)-Übertragungssyntax.
Wie es hierin beschrieben ist, werden dem Anwender der mittleren Form Funktionen zur Verfügung gestellt, die durch die Form auf hoher Ebene nicht verfügbar sind. Zusätzlich zu den hinzugefügten Ausführungsleistungsfähigkeitsvorteilen liefert die vorliegende mittlere Form durch die Verwendung des DECdns-Browsers, der X.500-Browser-Einrichtung und anderer ähnlicher Einrichtungen eine effizientere Weise für den Anwender, relevante Abstrakttypendefinitions-Informationen anzuzeigen und zu modifizieren.
Das DECdns-Produkt ist ein Directoryservice, der Informationen über Objekte in einem Rechensystem enthält. Der "DECdns-Browser" ist ein Anzeige- Programmierwerkzeug, das in Zusammenhang mit dem DECdns-Directory verwendet wird, um einem Anwender zu ermöglichen, die Directory-Datenbank zu untersuchen.
Das DEC-X.500-Produkt ist ein Directoryservice, der gemäß dem Internationalen Standard X.500 oder gemäß der Internationalen Organisation für Standardisierung (ISO 9594) implementiert ist. Das "X.500-Directory" ist ein Lager von Informationen über Objekte in einem Rechensystem. Dieses Lager von Informationen ist in der Directory-Informationsbank (DIB) enthalten. Jedes Objekt im Directory hat eine Gruppe von zu ihm gehörenden Attributen. Diese Attribute beschreiben die Eigenschaften des Objekts. Jeder Attributenwert stimmt mit einer spezifizierten Attributensyntax überein. Der DEC-X.500-Browser ist ein Anzeige-Programmierwerkzeug, das die Directory-Einträge im Directoryinformationsbaum (DII) interaktiv untersucht.
Der Programmierer kann das Programm zurück zur höheren Ebene umwandeln, wenn ein Programmierer wünscht, die Abstrakttypendefinition anzuschauen. Da die Form hoher Ebene allgemein die vertrauteste für den Programmierer ist, ist es für die Abstrakttypendefinition geeignet, daß sie in jener Form für den Programmierer dargestellt wird. Da ein Umkehrungs-Compiler bei der vorliegenden Erfindung die Fähigkeit besitzt, die ursprüngliche Form auf hoher Ebene aus der mittleren Form zu erzeugen, muß nur eine einzige Kopie der aktuellen codierten Befehle zu irgendeinem Zeitpunkt existieren. Dies führt zu wesentlichen Einsparungen in bezug auf den Speicherplatz. Weiterhin werden Konsistenzprobleme zwischen mehrfachen Kopien des Programms, das in Formen verschiedener Ebenen dargestellt wird, vermieden.
Bei sowohl dem von DEC vertriebenen Namensgebungsservice (DECdns) als auch der Implementierung von DEC des X.500-Directoryservice wandelt der Compiler Abstrakttypendefinitionen einer Form auf hoher Ebene, die in der ASN.1- Datentypenspezifizierungssprache definiert sind, in die mittlere Form um. Bei der DEC-Version des X.500-Directoryservice wird die mittlere Form im X.500- Directoryschema gespeichert. Bei DECdns wird die mittlere Form in der DECdns- Datenbank selbst gespeichert. Da die Form auf hoher Ebene aus der mittleren Form wiederhergestellt werden kann, muß die Version der hohen Ebene einer ASN.1-codierten Abstrakttypendefinition nicht gespeichert werden, nachdem die mittlere Form erzeugt ist. Die mittlere Form bietet eine verbesserte Leistungsfähigkeit der DEC-X.500-Directory-Updatedienste durch eine schnellere Verifizierung, daß Attributenwerte genau und vollständig zugeordnet (wohl ausgebildet) sind und mit der für sie spezifizierten Abstrakttypendefinition übereinstimmen. Zusätzlich können neue Abstrakttypendefinitionen zum X.500-Schema oder zum DECdns- Directory hinzugefügt werden und in ihren jeweiligen Browser-Einrichtungen verwendet werden. Im Fall des X.500-Schemas wird die Attributensyntax verstärkt, ohne daß die gesamte X.500- oder DECdns-Anwendung und der Browser erneut compiliert/erneut gebunden worden ist.
Wie es zuvor angegeben ist, sind die bestimmten zur Anwendung bei der vorliegenden Erfindung gedachten Interpretierer der DEC-Browser für einen verteilten Namensgebungsservice (DECdns), der eine von Digital Equipment Corporation zur Verfügung gestellte wohlbekannte Einrichtung zum Suchen eines hierarchischen Namensraums von Objekten ist und die Namen und Attribute für jene Objekte anzeigt, und die DEC-Implementierung des X.500-Browsers, der auf dem Gebiet auch wohlbekannt ist und zum Suchen nach Objekten in einem X.500-Directory verwendet wird und die Namen und Attribute von Objekten anzeigt. Die interpretierende Funktion, die durch jede dieser Einrichtungen bereitgestellt wird, besteht in der Anwendung von Struktur- und Formatinformationen auf eine nicht typisierte Bytekette, um die nicht typisierte Bytekette in eine Gruppe von typisierten Feldern umzuwandeln. Dies wiederum ermöglicht dem Anwender der DNS- und X.500- Einrichtungen, Attributenwerte effizient und auf eine anwenderfreundliche Weise anzuzeigen. Zusätzlich wird die vorliegende Erfindung zum Durchführen von X.500-Directory-Updatediensten verwendet, die durch eine effiziente Verstärkung der für die Attribute spezifizierten Abstrakttypendefinitionen schneller sind.

BESCHREIBUNG DER ZEICHNUNGEN

Ein detaillierteres Verstehen der Erfindung kann aus der folgenden Beschreibung eines bevorzugten beispielhaften Ausführungsbeispiels erhalten werden, das in Zusammenhang mit der beigefügten Zeichnung zu verstehen ist, wobei:
Fig. 1 eine diagrammäßige Darstellung eines Rechensystems zum Compilieren und zum Speichern ist;
Fig. 2 ein Ablaufdiagramm für die Operation eines Compilers zum Umwandeln von ASN.1-Abstrakttypendefinitionen auf hoher Ebene in eine mittlere Form ist;
Fig. 3 ein illustratives Beispiel des Typen-, des Längen- und des Wert- (TLV)-Formats von ASN.1-BER-Werten, ist, die zum Darstellen der Abstrakttypendefinitionen in der mittleren Form verwendet werden;
Fig. 4 eine diagrammäßige Darstellung des Parserbaums für ein beispielhaftes ASN.1-Typendefinitionsmodul ist;
Fig. 5 eine diagrammäßige Darstellung des Parserbaums für eine beispielhafte ASN.1-Wertdefinition ist;
Fig. 6 ein illustratives Beispiel eines ASN.1-BER-Werts der mittleren Form für eine Abstrakttypendefinition ist;
Fig. 7 eine illustrative Ansicht des Programmablaufs zum Umwandeln der codierten Abstrakttypendefinitionen auf hoher Ebene in die mittlere Form ist; und
Fig. 8 eine Legende zum Umwandeln der in den Fig. 6 und 7 verwendeten Label in die aktuellen Definitionen ist, die sie darstellen.

DETAILLIERTE BESCHREIBUNG DES BEVORZUGTEN AUSFÜHRUNGSBEISPIELS

Nimmt man zuerst Bezug auf Fig. 1, wird bei dem gegenwärtig bevorzugten Ausführungsbeispiel der vorliegenden Erfindung die Textversion der ASN.1- Definitionen in den Speicher irgendeines geeigneten Computers eingegeben, um den Compilationsprozeß auszuführen, was die interaktiven Anwenderprogramme unterstützt, die die mittlere codierte Form verwenden, und um die Regeneration der Textform der ASN.1-Definitionen auf hoher Ebene aus der mittleren Form durchzuführen, wie es Fachleuten auf dem Gebiet bekannt ist. Somit ist die allgemeine Recheneinrichtung, die zum Beschreiben der vorliegenden Erfindung verwendet wird, für den Zweck eines Beschreibens der vorliegenden Erfindung vorgesehen, und andere geeignete Rechensysteme sind Fachleuten auf dem Gebiet bekannt.
Ein Systemanwender gibt die Text-ASN.1-Definitionen auf hoher Ebene durch eine Anwenderschnittstelle 2 in eine Speichereinheit 4 einer Recheneinrichtung 6 mittels eines Systembusses 8 ein. Auf einen Empfang eines geeigneten Befehls zum Aufrufen des hierin nachfolgend beschriebenen Compilationsprozesses hin überträgt eine zentrale Verarbeitungseinheit (CPU) 10 die Textform auf hoher Ebene der ASN.1-Definitionen auf dem Bus 8 zu einem lokalen Speicher 12 der CPU 10. Danach führt die CPU 10 die hierin nachfolgend beschriebenen Compilations- Unterprogramme aus, um eine mittlere BER-codierte Form der Form-ASN.1- Definitionen auf hoher Ebene herzustellen. Als nächstes überträgt die CPU 10 die ASN.1-Definitionen auf mittlerer Ebene auf dem Systembus 8 vom lokalen Speicher 12 zurück zur Speichereinheit 4.
Eine eindeutige Qualität der mittleren Form, nämlich die Fähigkeit zum Regenerieren der ursprünglichen Textform auf hoher Ebene daraus, bietet der Recheneinrichtung 6 die vorteilhafte Option, nur eine einzige Kopie der ASN.1-Definitionen gleichzeitig zu halten. Daher wirft die CPU 10 die ursprüngliche Textform auf hoher Ebene der ASN.1-Definitionen nach einem Erzeugen der mittleren Form weg.
Die CPU 10 liefert dem Anwender in Zusammenhang mit der Anwenderschnittstelle 2 und dem Systembus 8 mehrere bekannte Anwendungen zur Verwendung der mittleren Form der ASN.1-Definitionen. Diese Anwendungen sind hierin nachfolgend ausführlicher beschrieben.
Eine dem Systemanwender gezeigte Auswahl besteht in der Option zum Regenerieren der Form der ursprünglichen Form der ASN.1-Definitionen aus der mittleren Form. Auf einen Empfang des geeigneten Befehls auf dem Systembus 8 hin wandelt die CPU 10 die Form auf mittlerer Ebene in die ursprüngliche Textform auf hoher Ebene um (ohne die ursprünglichen Kommentierungen), und zwar mittels einer Gruppe von Umkehrungs-Compilierungs-Unterprogrammen, die hierin nachfolgend beschrieben sind. Wenn der Anwender es wünscht, wird die Form der ASN.1- Definitionen auf hoher Ebene im Speicher 4 gespeichert, und die Form auf mittlerer Ebene wird durch die Recheneinrichtung 6 weggeworfen.

Zusammenfassung der ASN.1-Notation

Abstrakt-Syntax-Notation-Eins (ASN.1) ist ein wohlbekannter Standard zum Spezifizieren von Abstrakttypendefinitionen, die sich auch auf Abstrakt-Syntaxen beziehen. Dieser Standard wird von Programmierern dazu verwendet, komplexe Datentypen aus einer Gruppe von Datenstrukturgrundelementen zu definieren. ASN.1 ist als internationaler Standard von der Internationalen Organisation zur Standardisierung (ISO) formuliert worden und ist von der Internationalen Elektrotechnischen Kommission angenommen worden.
ASN.1 enthält BOOLSCHE, GANZZAHLIGE, BITKETTEN, OKTETTKETTEN, sowie andere Grundelementen-Datentypen. ASN.1 enthält auch Bildungs- Datentypen, wie beispielsweise SEQUENZ, GRUPPE, AUSWAHL, SEQUENZ AUS und GRUPPE AUS. Der "SEQUENZ"-Datentyp entspricht dem PASCAL- "Datensatz". Eine SEQUENZ enthält eine vorbestimmte Gruppe von Feldern. Unter Verwendung einer SEQUENZ kann der Programmierer einen neuen Typ aus einer beliebigen Reihe anderer Typen bilden. SEQUENZ AUS ist ein weiterer Typ, der ähnlich der SEQUENZ ist; jedoch ist SEQUENZ AUS eine willkürliche Reihe geordneter Länge von Null oder mehr Werten, die jeweils vom selben Typ sind. Die "AUSWAHL"-Struktur bietet eine Auswahl von Werten aus einer Liste von spezifizierten Typen, die in der Definition aufgelistet sind. Ein "GRUPPEN"-Typ ist ähnlich einer SEQUENZ; jedoch erlaubt die GRUPPEN-Struktur, daß die Felder in einer beliebigen Reihenfolge erscheinen. GRUPPE AUS ist ähnlich SEQUENZ AUS; jedoch erlaubt die GRUPPE-AUS-Struktur, daß Werte in einer beliebigen Reihenfolge erscheinen. Schließlich ist der NULL-Typ der ASN.1-Typ, der einen Leerwert darstellt, d. h. nichts. Jeder dieser zuvor festgelegten Typen hat zuvor definierte Kennzeichen bzw. Tags, die im angenommenen Industriestandard dargelegt sind. Wenn ein ASN.1-Anwender einen neuen Typ definiert, der von einem der zuvor definierten Typen abgeleitet ist, hat der neue Typ dasselbe Kennzeichen bzw. dasselbe Tag wie der zuvor definierte Typ. Alternativ dazu kann der Anwender dem abgeleiteten Typ ein neues Tag zuordnen.
Der ASN.1-Standard definiert auch Basiscodierregeln (BER). Der ASN.1-Standard (ISO 8824) liefert eine Notation zum Spezifizieren von abstrakten Typen und Werten. BER liefert eine Gruppe von Regeln zum Codieren der Typen und Werte, die in ASN.1 spezifiziert sind.

Beschreibung der Zwischenform

Die Abstrakt-Syntax-Definitionen für die Zwischenform, die in der nachfolgenden Tabelle A aufgezeigt sind, bilden das Gerüst für das bevorzugte Ausführungsbeispiel der vorliegenden Erfindung. Die ASN.1-Definitionen in der Tabelle A sind von den Produktionen abgeleitet, die im ISO-Standard verwendet werden, der in der nachfolgenden Tabelle B dargestellt ist, die im Anhang F des Internationalen Standards ISO (ISO 8824, 1987) wiedergegeben ist. Diese Syntax-Definitionen sind in der Form einer ASN.1-Notation beschrieben und beschreiben den abstrakten Typ der Zwischenform. Tabelle A Syntax-Definitionen für die Zwischenform

Tabelle B

Zusammenfassung der ASN.1-Notation
Die folgenden Elemente sind im Abschnitt 8 des Standards ISO 8824 (1987) definiert:
Die folgenden Produktionen werden in diesem Internationalen Standard verwendet, und zwar mit den obigen Elementen als Anschlußstellensymbole:
Es sollte jedoch beachtet werden, daß ein Fachmann auf dem Gebiet unschwer erkennen würde, daß diese Liste von Definitionen erweitert, reduziert oder modifiziert werden könnte, damit sie in einer anderen Form dargestellt wird, ohne über den Schutzumfang der vorliegenden Erfindung hinauszugehen. Weiterhin ist berücksichtigt, daß der ASN.1-Standard in Zukunft modifiziert werden kann und daß alle Änderungen, die in bezug auf den Compiler für die mittlere Form gemacht werden, damit er diese Änderungen enthält, einem Fachmann auf dem Gebiet bekannt wären.
Die mittlere Form für die Definitionen sind gemäß dem ASN.1-BER-Standardtyp- (auch Tag genannt), Längen-, Wert-(TLV)-Format dargestellt, das in Fig. 3 gezeigt ist. Das Typenfeld oder das Tag bzw. das Kennzeichen bezeichnet den codierten Datentyp, der im Wertfeld enthalten ist. Die Inhalte des Typenfelds zeigen auch die Auswahl einer Liste möglicher Auswahlen in den in Tabelle 1 aufgelisteten Definitionen an. Das Längenfeld zeigt die Anzahl von Bytes an, die vor einem Treffen auf das Ende des bestimmten Wertfeldes bleiben. Schließlich enthält das Wertfeld den zu einem bestimmten Tag gehörenden Wert. Wie man auf einfache Weise aus Fig. 3 erfassen sollte, können die BER-Werte verschachtelt sein. Somit wird die rekursive Struktur des Parserbaums für eine gegebene abstrakte Typendefinition beibehalten. Die Tag-, Längen- und Wert-Felder werden hierin nachfolgend in Zusammenhang mit einem illustrativen Beispiel der Zwischenform bzw. der mittleren Form von ASN.1-Abstrakttypendefinitionen weiter beschrieben.
Beim bevorzugten Ausführungsbeispiel der vorliegenden Erfindung ist die Zwischenform gemäß den Basiscodierregeln (BER) codiert. Es ist berücksichtigt, daß ein Fachmann auf dem Gebiet innerhalb des Schutzumfangs der vorliegenden Erfindung eine Zwischenform unter Verwendung einer anderen Gruppe von Codierregeln (d. h. der Übertragungssyntax) erzeugen kann.
Eine Ausnahme für die parallele Beziehung zwischen den ASN.1-Definitionen in Tabelle A und den in Tabelle B spezifizierten Erzeugungsregeln existiert in bezug auf den Typ eines eingebauten Werts. Aus den Erzeugungsregeln würde man erwarten, daß die ASN.1-Definition für einen eingebauten Wert eine AUSWAHL- Struktur enthält. Jedoch dient der vollständige Parserbaum nicht notwendigerweise zum Regenerieren der Form hoher Ebene aus der Zwischenform für eine als eingebauten Wert spezifizierte Wertdefinition.
Es werden zwei allgemeine Anwendungen von der Zwischenform gemacht. Als erstes kann man die Form hoher Ebene aus der Zwischenform regenerieren. Als zweites kann man die Zwischenform zum Durchführen verschiedener Aufgaben verwenden. Der Parserbaum für den eingebauten Typ ist eingeschlossen, weil dies nötig ist, um den zweiten Zweck zu erfüllen. Für den eingebauten Wert wird jedoch nur der durch die Definition spezifizierte BER-Wert zum Erfüllen des zweiten Zwecks benötigt. Zusätzlich muß der entsprechende Text, der den Wert spezifiziert, gefangen sein, um eine Reproduktion des ursprünglichen Textes aus der Zwischenform zu erleichtern. Daher sind beim bevorzugten Ausführungsbeispiel der vorliegenden Erfindung nur jene zwei Informationsteile in der Zwischenform für einen eingebauten Wert dargestellt.
In den in Tabelle A aufgelisteten ASN.1-Syntax-Definitionen enthält der eingebaute Wert eine SEQUENZ, die aus zwei Feldern besteht. Jedes Feld in der ASN.1- Definition für einen eingebauten Wert ist eine OKTETTKETTE. Das erste Feld enthält die dem spezifizierten Wert äquivalente Zeichenkette. Das zweite Feld enthält den BER-Wert für den spezifizierten eingebauten Wert ohne das erste Tag auf oberster Ebene. Somit sind für einen BOOLSCHEN Wert von WAHR die zwei Felder des eingebauten Werts die Zeichenkette, die "WAHR" und den BER-Wert entsprechend WAHR darstellt.
Die übrigen in Tabelle A aufgelisteten Syntaxdefinitionen entsprechen der Parserbaumstruktur für das ASN.1-Modul. Es ist daher einfach, die Form hoher Ebene aus dem BER-Wert für die Definition durch Analysieren des BER-Werts auf dieselbe Weise zu regenerieren, auf welche man der Parserbaumdarstellung eines ASN.1-Moduls folgen würde. Die Regeneration der Textform hoher Ebene aus der Zwischenebene ist hierin nachfolgend beschrieben.
Die Zwischenform für ein ASN.1-Modul ist vom Typ der Moduldefinition, die in der Tabelle A definiert ist. Moduldefinition ist eine SEQUENZ, die zwei Felder enthält. Das erste Feld "Modulreferenz" enthält den Namen des Moduls. Das zweite Feld ist vom Typ Modulkörper und ist eine SEQUENZ eines Feldes, das die aktuellen Inhalte des benannten Moduls enthält. Die Inhalte sind entweder eine Liste von Zuordnungen in der Form der oben beschriebenen ASN.1-Struktur-Zuordnungsliste oder NULL (wenn es keinen Typen oder keine Wertzuordnungen im Modul gibt), und die Inhalte werden jeweils mit entweder [CONT 0] oder [CONT 1] gekennzeichnet. "CONT" zeigt ein kontextspezifisches Tag an.
Die Zwischenform für eine Liste von Zuordnungen ist eine SEQUENZ-AUS-Typ "Zuordnung". Diese Typenstruktur ist durch den Zuordnungslistentyp spezifiziert. Die Liste von Zuordnungen, die im BER-Wert vom Typ Zuordnungsliste enthalten sind, werden durch den Compiler in der Form des Typs "Zuordnung" individuell gebildet. Diese individuellen Zuordnungen werden dann in der Form der ASN.1- Struktur "SEQUENZ-AUS" zusammengesetzt.
Wendet man sich nun der Definition von "Zuordnung" in der Tabelle A zu, besteht diese ASN.1-Definition aus einem AUSWAHL-Typ von entweder Typenzuordnung oder Wertzuordnung und stellt die Zuordnung einer Definition für einen Typ oder für einen Wert dar.
Wenn Typenzuordnung für eine bestimmte ASN.1-Abstrakttypendefinition bestimmt ist, dann weist die Zwischenform für die Definition eine SEQUENZ auf, die zwei Felder enthält. Das erste Feld ist vom Typ "Typenreferenz" und hält den Namen der Typendefinition, die auf der linken Seite der Darstellung auf hoher Ebene einer bestimmten ASN.1-Typendefinition angeordnet ist. Das zweite Feld ist vom Typ "Typ", und dieses Feld enthält die aktuelle Definition auf der rechten Seite der Definition, die der benannten Abstraktdefinition auf der linken Seite der Typenzuordnung entspricht. Die weitere Zerlegung des "Typen"-Felds in der Definition würde durch eine verschachtelte Spezifikation zusätzlicher BER-Werte gemäß den in der Tabelle A aufgezeigten ASN.1-Definitionen auf eine Weise erreicht werden, die Fachleuten auf dem Gebiet bekannt ist.
Wenn alternativ dazu eine Wertzuordnung für eine bestimmte Abstrakttypendefinition bestimmt wird, dann weist die Zwischenform für die Definition eine SEQUENZ auf, die zwei Felder enthält. Das erste Feld ist vom Typ "Wertreferenz" und hält den Namen des Werts, und zwar positioniert auf der linken Seite der Darstellung auf hoher Ebene einer bestimmten ASN.1-Wertdefinition. Das zweite Feld enthält eine weitere SEQUENZ. Diese SEQUENZ enthält zusätzliche zwei Felder. Das erste Feld ist vom Typ "Typ", was die aktuelle Typendefinition auf der rechten Seite der Definition enthält, die der benannten abstrakten Definition auf der linken Seite der Wertzuordnung entspricht. Das zweite Feld ist vom Typ "Wert", was den aktuellen Wert enthält, der auf der rechten Seite des "::="-Symbols in der Textform auf hoher Ebene der Definition spezifiziert ist. Es ist eine SEQUENZ, die ein Feld enthält, das entweder vom Typ Definierter Wert oder Eingebauter Wert ist. Sowohl das erste als auch das zweite Unterfeld des zweiten Feldes von Wertzuordnung sind mit einem geeigneten BER-Wert gemäß der in der Tabelle A spezifizierten ASN.1- Syntaxdefinition auf eine Weise gefüllt, wie sie einem Fachmann auf dem Gebiet angesichts der Lehre der in der Tabelle A spezifizierten Definitionen bekannt ist.
Nun ist folgendes illustrative Eingabemodul zu betrachten:

Beschreibung des Compilationsprozesses

Es wird angenommen, daß der Eingang ein ASN.1-Modul ist, das eine Liste von ASN.1-Zuordnungen (Typ oder Wert) ist, und wir versuchen, die Zwischenform für das Modul zu erzeugen. Allgemein folgt der Compilationsprozeß bekannten Com pilerformen nach dem Stand der Technik, wie sie im Kapitel 1 von Compilers: Principles, Techniques, and Tools, von A. Aho, R. Sethi und Jeffrey D. Ullman beschrieben sind, das von Addison-Wesley Pub. Co. (1986) veröffentlicht ist. Wendet man sich nun der Fig. 2 zu, sind die Schritte zum Umwandeln der ASN.1- Abstrakttypdefinitionen auf hoher Ebene in die Zwischenform dargestellt. Der erste Schritt S1 beim Umwandeln der Darstellung auf hoher Ebene der Abstrakttypendefinitionen in die Zwischenform besteht im Zerlegen des ASN.1-Texts. Der Parser empfängt den eingegebenen Text für die abstrakte Syntax und erzeugt eine Parserbaumdarstellung des eingegebenen Textes durch Erzeugen eines Knotens für jeden Typ, auf den gestoßen wird, und durch Verzweigen, wenn es notwendig ist, ein Verschachteln von ASN.1-Grundelemententypen zu berücksichtigen. Die Form des Parserbaums entspricht der in der Tabelle B spezifizierten Grammatik.
Der Compiler modifiziert darauffolgend den Parserbaum, wenn er die Typenauflösung und eine semantische Prüfung während des semantischen Analyseschritts S3 durchführt, wobei der Compiler die Typen von Daten bestimmt, die der abstrakten Syntax und Beispielen bestimmter Informationen zugeordnet sind. Fehler, die während der Parserstufe auftreten könnten, sind diejenigen, die entstehen, wenn die vom Parser empfangene Eingabe dem ASN.1-Vokabular oder der Grammatik oder der Syntax nicht folgt oder nicht mit ihr übereinstimmt. Ein Beispiel für einen Fehler, der durch den Parser mit einem Flag versehen würde, wäre ein falsches Buchstabieren des Wortes "SEQUENZ", oder ein Fehlen von "{" in einer ASN.1-Angabe, wie beispielsweise "A ::= SEQUENZ BOOLSCHE ZAHL}". Fehler, die während der Typenauflösung und der semantischen Analyse auftreten könnten, sind diejenigen, die entstehen, wenn die Eingabe nicht mit der Semantik übereinstimmt, die in den ASN.1-Standards definiert ist. Sowohl die Syntax- als auch die Semantikfehler wären einem Fachmann auf dem Gebiet bekannt.
Es sollte beachtet werden, daß dann, wenn es einen Fehler während einer Ausführung des Compiler-Unterprogramms gibt, die Zwischenform nicht in ihrer Endform erzeugt wird. Die Zwischenform ist das transformierte Äquivalent der Eingabe in dem Sinn, daß es möglich ist, den eingegebenen Text aus der Zwischenform zu reproduzieren. Der durch den Parser erzeugte Parserbaum ist ein Beenden der Zerlegungs- bzw. Parserstufe genau wie die eingegebene Form auf hoher Ebene. Danach wird der Parserbaum durch die Durchführung einer Typenauflösung und einer semantischen Analyse manipuliert und modifiziert, um die Werte durch ein Beispiel darzulegen, die in Wertdefinitionen oder Vorgabewerten in GRUPPEN und SEQUENZEN definiert sind. Der Parserbaum stellt im wesentlichen die Syntax der Eingabe nach einem Beenden der Zerlegungsstufe dar, aber die Darlegung durch ein Beispiel der in Wertdefinitionen und Vorgabewerten in GRUPPEN und SEQUENZEN definierten Werte ist nur nach der semantischen Analysestufe beendet. Diese Werte sollen hierin nachfolgend eingebaute Werte genannt werden und dem Datentyp eingebauter Wert entsprechen, der in der Tabelle 1 beschrieben ist. Beide Informationsteile (Syntaxbaum und Darlegung durch ein Beispiel) sind erforderlich, um die Zwischenform zu bilden. Daher bildet der Compiler die Zwischenform in zwei Stufen.
Wenn der Compiler während der Zerlegungsstufe keinerlei Fehler erfaßt, dann geht eine Steuerung weiter zur Stufe des Compilationsprozesses, die hierin "Erstes Weitergehen" bei einer Zwischenformerzeugung genannt wird, wobei die "Vorläufige Zwischenform" der Abstrakttypendefinitionen gebildet wird. Diese Stufe ist in Fig. 2 durch einen Schritt S2 gezeigt.

Zwischenform - Weitergehen 1

Beim ersten Weitergehen im Schritt S2 wird die Vorläufige Zwischenform durch Entlanggehen am Parserbaum und durch Erzeugen eines ASN.1-BER-Werts vom Typ Moduldefinition gebildet. Wenn der Compiler den Parserbaum durchquert, wird die Parserstruktur der eingegebenen ASN.1-Abstrakttypendefinition im Parserbaum genau gezeigt. Als Folge davon ist es einfach, den ASN.1-BER-Wert vom Typ Moduldefinition zu bilden. Es gibt eine Gruppe von Unterprogrammen, und zwar eines für jede Definition in der Tabelle A. Jedes Unterprogramm bildet die Vorläufige Zwischenform für eine bestimmte Definition und bringt die Vorläufige Zwischenform zurück zum Aufrufer. Diese Zwischenprogramme sollen hierin nachfolgend "Generator"-Unterprogramme genannt werden. Somit bildet das Generatorprogramm, das dem Typ "Moduldefinition" entspricht, die Vorläufige Zwischenform für Moduldefinition, das Generator-Unterprogramm für den Typ "Typ" erzeugt die Vorläufige Zwischenform für Typ, und so weiter.
Jedes dieser Generator-Unterprogramme empfängt einen Zeiger in den vorher angegebenen Parserbaum. Das durch ein bestimmtes Unterprogramm aufgerufene Unterprogramm hängt von dem Symbol ab, auf das es beim Zeiger trifft. Das Generator-Unterprogramm analysiert den Zeiger, der auf eine Stelle im Parserbaum bezug nimmt, und ruft rekursiv andere Unterprogramme in der Gruppe von Genera tor-Unterprogrammen auf. Der Zeiger wird während jedes rekursiven Aufrufs einem Updaten unterzogen, wenn zusätzliche Knoten zur Definition hinzugefügt werden. Diese Generator-Unterprogramme erzeugen wiederum ihren erwarteten Abschnitt der vorläufigen Zwischenform. Das aufgerufene Unterprogramm bringt beim Beenden die erforderliche Vorläufige Zwischenform zum Aufrufer zurück. Der Aufrufer verwendet die zurückgebrachte Zwischenform, um die Erzeugung der Vorläufigen Zwischenform zu beenden, zu deren Erzeugung er entwickelt wurde. Dieser Prozeß wird hierin nachfolgend durch ein Beispiel in Zusammenhang mit der Beschreibung der Compilation eines ersten Weitergehens des in Fig. 4 dargestellten Parserbaums weiter erklärt.
Die Generator-Unterprogramme zeigen dieselbe Aufrufstruktur, wie es im Parserbaum gezeigt ist. Die Zweige des Baums werden verfolgt und keine Verzweigung wird angeregt, bis alle Unterzweige und Blätter besucht worden sind. Dies wird erwartet, da die Parserbaumstruktur absichtlich in die Zwischenform eingebaut ist.
Die obige Beschreibung gehört zu allen Generator-Unterprogrammen außer einem, nämlich jenem, das dem Typ "Wert" entspricht. Das Verhalten des Generator- Unterprogramms für Wert folgt nicht der Parserbaumstruktur. Der Knoten, der Wert im Parserbaum entspricht, wird durch das "Wert"-Generator-Unterprogramm analysiert, um zu bestimmen, ob er sich zum eingebauten Wert oder zum definierten Wert erstreckt. Wenn er sich zum definierten Wert erstreckt, fährt das rekursive Aufrufen und Bilden der Zwischenform fort, wie es oben beschrieben ist. Wenn er sich zum eingebauten Wert erstreckt, bringt das Generator-Unterprogramm eine SEQUENZ zurück, die ein Element enthält, nämlich [CONT 30] NULL, als seine Zwischenform. [CONT 30] NULL dient als Platzhalter. Der Platzhalter wird während des zweiten Weitergehens (das hierin nachfolgend beschrieben wird) durch den aktuellen Wert ersetzt, dessen Tag [CONT 0] ist und dessen Typ Eingebauter Wert ist. Gleichzeitig wird der Zeiger zum Parserbaumknoten entsprechend dem Eingebauten Wert zu einer Warteschlange von Zeigern (die Warteschlange für Zeiger für einen Eingebauten Wert genannt wird) hinzugefügt. Diese Warteschlange wird dazu verwendet, dem Platzhalter "[CONT 30] NULL" durch die richtigen Daten während des zweiten Weitergehens zu ersetzen. Wenn die Warteschlange für einen Zeiger für einen Eingebauten Wert am Ende des ersten Weitergehens leer ist, muß das zweite Weitergehen nicht durchgeführt werden.
Jedoch muß der Compiler die anderen Stufen durchführen, um sicherzustellen, daß die Eingabe frei von Fehlern ist. Nur dann wird die Vorläufige Zwischenform dazu bestimmt, richtig zu sein. Der Compiler wird die Zwischenform für eine unrichtige Eingabe nicht erzeugen. Daher wirft der Compiler dann, wenn der Compiler Fehler in der Typenauflösungsstufe oder in der Stufe für einen semantische Analyse erfaßt, die Zwischenform weg.
Zu illustrativen Zwecken ist der in Fig. 4 dargestellte Parserbaum zu betrachten. Das Generator-Unterprogramm für Moduldefinition wird mit dem Zeiger aufgerufen, der beim Knoten 1 auf den Parserbaum Bezug nimmt. Das Generator- Unterprogramm für Moduldefinition wird die Vorläufige Zwischenform für Moduldefinition erzeugen, was eine SEQUENZ ist, die aus zwei Feldern besteht, nämlich der Vorläufigen Zwischenform für den Typ "Modulreferenz" und der Vorläufigen Zwischenform für den Typ "Modulkörper". Dieses Unterprogramm wird das Generator-Unterprogramm für Modulreferenz mit einem Zeiger zum Knoten 1.1 aufrufen. Das Generator-Unterprogramm für Modulreferenz bringt die Vorläufige Zwischenform für Modulreferenz zurück. Als nächstes ruft das Generator-Unterprogramm für Moduldefinition das Generator-Unterprogramm für Modulkörper auf, und zwar mit einem Zeiger, der auf den Knoten 1.2 Bezug nimmt. Das Generator- Unterprogramm für Modulkörper bringt die Vorläufige Zwischenform für Modulkörper zurück. Diese zwei Zwischenwerte, die von den Generator-Unterprogrammen für Modulreferenz und Modulkörper zurückgebracht werden, sind als Felder innerhalb der SEQUENZ für Moduldefinition enthalten und werden zu dem Unterprogramm zurückgebracht, das das Moduldefinitions-Generator-Unterprogramm aufrief.
Als nächstes wird das Generator-Unterprogramm für Modulreferenz betrachtet. Dieses Unterprogramm erzeugt einen BER-Wert vom Typ Modulreferenz, wobei der aktuelle Wert "Testmodul" ist. Somit ist das Tag [CONT 3] oder A3H [Hexadezimal], ist die Länge 0AH und ist der Wert "Testmodul".
Nun wird das Generator-Unterprogramm für Modulkörper betrachtet. Dieses Unterprogramm untersucht den Knoten 1.2 und analysiert die Inhalte, um zu bestimmen, ob sich der Modulkörper im Parserbaum zu einer Zuordnungsliste oder zu leer erstreckt. Beim illustrativen Beispiel nimmt der Zeiger Bezug auf eine Zuordnungsliste. Das Modulkörper-Generator-Unterprogramm ruft rekursiv das Generator- Unterprogramm für Zuordnungsliste mit einem Zeiger auf, der auf einen Knoten 1.2.1 Bezug nimmt. Wenn der Aufruf zum Generator-Unterprogramm für Zuordnungsliste beendet ist, wird ein SEQUENZ-Wert mit einem Element, dessen Tag [CONT 0] ist, dessen Länge die Länge des vom Aufruf zum Generator- Unterprogramm für Zuordnungsliste zurückgebrachten Werts ist und dessen Wert der im Aufruf zurückgebrachte Wert ist, gebildet und zurückgebracht. Andererseits würde dann, wenn sich der Modulkörper zu leer erstrecken würde (wie es dann auftreten würde, wenn es keine Definitionen im Modul gibt), ein SEQUENZ-Wert mit einem Element, dessen Tag [CONT 1] ist, dessen Länge 0 ist und dessen Wert nicht existiert, zurückgebracht werden.
Obwohl nur ein Teil des ersten Weitergehens des Compilationsprozesses für eine Verzweigung des Parserbaums der Fig. 4 beschrieben worden ist, untersucht der Compiler beim ersten Weitergehen, während er die Vorläufige Zwischenform bildet, auf eine reihenfolgenmäßige Weise jeden Knoten des in Fig. 4 dargestellten Parserbaums auf die Weise, die durch diese teilweise Beschreibung der Compilation des ersten Weitergehens zuvor beschrieben ist. Die Verzweigungen von jedem Knoten werden von links nach rechts im Parserbaum der Fig. 4 besucht. Eine Verzweigung wird nicht angeregt, bis alle ihre Unterverzweigungen besucht worden sind.

Typenauflösung

Nachdem die Stufe 52 des ersten Weitergehens des Compilierungsprozesses beendet ist, wird die Typenauflösungsstufe des Compilierungsprozesses im ersten Teil der semantischen Analysestufe durchgeführt, die einen Schritt S3 des Compilierungsprozesses aufweist, und zwar auf eine Weise, wie es Fachleuten auf dem Gebiet bekannt ist. Während der Typenauflösungsstufe wandert der Compiler durch den Parserbaum, der durch den Parser erzeugt ist, und verfolgt Vorwärtsreferenzen und löst alle Vorwärts- und Externreferenzen auf. Die Typenauflösungsprozeduren sind Fachleuten auf dem Gebiet wohlbekannt. Während er den Parserbaum nach unten geht, prüft der Compiler jedes Symbol gegenüber lokalen sowie externen Definitionstabellen. Am Ende der Typenauflösungsstufe sollten alle Symbolnamen an ihre geeignete Wert/Typen-Symboladresse angepaßt sein. Wenn irgendwelche unaufgelösten Referenzen zurückbleiben, dann werden geeignete Warnungen auf irgendeine Weise erzeugt, wie es Fachleuten auf dem Gebiet bekannt ist.

Semantische Prüfung

Während des Semantikanalyseschritts S3 geht der Compiler durch den zuvor durch den Parser erzeugten Parserbaum und verifiziert, daß die Typen und Werte mit der Semantik übereinstimmen, die im Internationalen Standard ISO (ISO 8824, 1987) definiert ist. Der Semantikanalysierer füllt die Typen von Wertsymbolen. Die Ausgabe dieser Stufe des Compilerprozesses ist die Erzeugung von Fehlernachrichten für Typen und Werte, die nicht mit den im ISO-Standard (ISO 8824, 1987) dargestellten Regeln übereinstimmen.
Die Semantikanalyse ist auf die Zwischenformerzeugung der vorliegenden Erfindung zugeschnitten. Für Knoten im Parserbaum entsprechend der Erzeugungsregel "Eingebauter Wert ::= ..." im ISO-Standard (ISO 8824, 1987), wie beispielsweise demjenigen in Fig. 5, werden zwei zusätzliche Informationsteile erzeugt und am Parserbaum angebracht. Diese zwei Informationsteile sind gleich dem Kettenäquivalent des spezifizierten Werts und dem BER-Wert des spezifizierten Werts. Eine Erzeugung dieser zwei Informationsteile ist unkompliziert und auf irgendeine geeignete Weise erreichbar, wie sie Fachleuten auf dem Gebiet bekannt ist.
Zum Darstellen dieser Darstellung einer ASN.1-Wertdefinition wird die folgende Wertdefinition betrachtet.
alpha BOOLSCHER AUSDRUCK ::= WAHR
Der Parserbaum für die obige Definition ist in Fig. 5 dargestellt. Das Kettenäquivalent für den spezifizierten Wert (d. h. für den Knoten Eingebauter Wert im Parserbaum) ist "WAHR" und der BER-Wert ohne das erste Tag besteht aus zwei hexadezimalen Bytes 01 H und 01 H.

Zwischenform - Weitergehen 2

Wenn es keine in den zuvor beschriebenen Stufen des Compilerprozesses erfaßten Fehler gibt, dann führt der Compiler die Stufe 54 für ein zweites Weitergehen aus. Wie es zuvor angegeben ist, wird das Bilden von Werten vom Typ Eingebauter Wert zur zweiten Stufe verzögert, weil die nötigen Daten nicht verfügbar sind, bis nachdem der Compiler die Semantikanalysestufe durchführt. Während des zweiten Weitergehens ersetzt der Compiler die Platzhalterwerte "[CONT 30] NULL" durch aktuelle Werte. Zusätzlich wird der ASN.1-BER-Wert der Vorläufigen Zwischenform durchquert und gleichzeitig wird die Verbesserte Zwischenform gebildet. Die Verbesserte Zwischenform ist dieselbe wie die Vorläufige Zwischenform außer für die Substitution von aktuellen Werten für Platzhalterwerte. Die Substitution aktueller Werte kann auf eine beliebige Weise erreicht werden, wie sie Fachleuten auf dem Gebiet bekannt sind.
Die Durchquerung der Vorläufigen Zwischenform ist keine Durchquerung Byte für Byte, sondern eine strukturierte Durchquerung (ASN.1-BER-Werte sind strukturierte Werte) durch Öffnen von SEQUENZEN durch Untersuchen der zugehörigen Tags, wie es Fachleuten auf dem Gebiet bekannt ist. Wann immer in der Vorläufigen Zwischenform auf "[CONT 30] NULL" gestoßen wird, wird ein Wert mit der Kennung bzw. dem Tag [CONT 0] und vom Typ Eingebauter Wert in die Verbesserte Zwischenform eingesetzt. Auf die notwendigen Informationen zum Bilden des Werts vom Typ Eingebauter Wert wird durch den ersten Zeiger in der oben beschriebenen Warteschlange für einen Zeiger für Eingebauten Wert Bezug genommen. Der Zeiger indiziert einen Knoten im Parserbaum, der einem Eingebauten Wert entspricht.
Als Ergebnis der Semantikanalyse nimmt dieser Knoten Bezug auf zwei Informationsteile: das Kettenäquivalent des eingebauten Werts und den ASN.1-BER-Wert ohne dem "T"- oder Tag-Feld des BER-Werts. Ein SEQUENZ-Wert, der diese zwei Elemente enthält, wird gebildet. Der Compiler ordnet das Tag von [CONT 0] diesem Wert zu und fügt dann das Tag in die Verbesserte Zwischenform anstelle des Platzhalters [CONT 30] NULL ein. Der Zeiger, der auf die Zeigerwerte in der Warteschlange für einen Zeiger für Eingebauter Wert Bezug nimmt, wird zum nächsten Zeiger in der Warteschlange weitergeschaltet.
Am Ende des Zweiten Weitergehens sind alle Platzhalter [CONT 30] NULL durch aktuelle Werte in der Vorläufigen Zwischenform ersetzt worden, und alle Zeiger aus der Warteschlange sind verwendet worden, und die Warteschlange für Zeiger für Eingebauter Wert ist leer.

Detaillierte Beschreibung der Zwischenform für eine Abstrakttypendefinition auf hoher Ebene

Nun wird das folgende Beispiel eines ASN.1-Moduls betrachtet.
Fig. 4 zeigt illustrativ die Parserbaum-Endstruktur für die Zwischendarstellung der Textdarstellung auf hoher Ebene von Testmodul. Die Gruppe von hexadezimalen Bytes, die hierin nachfolgend vorgesehen sind, stellt die Zwischenform für dieses ASN.1-Modul in hexadezimaler Form dar, die im Speicher linear gespeichert ist. Diese Darstellung wird am besten verstanden, wenn sie in Zusammenhang mit illustrativen Darstellungen der codierten Zwischenform der oben beschriebenen Abstrakttypendefinitionen angeschaut wird, die in den Fig. 6 und 7 gezeigt sind.
Fig. 6 und 7 stellen zwei unterschiedliche Darstellungen der verschachtelten Beziehung der zuvor beschriebenen Abstrakttypendefinition auf hoher Ebene dar, die in der hexadezimalen Form auf einer Zwischenebene codiert und als ASN.1-BER- Wert gespeichert ist. Fig. 6 zeigt die verschachtelte Beziehung der ASN.1-BER- Werte (in TLV-Form). Fig. 7 zeigt die Anordnung der manchmal verschachtelten Verfahrensaufrufe und die auf jeder Ebene eines Verfahrensaufrufs ausgeführten Auswahlen, wenn ein in der Zwischenform gespeicherter ASN.1-BER-Wert interpretiert wird, um eine von mehreren interpretierenden Funktionen auszuführen, die Anwendern der Zwischenform verfügbar sind. Diese speziellen Funktionen sind hierin nachfolgend beschrieben. Eine Legende zum Umwandeln von Labels (A, B, C, ... a, b, c, etc.) zu aktuellen Typendefinitionsnamen ist in Fig. 8 zur Verfügung gestellt. Die Legende von Fig. 8 bietet ein Mittel zum Zeigen einer klaren Figur in sowohl der Fig. 6 als auch der Fig. 7 und stellt keine aktuellen codierten Werte (aufgerufene Tags) für die Typen dar, denen sie entsprechen.
Wendet man sich nun der Fig. 6 zu, beginnt die Zwischenform der illustrativen Gruppe von ASN.1-Typendefinitionen auf hoher Ebene mit dem Tag-Feld entsprechend SEQUENZ, da Moduldefinition eine SEQUENZ (30 Hexadezimal oder 30H) ist. Die Länge des Inhaltsfeldes (das die übrigen Abschnitte der abstrakten Typendefinition bildet) ist 38H.
Das Inhaltsfeld für die abstrakte Typendefinition beginnt mit dem ersten Feld des Moduldefinitionstyps SEQUENZ. Das erste Feld ist vom Typ Modulreferenz. Das Tag für dieses Feld ist A3H, da Modulreferenz vom Typ [3] ASN.1-Elementenkette ist, und [3], oder [CONT 3] übersetzt zu A3H. Die Länge des ersten Felds beträgt 10 Bytes (0AH), was der Anzahl von Bytes entspricht, die zum Speichern der maschinencodierten Textform des Modulnamens "Testmodul" benötigt werden. Die Inhalte dieses Felds sind die ASCII-codierte Form der Kette "Testmodul". Das zweite Feld ist vom Typ Modulkörper. Es ist eine SEQUENZ und hat innerhalb von ihm verschachtelt ein Feld vom Typ Zuordnungsliste. Das Tag für dieses Feld ist A0H, da Modulkörper eine SEQUENZ {AUSWAHL[0] Zuordnungsliste [1] NULL}} ist, und die Zuordnungslistenauswahl hat das zu ihr gehörende Tag [0] oder [CONT 0]. [CONT 0] übersetzt zu A0H. Dieses Feld ist eine SEQUENZ vom Typ Zuordnung und enthält mehrere Elemente, die innerhalb von ihm verschachtelt sind. Beim vorliegenden illustrativen Beispiel hat die SEQUENZ nur ein einziges Element vom Typ Typenzuordnung (A0H) und ihr Wertfeld besetzt 26H Bytes des Speichers. Das erste Feld ist durch einen Wert vom Typ Typenreferenz (Tag ist A0H, da Typenreferenz ::= [0] ASN1.Elementenkette) der Länge 08H und einen Wert gleich der ASCII-codierten Form der Kette "Testtyp" besetzt. Das zweite Feld ist vom Typ Typ, was eine SEQUENZ ist, und hat somit ein Tag 31 H, (31 H) hat einen Wert der Länge 1CH. Das Typenfeld, eine SEQUENZ, hat innerhalb von ihm einen Wert vom Typ Eingebauter Typ (A0H) verschachtelt. Das Tag-Feld für diesen Wert ist A0H, da der Wert von Typ eine SEQUENZ (AUSWAHL {[0] Eingebauter Typ, [1] Definierter Typ}} ist und der Wert des Eingebauten Typs das Tag [0] oder [CONT 0] ihm zugeordnet hat. [CONT 0] übersetzt zu A0H. Der Wert von Eingebauter Typ wiederum hat einen Wert der Länge 1AH. Der Eingebaute Typ hat in ihm verschachtelt einen Wert vom Typ Sequenztyp (A5H), dessen Wert 18H Bytes des Speichers besetzt. Das Tag-Feld für diese Auswahl ist A5H, da Eingebauter Typ eine SEQUENZ {AUSWAHL [0] Boolscher Typ, ..., [5] Sequenztyp ...}} ist und der Wert von Sequenztyp ihm zugeordnet das Tag [5] oder [CONT 5] hat. [CONT 5] entspricht dem maschinencodierten hexadezimalen Wert A5H. Der Wert von Sequenztyp hat innerhalb von ihm verschachtelt einen Wert vom Typ Elemententypliste (A0H), dessen Wert 16H Bytes des Speichers besetzt.
Beim gegenwärtigen Beispiel enthält der Wert der Elemententypliste SEQUENZ- AUS-Elemententyp (BER-Tag = 30H) zwei Felder. Beide Felder sind vom Typ Elemententyp. Das erste Feld hat eine Länge von 08H und hat in ihm verschachtelt einen Wert vom Typ Benannter Typ (A0H). Der Benannte Typ hat in ihm verschachtelt einen Wert vom Typ Typ (A1H) und hat eine Länge von 6 Bytes. Der Wert von Typ hat einen Wert der Länge 04H. Der Wert von Typ ist eine SEQUENZ und enthält einen Wert vom Typ Eingebauter Typ (A0H), dessen Wert 2 Bytes des Speichers besetzt. Der Eingebaute Typ hat in ihm verschachtelt einen Wert vom Typ Boolscher Typ (A0H), was NULL ist.
Das zweite Feld der Elemententypliste SEQUENZ hat einen BER-Wert der Länge (0AH). Sein Wert ist fast identisch zum ersten Element; jedoch hat der Wert vom eingebauten Typ beim zweiten Feld in ihm verschachtelt einen Wert vom Typ Ganzzahliger Typ (A1H) und sein Wert besetzt zwei Bytes des Speichers. Der Wert des Ganzzahligen Typs ist eine SEQUENZ. In diesem Fall wird die Option [0] NULL der AUSWAHL innerhalb der SEQUENZ ausgewählt, und dies spezifiziert den Ganzzahligen Typ SEQUENZ, der einen BER-Wert mit einem Tag-Feld gleich A0H und einer Länge von Null enthält.
Wendet man sich nun der Fig. 7 zu, ist beabsichtigt, daß die in Klammern gesetzte Folge von Verfahrensaufrufen (durch Großbuchstaben gezeigt) Auswahlen aus dem Kontext (durch in Klammern gesetzte Zahlen gezeigt) und Verfahrensrücksprünge (durch Kleinbuchstaben gezeigt) den Programmablauf des Compilers zum Bilden des ASN.1-BER-Werts für das spezifizierte ASN.1-Modul darstellen. Die Auswahlen und Namen entsprechen den Syntaxdefinitionen für die in der Tabelle A aufgelistete Zwischenform.

Beschreibung interpretierender Funktionen, die beim Verwenden der Zwischen- ASN.1-Abstrakttypendefinitionen verfügbar sind

Mehrere zuvor gezeigte interpretierende Funktionen sowie eine neue interpretierende Funktion sind von der Zwischenform der codierten ASN.1- Abstrakttypendefinitionen ausführbar. Zuerst kann ein bekanntes Verfahren auf die Zwischenform angewendet werden, um eine nicht typisierte Bytekette entsprechend der Abstraktsyntax als eine Gruppe von typisierten Feldern und Unterfeldern zu interpretieren. Als zweites kann der Wert entsprechend einer Abstraktsyntax in typisierte Felder und Unterfelder organisiert und als alphanumerische Werte auf einer Ausgabevorrichtung angezeigt werden. Dies ist eine von einem Menschen besser lesbare Form als die nicht typisierte Bytekette. Als drittes können bekannte Verfahren angewendet werden, um zu verifizieren, daß ein bestimmter codierter Wert mit einer abstrakten Syntax übereinstimmt. Als viertes ist es möglich, einen Wert umzuwandeln, der einer Gruppe von Codierungsregeln oder einer Übertragungssyntax folgt, in einen Wert, der einer anderen Gruppe von Codierungsregeln oder einer Übertragungssyntax folgt. In diesem Fall stimmen beide Werte (umgewandelter und umzuwandelnder) mit der abstrakten Syntax überein. Als fünftes können bekannte Verfahren auf die vorliegende Erfindung angewendet werden, um zufällige oder willkürliche Werte zu erzeugen, die der abstrakten Syntax entsprechen.
Die obigen Funktionen sowie neue Funktionen, die durch die Zwischencodierform der vorliegenden Erfindung ermöglicht werden, können in ein interaktives System eingebaut werden, wie beispielsweise die DEC-Version des X.500- Directoryprodukts. Die interpretierenden Funktionen werden direkt in das Programm compiliert und werden zum Anwender in einer Laufzeitbibliothek auf eine bekannte Weise geliefert, die Fachleuten auf dem Gebiet bekannt ist. Dieses Verfahren zum Bereitstellen von Anwenderfunktionen wird "Soft-Schema" genannt.
Zusätzlich zu den zuvor bekannten interpretierenden Funktionen, die bei Systemen nach dem Stand der Technik zur Verfügung gestellt werden, liefert die vorliegende Erfindung die Fähigkeit zum interpretierenden Erzeugen des ursprünglichen Texts auf hoher Ebene aus der codierten Zwischenform der ASN.1- Abstrakttypendefinitionen. Dies ermöglicht dem Anwender, die ursprüngliche Textdarstellung auf hoher Ebene der ASN.1-Definitionen zu regenerieren, während gerade eine Anwendung auf einem System ausgeführt wird. Die Form auf hoher Ebe ne, die aus der Zwischenebene regeneriert wird, kann durch den Anwender angeschaut werden, zu einem anderen Codiersystem zum Compilieren in eine andere Zwischenform oder Form auf niedriger Ebene übertragen werden, oder irgendeiner anderen nützlichen Funktion unterzogen werden. Ein durch diese Funktion zur Verfügung gestellter Vorteil besteht darin, daß die ursprüngliche Form nicht gesichert werden muß, um diese Funktionen für einen Anwender zur Verfügung zu stellen. Daher wird kein sehr großer Raum im Speicher (sowohl im primären als auch im sekundären) durch gleichzeitiges Halten sowohl der hohen als auch der mittleren Formen eines Codierens verbraucht. Weiterhin ist es dann, wenn zwei getrennte Kopien der ASN.1-Definitionen gehalten werden, und zwar eine für jede Ebene, möglich, daß Änderungen in bezug auf eine Ebene gemacht werden, die nicht zur anderen Ebene übertragen wird. In solchen Fällen entsteht ein Konsistenzproblem, das die Unversehrtheit der gespeicherten Informationen negativ beeinflußt. Ein weiterer Vorteil der Einzelform der ASN.1-Definition ist die Sicherstellung, daß die Form auf hoher Ebene der durch den Computer verwendeten Zwischenform entspricht, da die regenerierte Form auf hoher Ebene direkt von der Zwischenform abgeleitet wird.

Beschreibung eines umgekehrten Compilierens der Zwischenform

Es wird die Zwischenform für Moduldefinition angenommen, die aus einem ASN.1- BER-Wert vom Typ Moduldefinition besteht. Der Umkehrungs-Compiler analysiert und untersucht diesen BER-Wert, wie es unten beschrieben ist, um die beschriebene Textform auf hoher Ebene der Definition zu erzeugen.
Der Umkehrungs-Compiler enthält eine Gruppe von Unterprogrammen, und zwar ein Unterprogramm für jede in der Tabelle A aufgelisteten Definition. Jedes dieser Unterprogramme kooperiert dann, wenn die entsprechende Zwischenform gegeben ist, mit einem anderen, um den Text entsprechend der Zwischenform zu erzeugen. Diese Unterprogramme sollen hierin nachfolgend Drucker-Unterprogramme genannt werden.
Beispielsweise erzeugt das Drucker-Unterprogramm für Moduldefinition die ASN.1- Textform auf hoher Ebene entsprechend der Zwischenform für Moduldefinition. Anders ausgedrückt druckt es ein ASN.1-Modul. Jedes Drucker-Unterprogramm analysiert den Zwischenform-Wert, der ihm gegeben wird (durch seinen Aufrufer), und ruft dann, wenn es nötig ist, rekursiv ein anderes Drucker-Unterprogramm auf.
Die Beschreibung jedes Drucker-Unterprogramms wird hierin nachfolgend geliefert. Das Drucker-Unterprogramm für ASN1-Elementenkette empfängt die Zwischenform für ASN1-Elementenkette und erzeugt den OKTETTKETTEN-Wert als alphanumerischen Text. Die Drucker-Unterprogramme für Typenreferenz, Identifizierer, Wertreferenz, Modulreferenz, Nummer, B-Kette, H-Kette und C-Kette verhalten sich alle ähnlich. Sie empfangen die codierte Zwischenform für jeden jeweiligen Typ, und jedes dieser Drucker-Unterprogramme ruft das ASN1-Elementenketten- Drucker-Unterprogramm auf und gibt die empfangene codierte Zwischenform zum ASN1-Elementenketten-Drucker-Unterprogramm weiter.
Als nächstes empfängt das Moduldefinitions-Drucker-Unterprogramm als seine Eingabe die Zwischenform (den BER-Wert) für Moduldefinition. Wie es aus der Beschreibung der Zwischenform in Erinnerung gerufen werden sollte, ist die somit empfangene Eingabe ein SEQUENZ-Wert, der zwei Felder enthält: das erste Feld ist vom Typ Modulreferenz und das zweite Feld ist vom Typ Modulkörper. Das Moduldefinitions-Drucker-Unterprogramm führt als nächstes eine Reihe von Operationen durch.
Zuerst ruft der Moduldefinitions-Drucker das Modulreferenz-Drucker- Unterprogramm auf und gibt den Parameter weiter, der das zuvor beschriebene erste Feld der Moduldefinitions-SEQUENZ aufweist. Nachdem eine Steuerung zum Moduldefinitions-Drucker-Unterprogramm zurückspringt, erzeugt dieses Unterprogramm den Text "DEFINITIONEN ::=", das Zeichen "neue Zeile", "BEGINN" und das Zeichen "neue Zeile". Als nächstes ruft das Moduldefinitions-Drucker- Unterprogramm das Modulkörper-Drucker-Unterprogramm auf und enthält als weitergegebenen Parameter zu jenem Drucker-Unterprogramm das zuvor beschriebene zweite Feld der Moduldefinition SEQUENZ. Nachdem eine Steuerung zum Moduldefinitions-Drucker-Unterprogramm zurückspringt, erzeugt dieses Unterprogramm den Text "ENDE". Danach wird das Moduldefinitions-Drucker- Unterprogramm angeregt und eine Steuerung springt zum Aufrufverfahren zurück.
Das Modulkörper-Drucker-Unterprogramm empfängt die Zwischenform für einen Wert vom Typ "Modulkörper". Somit ist die Eingabe zu diesem Unterprogramm ein SEQUENZ-Wert mit nur einem Feld. Dieses Drucker-Unterprogramm untersucht das Tag für dieses Feld. Das Tag ist entweder [CONT 0] oder [CONT 1]. Wenn das Tag gleich [CONT 0] ist, dann ruft dieses Unterprogramm das Zuordnungslisten- Drucker-Unterprogramm auf und gibt den Wert dieses Felds zum Zuordnungslisten-Drucker-Unterprogramm weiter. Wenn die Steuerung zum Modulkörper- Drucker-Unterprogramm zurückgeht, geht die Steuerung zurück zum Aufrufer des Modulkörper-Drucker-Unterprogramms. Wenn das Tag [CONT 1] ist, dann wird keine Handlung durchgeführt, und die Steuerung geht zurück zum Aufrufer.
Das Zuordnungslisten-Drucker-Unterprogramm empfängt die Zwischenform für einen Wert vom Typ Zuordnungsliste. Somit ist die Eingabe ein SEQUENZ-AUS- Wert mit einem oder mehreren Feldern. Für jedes Feld in der SEQUENZ-AUS- Struktur führt das Zuordnungslisten-Drucker-Unterprogramm eine Reihe von Schritten durch. Zuerst erzeugt das Unterprogramm ein Zeichen "neue Zeile". Als zweites ruft das Unterprogramm das Zuordnungs-Drucker-Unterprogramm auf und gibt als den relevanten Parameter das Feld weiter, das gegenwärtig analysiert wird. Nachdem die Liste vollständig ausgeschöpft worden ist, springt die Steuerung zurück zum Aufrufer-Drucker-Unterprogramm.
Das Zuordnungs-Drucker-Unterprogramm empfängt die Zwischenform für einen Wert vom Typ Zuordnung. Somit ist die Eingabe eine AUSWAHL. Dieses Unterprogramm untersucht das zu dem weitergegebenen Wert gehörende Tag. Das Tag muß entweder [CONT 0] oder [CONT 1] sein. Wenn das Tag [CONT 0] ist, wird das Drucker-Unterprogramm für Typzuordnung aufgerufen und der eingegebene Wert zum aufgerufenen Unterprogramm weitergegeben. Wenn das Tag [CONT 1] ist, erfolgt ein Aufruf des Druckers für Wertzuordnung mit dem eingegebenen Wert. Auf einen Rücksprung der Steuerung von einem dieser zwei Unterprogramme hin wird das Zuordnungs-Drucker-Unterprogramm angeregt.
Das Drucker-Unterprogramm für eine externe Typenreferenz empfängt die Zwischenform für einen Wert vom Typ Externe Typenreferenz. Daher ist die Eingabe ein SEQUENZ-Wert, der zwei Felder enthält. Das erste Feld ist vom Typ Modulreferenz. Das zweite Feld ist vom Typ Typenreferenz. Das Drucker-Unterprogramm für Externe Typenreferenz ruft das Drucker-Unterprogramm für Modulreferenz auf. Auf einen Rücksprung der Steuerung vom aufgerufenen Unterprogramm hin druckt das Drucker-Unterprogramm für Externe Typenreferenz das Zeichen Zeichenperiode (.). Als nächstes ruft dieses Unterprogramm das Drucker-Unterprogramm für Typenreferenz auf und gibt das zweite Feld weiter. Wenn eine Steuerung vom aufgerufenen Unterprogramm zurückgesprungen ist, wird das Unterprogramm für Externe Typenreferenz angeregt. Das Drucker-Unterprogramm für Externe Wertrefe renz ist ähnlich dem Drucker-Unterprogramm für Externe Typenreferenz. Irgendwelche Unterschiede zwischen diesen zwei Drucker-Unterprogrammen sind Fachleuten auf dem Gebiet bekannt.
Das Drucker-Unterprogramm für Definierten Typ empfängt als seine Eingabe die Zwischenform für einen Wert vom Typ Definierter Typ. Somit ist die Eingabe ein SEQUENZ-Wert, der ein Feld enthält. Das einzelne Feld enthält eine AUSWAHL. Wenn das Tag [CONT 0] ist, ruft dieses Unterprogramm das Drucker- Unterprogramm für Externe Typenreferenz auf und gibt den einzigen Feldwert weiter. Wenn das Tag [CONT 1] ist, ruft dieses Unterprogramm das Drucker- Unterprogramm für Typenreferenz auf und gibt den einzigen Feldwert weiter. Auf einen Rücksprung vom aufgerufenen Drucker-Unterprogramm hin, wird dieses Unterprogramm angeregt, und eine Steuerung springt zum aufrufenden Unterprogramm zurück. Das Drucker-Unterprogramm für definierten Wert ist ähnlich dem Drucker-Unterprogramm für definierten Typ. Irgendwelche Unterschiede zwischen diesen zwei Drucker-Unterprogrammen sind Fachleuten auf dem Gebiet bekannt.
Das Drucker-Unterprogramm für Typzuordnung empfängt als seine Eingabe die Zwischenform für einen Wert vom Typ Typenzuordnung. Somit ist die Eingabe ein SEQUENZ-Wert, der zwei Felder enthält. Das erste Feld ist vom Typ Typenreferenz. Das zweite Feld ist vom Typ Typ. Dieses Unterprogramm ruft zuerst das Drucker-Unterprogramm für Typenreferenz auf und gibt den ersten Feldwert weiter. Wenn die Steuerung zu diesem Unterprogramm zurückspringt, werden folgende Textzeichen erzeugt: "::= ". Als nächstes ruft das Drucker-Unterprogramm für Typenzuordnung das Drucker-Unterprogramm für Typ auf und gibt den zweiten Feldwert weiter. Wenn die Steuerung zum Drucker-Unterprogramm für Typ zurückspringt, wird das Drucker-Unterprogramm für Typenzuordnung angeregt.
Das Drucker-Unterprogramm für Wertzuordnung empfängt als seine Eingabe die Zwischenform für einen Wert vom Typ Wertzuordnung. Somit ist die Eingabe ein SEQUENZ-Wert, der zwei Felder enthält. Das erste Feld ist vom Typ Wertreferenz. Das zweite Feld ist vom Typ SEQUENZ. Diese SEQUENZ enthält wiederum zwei Felder. Das erste Feld ist vom Typ Typ. Das zweite Feld ist vom Typ Wert. Das Drucker-Unterprogramm für Wertzuordnung ruft das Drucker-Unterprogramm für Wertreferenz auf und gibt den ersten Feldwert weiter. Auf einen Rücksprung der Steuerung vom aufgerufenen Unterprogramm hin erzeugt dieses Unterprogramm ein "Leerzeichen"-Zeichen. Als nächstes ruft dieses Unterprogramm das Drucker- Unterprogramm für Typ auf und gibt den ersten Unterfeldwert des zweiten Felds weiter. Auf einen Rücksprung der Steuerung vom aufgerufenen Unterprogramm hin erzeugt dieses Unterprogramm ein weiteres "Leerzeichen"-Zeichen, dem "::=" und ein Zeichen "neue Zeile" folgt. Als nächstes ruft dieses Unterprogramm das Drukker-Unterprogramm für Wert auf und gibt den zweiten Unterfeldwert des zweiten Felds weiter. Auf einen Rücksprung von diesem Unterprogramm hin wird das Drukker-Unterprogramm für Wertzuordnung angeregt.
Das Drucker-Unterprogramm für Typ empfängt als seine Eingabe die Zwischenform für einen Wert vom Typ Typ. Somit ist die Eingabe ein SEQUENZ-Wert mit einem einzigen Feld. Das einzige Feld zeigt einen Tag-Wert zum Anzeigen einer AUSWAHL an. Wenn das Tag [CONT 0] ist, dann ruft dieses Unterprogramm das Drucker-Unterprogramm für Eingebauten Typ auf und übergibt dieses Feld. Wenn das Tag [CONT 1] ist, dann ruft dieses Unterprogramm das Unterprogramm für Definierter Typ auf und übergibt das Feld. Auf einen Rücksprung vom aufgerufenen Unterprogramm hin wird das Drucker-Unterprogramm für Typ angeregt.
Das Drucker-Unterprogramm für Eingebauten Typ empfängt als seine Eingabe die Zwischenform für einen Wert vom Typ Eingebauter Typ. Somit ist die Eingabe ein SEQUENZ-Wert, der ein Feld enthält. Das Tag für dieses Feld zeigt eine der sechzehn möglichen Kontexte ([CONT 0], [CONT 1] ..... [CONT 15]) an. Basierend auf dem Tag-Wert führt das Drucker-Unterprogramm für eingebauter Typ einen geeigneten Aufruf zu einem anderen Drucker-Unterprogramm durch, der zu dem angezeigten Tag gehört, und übergibt den Feldwert.
Das Drucker-Unterprogramm für Eingebauter Wert empfängt als seine Eingabe die Zwischenform für einen Wert vom Typ Eingebauter Wert. Somit ist die Eingabe ein Wert vom Typ SEQUENZ, der zwei Felder enthält. Nur das erste Feld wird während des umgekehrten Compilierungsprozesses verwendet. Das Drucker- Unterprogramm für Eingebauter Wert erzeugt die ASCII-Kette in der Wertkomponente im ersten Feld des empfangenen Zwischenformwerts vom Typ Eingebauter Wert. Das Unterprogramm wird dann angeregt.
Ähnliche Unterprogramme sind für alle Definitionen vorgesehen, die in der Tabelle A beschrieben sind. Die Operation der übrigen Drucker-Unterprogramme folgt direkt aus der Beschreibung der ASN.1-Syntaxdefinitionen für die Zwischenform in der Tabelle A und der Tabelle B. Somit wäre es angesichts der Lehren der Tabelle A und der Tabelle B eine einfache Aufgabe für einen Fachmann auf dem Gebiet, geeignete Drucker-Unterprogramme zu erzeugen.
Somit ist ein bevorzugtes Ausführungsbeispiel für die vorliegende Erfindung beschrieben worden. Es sollte verstanden werden, daß beabsichtigt ist, daß die vorliegende Erfindung alle äquivalenten Verfahren und Vorrichtungen zum Ausführen der Erfindung, wie sie in den Ansprüchen beschrieben ist, abdeckt.

Claims

1. Vorrichtung (6) zum Umwandeln einer Abstrakt-Syntax-Notation-Eins- (ASN.1)-Definition zwischen einer ASN.1-Definition einer Textform auf hoher Ebene mit einer Vielzahl von Definitionen vom abstrakten Typ und einer ASN.1-Definition einer codierten Form auf einer mittleren Ebene, die die Vielzahl von Definitionen vom abstrakten Typ enthält, wobei die Vorrichtung folgendes aufweist:

eine erste Speichereinrichtung (4) zum Empfangen und Speichern der ASN.1-Definition der Textform auf hoher Ebene;

eine Compilereinrichtung (10) zum Umwandeln einer ASN.1-Definition der Textform auf hoher Ebene zu einer ASN.1-Definition der codierten Form auf mittlerer Ebene, wobei die codierte Form auf mittlerer Ebene eine Parserbaumdarstellung der ASN.1-Definition der Textform auf hoher Ebene enthält;

eine zweite Speichereinrichtung (4) zum Empfangen und Speichern der ASN.1-Definition der codierten Form auf mittlerer Ebene;

eine Ausführungseinrichtung, die mit der zweiten Speichereinrichtung verbunden ist, zum interpretierenden Ausführen der ASN.1-Definition der codierten Form auf mittlerer Ebene;

eine Änderungseinrichtung (2), die mit der zweiten Speichereinrichtung verbunden ist, zum Ändern der Vielzahl von Definitionen vom abstrakten Typ, die in der ASN.1-Definition der codierten Form auf mittlerer Ebene enthalten sind, wobei die Änderungseinrichtung auf Anwenderbefehle antwortet;

wobei die Ausführungseinrichtung damit fortfährt, die ASN.1-Definition der codierten Form auf mittlerer Ebene interpretierend auszuführen, ohne die ASN.1-Definition der Textform auf hoher Ebene neu zu compilieren, nach einer Änderung der Vielzahl von Definitionen vom abstrakten Typ;

eine Umkehrungs-Compilereinrichtung zum Analysieren der Parserbaumdarstellung, die durch die ASN.1-Definition der codierten Form auf mittlerer Ebene enthalten ist, und zum Umwandeln der ASN.1-Definition der codierten Form auf mittlerer Ebene in die ASN.1-Definition der Textform auf hoher Ebene; und

eine Buseinrichtung zum Koppeln der ersten Speichereinrichtung, der zweiten Speichereinrichtung, der Änderungseinrichtung, der Ausführungseinrichtung, der Compilereinrichtung und der Umkehrungs-Compilereinrichtung.

2. Vorrichtung nach Anspruch 1, die weiterhin folgendes aufweist:

eine Erfassungseinrichtung zum Erfassen, wenn die Umwandlung von der ASN.1-Definition der Textform auf hoher Ebene in die ASN.1-Definition der codierten Form auf mittlerer Ebene beendet ist; und

eine Verwerfungseinrichtung, die auf die Erfassungseinrichtung antwortet, zum Löschen der ASN.1-Definition der Textform auf hoher Ebene von der ersten Speichereinrichtung.

3. Verfahren zum Umwandeln einer Abstrakt-Syntax-Notation-Eins-(ASN.1)- Definition zwischen einer ASN.1-Definition einer Textform auf hoher Ebene mit einer Vielzahl von Definitionen vom abstrakten Typ und einer ASN.1- Definition einer codierten Form auf mittlerer Ebene, die die Vielzahl von Definitionen vom abstrakten Typ enthält, wobei das Verfahren folgendes aufweist:

Empfangen der ASN.1-Definition der Textform auf hoher Ebene;

Speichern der empfangenen ASN.1-Definition der Textform auf hoher Ebene in einem ersten Speicher;

Umwandeln der ASN.1-Definition der Textform auf hoher Ebene in die ASN.1-Definition der codierten Form auf mittlerer Ebene, wobei die codierte Form auf mittlerer Ebene eine Parserbaumdarstellung der ASN.1-Definition der Textform auf hoher Ebene enthält;

Empfangen der ASN.1-Definition der codierten Form auf mittlerer Ebene;

Speichern der empfangenen ASN.1-Definition der codierten Form auf mittlerer Ebene in einem zweiten Speicher;

interpretierendes Ausführen der ASN.1-Definition der codierten Form auf mittlerer Ebene;

Ändern der Vielzahl von Definitionen vom abstrakten Typ, die in der ASN.1-Definition der codierten Form auf mittlerer Ebene enthalten sind, in Antwort auf Anwenderbefehle;

Fortfahren mit dem Schritt zum interpretierenden Ausführen der ASN.1- Definition der codierten Form auf mittlerer Ebene, ohne die ASN.1-Definition der Textform auf hoher Ebene erneut zu compilieren, nach einer Änderung der Vielzahl von Definitionen vom abstrakten Typ;

Analysieren der Parserbaumdarstellung; und in Antwort auf das Analysieren der Parserbaumdarstellung, Umwandeln der ASN.1-Definition der codierten Form auf mittlerer Ebene in die ASN.1- Definition der Textform auf hoher Ebene.

4. Verfahren nach Anspruch 3, das weiterhin folgenden Schritt aufweist:

Löschen der ASN.1-Definition der Textform auf hoher Ebene aus dem ersten Speicher, nach einem Erfassen des Beendens des Umwandlungsschritts.