DE69130673T2

DE69130673T2 - Verfahren zur software-optimierung für irgendeine einer vielfältigkeit von ändernden architekturen

Info

Publication number: DE69130673T2
Application number: DE69130673T
Authority: DE
Inventors: Glenn W. Sunnyvale Ca 94086 Connery; Scott Andrew San Jose Ca 95118 Emery; W. Paul Sunnyvale Ca 94086 Sherer
Original assignee: 3Com Corp
Current assignee: 3Com Corp
Priority date: 1990-06-04
Filing date: 1991-06-03
Publication date: 1999-05-20
Anticipated expiration: 2011-06-04
Also published as: EP0532643B1; EP0532643A1; US5600823A; WO1991019244A1; DE69130673D1; US5459854A; EP0532643A4

Description

HINTERGRUND DER ERFINDUNG

Erfindungsbereich

Die vorliegende Erfindung bezieht sich auf Techniken zur Initialisierung von Software, wie Gerätetreiber für Netzwerk-Schnittstellen-Steuereinheiten in einem Wirts-Datenverarbeitungssystem. Genauer gesagt, bezieht sich die Erfindung auf einen Prozeß zum Laden eines Software-Produktes in einem Wirtsspeicher und die anschließende Optimierung des Produktes für die besondere Architektur des Wirts- Datenverarbeitungssystems.

Beschreibunci der verwandten Technik

Computersysteme wurden gemäß einer großen Anzahl von ändernden Architekturen implementiert, wobei die Architektur als die Hardware-Komponenten definiert wird, wie die CPU-Type, die das System bilden, sowie das Software- Betriebssystem, das eine Plattform zum Erzielen verschiedener Anwendungen bereitstellt.
Die CPU-Type in einer bestimmten Architektur kann eine Art von Mikroprozessor einschließen, die in der CPU benutzt wird. Mikroprozessor-Typen schließen die Klasse "86" der Mikroprozessoren ein, die ihren Ursprung bei der Intel Corporation haben und vorwiegend durch diese hergestellt werden. Diese Klasse von Mikroprozessoren schließt die Modelle ein, die als 8086, 8088, 80186, 80286, 80386, 80486 bezeichnet werden, sowie jeden anderen Mikroprozessor, der im wesentlichen dieselben Befehlssätze teilt. Jeder Mikroprozessor in dieser Familie benutzt einen gemeinsamen Untersatz von Befehlen, besitzt aber einmalige Fähigkeiten, die ihn von anderen unterscheiden. Weitere Klassen von Mikroprozessoren schließen die Klasse 68000 ein, die durch Motorola bereitgestellt wird, sowie eine Vielfältigkeit von RISC-Prozessoren, die durch eine Reihe von Unternehmen hergestellt werden.
Betriebssystem-Typen schließen am häufigsten MS-DOS in verschiedenen Ausführungen ein, die durch die Microsoft Corporation in Bellevue, Washington und Varianten derselben entwickelt wurden. Außerdem wurden das OS/2 Betriebssystem, das UNIX Betriebssystem und andere für eine Vielzahl von System-Architekturen entwickelt.
Somit wird die Architektur eines Datenverarbeitungssystems durch die Hardware definiert, die ihre Zentralverarbeitungseinheit und verwandte Komponenten bildet, sowie die Betriebssystem-Software, die eine Plattform zum Ablaufen von Anwendungs-Software und ähnlichem bereitstellt. Ein Hersteller von Zusatzgeräten, die zur Verarbeitung einer Vielzahl von ändernden Architekturen entworfen wurde, muß Software zur Steuerung der Zusatzgeräte bereitstellen, die in jeder der ändernden Architekturen abläuft. Diese Software wird normalerweise als Gerätetreiber bezeichnet. Deshalb waren bei früheren technischen Systemen mehrere Versionen von Gerätetreibern erforderlich, die für jede ändernde Architektur geschrieben wurden, die für den Ablauf des Zusatzgerätes bestimmt war. Der Benutzer muß in der Lage sein, zu wählen, welcher Gerätetreiber für sein Datenverarbeitungssystem anwendbar ist und der Hersteller muß eine große Anzahl von Versionen vertreiben. Hierzu ist ein intelligenter Benutzer zum Laden und zur Initialisierung des Gerätetreibers erforderlich.
Als Alternative werden beim Design der Gerätetreiber Kompromisse gemacht. Wenn beispielsweise jemand daran interessiert ist, nur die Klasse 86 von Mikroprozessoren unterzubringen, muß der Gerätetreiber nur im allgemeinen Untersatz von Befehlen geschrieben werden, die durch alle Prozessoren in der Klasse ausgeführt werden. Somit besitzen Datenverarbeitungssysteme, die die High-End-Versionen der 86 Klasse benutzen, Gerätetreiber, die die Fähigkeiten dieses Systems nicht in vollem Umfang ausnutzen.
Um den Benutzer bei der Identifizierung zu helfen, welcher Mikroprozessor in einem bestimmten Datenverarbeitungssystem benutzt wird, legen die Hersteller solcher Mikroprozessoren normalerweise Verfahren zur Erkennung des Mikroprozessors, der benutzt wird, offen. Diese Verfahren schließen die Prüfung der Funktionen des Mikroprozessors ein, so daß durch die Ergebnisse lediglich angegeben wird, welche Type benutzt wird. Diese Prüfungen können zur Optimierung der Benutzung von Codes durch einen bestimmten Mikroprozessor benutzt werden.
Computer-Architekturen werden normalerweise mit einer begrenzten Menge von benutzerzugänglichen Direktzugriffsspeicher entwickelt. Beispielsweise waren die Klasse 86 der Mikroprozessoren und das MS-DOS Betriebssystem ursprünglich dazu bestimmt, nur mit einer Basis von 640 Kilobytes von benutzerzugänglichem Speicher nützlich zu sein. Diese Einschränkung stellt eine große Einschränkung bei der Speicherbenutzung bei gewissen Anwendungen von Computern dar, bei denen eine bestimmte ändernde Architektur verwendet wird.
Anwendungsprogramme, einschließlich Treibern, speicherresidente Teile des Betriebssystems, einschließlich Treibern, beenden und halten speicherresidente Programme an und die übrige Software muß im allgemeinen einen Teil dieses benutzerzugänglichen Speichers während des Betriebs des Computers belegen. Wenn der Computer als Knoten eines lokalen Gebietsnetzwerkes oder ähnliches installiert wird, muß eine gewisse Menge dieses Speicherraums für Gerätetreiber für die Netzwerk-Schnittstelle reserviert werden. Es ist somit wichtig, die Menge an Speicherraum, die durch Gerätetreiber und ähnliches belegt wird, zu minimieren, um Anwendungen des Computersystems maximalen Zugriff auf benutzerzugänglichen Speicherraum zu ermöglichen.
Deshalb muß der Programmierer, der beabsichtigt Software in ausführbarer Form zu verteilen, die einen Teil des benutzerzugänglichen Speicherraums in einem Computersystem belegen muß, die ändernden Architekturen berücksichtigen, zu deren Benutzung ein gewisses Gerät vorgesehen ist. Ein Verfahren dies zu tun ist, daß das Betriebssystem für jede einzelne Variante optimiert wird und durch den Benutzer eine Wahl der korrekten Version des Gerätetreibers, der auf sein System zu laden ist, getroffen wird. Bei einem anderen Verfahren werden alle wahlfreien Versionen gemeinsam in einen begrenzten benutzerzugänglichen Speicherraum geladen, und dabei mehr Speicherraum als notwendig zu benutzen. Ein Verfahren, dies durchzuführen, besteht darin, daß das Betriebssystem für jede einzelne Variante optimiert und durch den Benutzer die korrekte Version des Gerätetreibers, der für sein System geladen werden soll, gewählt wird. Bei einem anderen Verfahren werden alle Versionen gemeinsam in den beschränkten benutzerzugänglichen Speicherraum geladen, wobei mehr Speicherraum als notwendig aufgebraucht wird. Als Alternative werden die Gerätetreiber nur mit dem gemeinsamen Untersatz von verfügbaren Befehlen geschrieben, die für alle Architekturen zur Verfügung stehen, für die der Treiber geschrieben wurde. In diesem Fall ist der Programmierer nicht in der Lage, die Leistung und Flexibilität der mehr entwickelten Architekturen auszunutzen.
Demzufolge besteht eine Notwendigkeit für einen Prozeß zur Optimierung von Software für die besondere Variante der Wirtsarchitektur, ohne daß fortgeschrittene Prozesse geopfert werden, die in den erweiterten Architekturen zur Verfügung stehen, und auch kein benutzerzugänglicher Speicherraum mit Codeversionen verschwendet wird, die in dem bestimmten Wirt nicht benutzt werden.
In EP-A-0100140 wird ein Verfahren zum Starten eines Datenverarbeitungssystems auf eine solche Weise offengelegt, daß es auf die gewünschte Weise funktioniert. Gemäß dieser Offenlegung schließt das Datenverarbeitungssystem einen grundlegenden Befehlssatz ein, der in den Mikroprozessor beim Starten unter der Kontrolle dieses grundlegenden Befehlssatzes geladen wird, der beim Starten in den Mikroprozessor geladen wird. Unter der Kontrolle dieses grundlegenden Befehlssatzes wird ein weiterer Mikrocode in den Hauptspeicher des Prozessors auf eine solche Weise übertragen, daß die gewünschte Betriebs-Software in den Prozessor geladen wird. In einer Ausführung dieser Offenlegung, wird ein Teil des erforderlichen Mikrocodes in einem Eingabe/Ausgabe-Gerät gespeichert und ein Teil dieses Vorgangs ist das Lokalisieren dieses Eingabe/Ausgabe-Gerätes zum Laden eines bestimmten Teiles des Betriebssystems.
Die vorliegende Erfindung wird in Anspruch 1 definiert (Verfahren zur Initialisierung von Software in einem VVirts-Datenverarbeitungssystem) und in Anspruch 15 (Verfahren zur automatischen Optimierung der Verwendung einer Mikroprozessoreinheit in einem Computersystem).
Die vorliegende Erfindung stellt ein Verfahren zur Initialisierung von Software in einem Wirts-Datenverarbeitungssystem bereit, wobei der Wirt irgendeine einer Vielfältigkeit von ändernden Architekturen besitzt, die aus folgendem besteht: Laden eines Software-Moduls in den Wirtsspeicher, einschließlich eines Satzes von Codeblocks, wobei jeder Codeblock für mindestens eine der Vielfältigkeit von ändernden Architekturen angepaßt wurde;
Identifizieren der ändernden Architektur des Wirts;
Auswahl eines Untersatzes aus dem Satz von Codeblocks, die für die identifizierte ändernde Architektur angepaßt wurde;
Lokalisieren des Untersatzes innerhalb des Wirtsspeichers in angrenzenden Speicherstellen; und
Freigabe von Speicherstellen des Software-Moduls im Wirtsspeicher außerhalb der angrenzenden Speicherstellen.
Die vorliegende Erfindung stellt somit ein Verfahren bereit, die es einem Programmierer ermöglicht, Software für eine Vielfältigkeit von ändernden Wirtsarchitekturen ohne übermäßige Verwendung von Wirtsspeicher zu implementieren, und außerdem nicht auf die Leistungsfähigkeit von High-End- Versionen der verfügbaren ändernden Architekturen zu verzichten.
Gemäß einem Aspekt der vorliegenden Erfindung, sind die Codeblocks in eine Vielfältigkeit von Funktionssegmenten geordnet, wobei jedes Segment mindestens einen Codeblock einschließt, der für mindestens eine ändernde Architektur optimiert wurde. Nach Identifizierung des Wirtssystems wird ein Codeblock aus jedem Funktionssegment in der Vielfältigkeit von Funktionssegmenten gewählt, um den speicherresidenten Teil des Wirtsspeichers des Betriebssystems zu bilden.
In einer Implementierung schließt das Initialisierungsmodul Tabellen zur Identifizierung von Speicherstellen von Codeblocks und von speicherstellenabhängigen Eintritten innerhalb der Codeblocks ein, die auf der identifizierten ändernden Architektur basieren. Um bestimmte Codeblocks zu wählen, greift das System auf die Tabellen als Reaktion auf die identifizierte ändernde Architektur zu, um die gewählten Codeblocks zu identifizieren, greift auf die gewählten Codeblocks zu und aktualisiert speicherstellenabhängige Eintragungen in den Codeblocks unter Benutzung der Tabellen.
Gemäß einem anderen Aspekt der Erfindung schließt das Initialisierungsmodul ein Programm zur Identifizierung der Wirtsarchitektur ein. Wenn die Wirtsarchitektur eine Konfigurationstabelle einschließt, so identifiziert dieses Programm den Wirt durch Analysieren der Konfigurationstabelle. Falls keine Konfigurationstabelle vorhanden ist, oder der Konfigurationsspeicher nicht genügend Informationen bereitstellt, führt das Programm Prüfungen durch, um die Merkmale der Wirtsarchitektur zum Zwecke der Identifizierung der Variante zu bestimmen, in die das Programm geladen wurde.
Die vorliegende Erfindung ist besonders zur Initialisierung von Betriebssystem-Software zur Steuerung eines Zusatzgerätes geeignet, wie beispielsweise ein Netzwerk-Schnittstellentreiber, falls der Netzwerk- Schnittstellentreiber Software zur Übermittlung und zum Empfang von Daten durch die Netzwerk-Schnittstelle einschließt.
Demzufolge ermöglicht es die vorliegende Erfindung einem Programmierer, ein einzelnes Initialisierungsmodul für die Benutzer seines Produktes in einer Vielfältigkeit von ändernden Architekturen bereitzustellen. Der Benutzer des Produktes ist dann von der Pflicht befreit, eine bestimmte Version des Gerätetreibers zu wählen. Der Code wird ohne Beteiligung des Benutzers und ohne Wirtsspeicherraum zu verschwenden, automatisch für die Architektur optimiert.
Weitere Aspekte und Vorteile der vorliegenden Erfindung können bei Überprüfung der Zahlen, der detaillierten Beschreibung und den nachstehenden Ansprüchen entnommen werden.

KURZE BESCHREIBUNG DER ZAHLEN

Abb. 1 zeigt ein Flußdiagramm eines Programms zur Initialisierung eines Computer-Betriebssystemprogramms gemäß der vorliegenden Erfindung.
Abb. 2 zeigt ein Blockdiagramm eines Teils eines Computersystems, das die Bewegung von ausführbaren Computer-Codes gemäß einer Ausführung der vorliegenden Erfindung zeigt.
Abb. 3 zeigt ein Blockdiagramm eines Stadiums der Speicherzuweisung während eines Schritts der Verarbeitung gemäß einer Ausführung der vorliegenden Erfindung.
Abb. 4 zeigt ein Blockdiagramm eines Stadiums der Speicherzuweisung während eines weiteren Schritts der Verarbeitung gemäß einer Ausführung der vorliegenden Erfindung.
Abb. 5 zeigt ein Blockdiagramm eines typischen Wirtssystems, in das die vorliegende Erfindung implementiert werden kann.
Abb. 6A zeigt ein Blockdiagramm eines initialisierten Moduls für OS/2 Betriebssystem-Umgebungen.
Abb. 6B zeigt ein Blockdiagramm des Initialisierungsmoduls für DOS Betriebssystem-Umgebungen.
Abb. 7 zeigt ein Flußdiagramm des Initialisierungsvorgangs gemäß einer bevorzugten Ausführung der vorliegenden Erfindung.
Abb. 8 zeigt ein Flußdiagramm eines Teils des Initialisierungscodes zur Analyse eines Konfiguationsspeicherbildes in einer bevorzugten Ausführung der vorliegenden Erfindung.
Abb. 9 zeigt ein Flußdiagramm zur Bestimmung einer Wirts-CPU-Type gemäß einer Ausführung der vorliegenden Erfindung.
Abb. 10 zeigt ein Flußdiagramm zur Bestimmung, ob physische oder virtuelle Adressenübersetzung im Wirts-Datenverarbeitungssystem gemäß einer bevorzugten Ausführung der vorliegenden Erfindung zulässig ist.
Abb. 11 zeigt ein Flußdiagramm, das die Verschiebung von Codeblocks gemäß einer Ausführung der vorliegenden Erfindung veranschaulicht.
Abb. 12 zeigt ein Diagramm einer Maschinen-Umgebungsvariable, das zur Wahl von Codeblocks gemäß einer bevorzugten Ausführung der vorliegenden Erfindung benutzt wird.
Abb. 13 zeigt ein schematisches Diagramm der Tabellen, die zur Wahl von Codeblocks und Aktualisierung von speicherstellenabhängigen Eingaben in Codeblocks, gemäß einer bevorzugten Ausführung der vorliegenden Erfindung benutzt werden.
Abb. 14 zeigt ein Blockdiagramm von einem Beispiel einer Verzeichnistabelle gemäß einer bevorzugten Ausführung der vorliegenden Erfindung.

DETAILLIERTE BESCHREIBUNG

Unter Bezugnahme auf die Abbildungen wird eine detaillierte Beschreibung der bevorzugten Ausführung der vorliegenden Erfindung bereitgestellt. Die Abb. 1-5 geben eine auswählbare Beschreibung der Erfindung, während die Abb. 6A, 6B und 7-14 zur Veranschaulichung einer bevorzugten Ausführung benutzt werden.

Übersicht

Unter Bezugnahme auf Abb. 1, wird dort ein Flußdiagramm 10 gezeigt, das eines der Verfahren gemäß der Erfindung darstellt. Abb. 2 veranschaulicht relevante Teile eines Computersystems 12 zur Veranschaulichung des Betriebs gemäß der Erfindung. Im Großspeicher 14 wird beispielsweise ein einzelnes ausführbares Computersystem-Programm gespeichert, das für jedes einzelne der verschiedenen Mikroprozessoren geeignet ist, wie beispielsweise die Familie "86" von Mikroprozessoren. Einzelne Elemente 16, 18, 20, 22 stellen verschiedene verschlüsselte Betriebssystem-Segmente dar, die einen Teil des Betriebssystem- Programms bilden, von denen jedoch jede für einen spezifischen Mikroprozessor 30 (einer noch zu identifizierenden Type) optimiert wird, und Programm-Element 24 stellt ein verschlüsseltes Betriebssystem-Segment dar, das genauso gut mit allen Typen von Mikroprozessoren 30 arbeitet. Eingeschlossen ist ein Programm- Element 26, das zu Identifizierung der Type des Mikroprozessors nützlich ist. Dieses Programm-Element 26 kann auf Befehle eingestellt werden, die einzig und allein mit jeder der Arten von Mikroprozessoren ablaufen und die mit einem Kennzeichen von einem gewissen Wert antworten, die eine Art des Mikroprozessors identifizieren. Es kann ein ausführbarer Code sein, der aus Reihe von Prüfungen besteht, der wahlweise Mikroprozessor-Typen eliminiert, die gewählt werden, ohne daß sie zu einem abbrechenden Versuch bei der Ausführung von Befehlen führen.
Der Prozeß gemäß der Erfindung startet mit dem Laden aller der Programmelemente 16, 18, 20, 22, 24, 26 des Betriebssystems aus einem Großspeichersystem 14 in den Systemspeicher 28 (Schritt A, Abb. 1).
Daraufhin wird das Programmelement 26 durch den Mikroprozessor 30 als Prüfung für die Type des Mikroprozessors 30, die benutzt wird, ausgeführt (Schritt B). Mit jeder Prüfung wird ein Kennzeichen-Signal 32 an das Programm-Modul als Parameter zur Verwendung bei der weiteren Ausführung des Programm-Elements 26 retourniert, bis die Type des Mikroprozessors, die verwendet wird, einmalig identifiziert ist.
Nachdem die Type des Mikroprozessors identifiziert wurde, identifiziert das Programm-Element 26, welche Teile von 34 selbst noch benötigt werden und welche Teile von 36, 38 nicht mehr benötigt werden (Abb. 3). Die Speicherstellen, die diesen nicht benötigten Teilen von 36, 38 entsprechen, werden zur Benutzung durch andere Programme (Schritt C) ausgelöst oder freigegeben. Um den Speicher des benötigten Teils von 34 zu verdichten, kann der benötigte Teil 34 innerhalb des Speichers 28 verschoben werden (Schritt D und Abb. 4). Die Zeiger zu den benötigten Teilen 34 werden zurückgestellt (Schritt E), und andere Teile des Betriebssystems (falls zutreffend) können geladen werden (Schritt F).
Die verschobenen Teile von 16, 18, 20 oder 22 können im benutzerzugänglichen Speicherraum oder im geschützten Speicherraum liegen wie Teile 16', 18', 20' oder 22, wie in Abb. 4 gezeigt. Die Wahl hängt normalerweise vom Mikroprozessor ab. Die Steuerung des Computers kann auf andere Prozesse umgeschaltet werden.
Netzwerk-Schnittstellentreiber einer bevorzuaten Ausführung Abb. 5 zeigt ein Schaltbild eines Wirts-Computersystems, in dem die bevorzugte Ausführung der vorliegenden Erfindung implementiert wird. Wie ersichtlich ist, schließt das Wirts-Computersystem eine Wirt-CPU-50 ein, die an den Wirts-Datenweg 51 gekoppelt ist. Außerdem ist ein Wirtsspeicher 52 angeschlossen, der an den VVirts-Datenweg angeschlossen ist. Die Architektur schließt außerdem ein Großspeichergerät 53 ein, wie ein Diskettenlaufwerk, das an den Wirts-Datenweg 51 angeschlossen ist. Zusatzgeräte wie die Anzeigensteuerung 54, die Netzwerk-Schnittstelle 55 und ein weiteres Zusatzgerät 56 sind ebenfalls an den Wirts-Datenweg gekoppelt. Die Netzwerk-Schnittstelle 55 im bevorzugten System ist an ein Ethernet-Netzwerk gekoppelt. Die bevorzugte Ausführung der vorliegenden Erfindung stellt ein Verfahren zur Optimierung eines Gerätetreibers für eine Netzwerk-Schnittstelle 55 für ein Ethernet-Netzwerk gemäß dem NDIS Standard bereit.***
Zwei Hauptziele der vorliegenden Erfindung sind die Schaffung des schnellstmöglichen Codes für eine ändernde Wirts-Architektur und die kleinste Menge von Wirtsspeicher zu belegen. Beide dieser Ziele werden durch die Benutzung der verschieblichen Codeblock-Technik erzielt, die oben dargelegt wird. In dem bevorzugten System wird die Technik zur Erstellung eines Treibers für die Netzwerk-Schnittstelle gemäß dem NDIS-Industriestandard benutzt. Ein derartiger Antrieb benötigt gewisse Funktionsblocks in allen der ändernden Wirts- Architekturen. Beispielsweise ist ein Funktionsblock das TransmitChain Verfahren. Im Initialisierungsmodul werden mehrere verschiedene Versionen des TransmitChain-Verfahrens in einem TransmitChain-Segment gespeichert. Eine Version wird für eine 286 Umgebung geschrieben und so weiter. Während der Initialisierung bestimmt der Gerätetreiber seine Umgebung und wählt das angemessene TransmitChain-Verfahren für diese Umgebung. Das gewählte Verfahren wird daraufhin an den Anfang des TransmitChain Segmentes verschoben. Die übrigen TransmitChain Verfahren, die für diese Umgebung nicht angemessen waren, werden überschrieben und abgelegt, wenn der Gerätetreiber von der Initialisierung zurückkehrt.
Diese verschiebliche Codeblock-Technik wird im bevorzugten System im gesamten leistungskritischen Gerätetreiber-Code implementiert. Das heißt, daß alle Codes außer dem Code im SupportCode-Segment in dieser Technik implementiert werden. Somit werden viele verschiedene Versionen der leistungskritischen Routinen so geschrieben, daß optimale Leistung und minimale Größe für fast jede ändernde Host-Architektur bereitgestellt wird.
Der daraus resultierende Gerätetreiber, schließt nach der Initialisierung die nachstehenden Codeblocks ein:
SupportCode
TransmitChain
TransferData
ISREntry/RCSComplete
XmitComplete
IndicationComplete/ISRExit
IndicationOn/IdicationOff
Somit wird mit Ausnahme des SupportCode Blocks, ein Funktionssegment, einschließlich einer Vielfältigkeit von Codeblocks, die für eine bestimmte Anwendung optimiert werden, für jede der sechs verbleibenden Funktionen bereitgestellt.
Es ist wahrnehmbar, daß eine Einschränkung auf Sprungbefehle und Aufrufbefehle auferlegt werden muß, die in diesen Blocks ausgeführt werden. Zwischen verschieblichen Codeblocks können keine zeigerbezogenen Sprungbefehle oder Aufrufbefehle durchgeführt werden. Damit Codes in einem Codeblock ein Verfahren in einem anderen Codeblock aufrufen, muß ein indirekter Sprungbefehl durch eine Variable im Datensegment durchgeführt werden. Hierdurch wird der Befehlszeiger mit einer absoluten Byteversetzung vom Anfang des Codesatzes, keine relative Byteversetzung geladen.
Die Struktur der Funktionssegmente wird in Abb. 6A für eine OS/2 Umgebung und in Abb. 6B für eine DOS-Umgebung veranschaulicht. Somit werden in der OS/2 Umgebung die Datensegmente, einschließlich devHeader Seg, ResDataSeg und InitDataSeg in einen Datenteil des Wirtsspeichers geladen, auf den durch ein Datensegment-Wähler DS zeigt. Die Funktionscode-Segmente werden in den SupportCodeSeg, TransmitChainSeg, TransferDataSeg, ISREntrySeg, XmitCompleteSeg, ISRExitSeg, IndicationsSeg und InitCodeSeg geladen und ein Codesegmentzähler zeigt auf dieselben. In der DOS-Umgebung ist die Reihenfolge der Segmente etwas anders, da die Daten- und Codesegmente nicht innerhalb des Speichers aufgeteilt sind. Somit ist in der DOS-Umgebung, wie in Abb. 6B gezeigt, die Reihenfolge der Segmente wie folgt: devHeaderSeg, ResDataSeg, SupportCodeSeg, TransmitChainSeg, ISREntrySeg, TransmitCompleteSeg, ISRExitSeg, IndicationsSeg, InitCodeSeg, InitDataSeg.
Wie oben erwähnt, wird, wenn der Gerätetreiber zuerst in den Speicher geladen wird, jedes der leistungskritischen Programm-Segmente aus mindestens einem Codeblock gebildet, jeder Codeblock wird für eine oder mehrere bestimmte ändernde Architekturen optimiert, in denen der Ablauf des Gerätetreibers vorgesehen ist.
Der Initialisierungsprozeß für diese bevorzugte Ausführung wird in Abb. 7 veranschaulicht. Der Prozeß beginnt, wenn das Betriebssystem das Programmbild des Gerätetreibers von einem sekundären Speichergerät liest und es in den Speicher lädt. Das Betriebssystem verzweigt sich dann zum Initialisierungscode des Programms, InitCodeSeg, der in den Speicher geladen wurde.
Der Initialisierungsprozeß schließt die in Abb. 7 veranschaulichten Schritte ein.
Wie oben erwähnt, beginnt der Prozeß mit dem Laden des Programms und dem Aufrufen des Initialisierungscodes (Block 70). Der erste Schritt schließt das Drucken einer Meldung am Anzeige-Terminal ein, das die Software identifiziert, die initialisiert wird (Block 71). Als nächstes sucht der Gerätetreiber nach einem unbenutzten Gerätetreiber-Namen unter allen übrigen Gerätetreibern, die geladen wurden (Block 72). Beim dritten Schritt wird der Protokoll-Manager geöffnet, um einen Zeiger auf ein Konfigurations-Speicherbild zu erhalten, wenn ein solcher Konfigurations-Speicher besteht (Block 73). Als nächstes wird das Konfigurations- Speicherbild analysiert, um Kennworte und Parameter zu identifizieren, die den Gerätetreiber der Wirts-Architektur informieren (Block 74).
In Schritt 5 werden die Erweiterungsschlitze des Wirtscomputers auf einen Adapter abgetastet, der durch diesen Gerätetreiber gesteuert wird. Nachdem dieser gefunden wurde, werden die Konfigurations-Informationen gelesen (Block 75). In Schritt 6 werden die Variablen, die nicht zur Übersetzungszeit initialisiert werden konnten, jetzt initialisiert und der Code läuft ab, wodurch die Wirtsumgebung des Gerätetreibers bestimmt wird (Block 76).
In Schritt 7 werden die Codeblocks gewählt und verschoben, möglicherweise durch Überschreiben von Codeblocks, die nicht benötigt werden. Die Datenstrukturen, die zur Übersetzungszeit und in Schritt 6 initialisiert wurden (Block 76) werden benutzt, um den Verschiebungsprozeß zu führen. Die Wirtsumgebung, die in Schritt 4 bestimmt wurde (Block 74) und 6 (Block 76) wird ebenfalls zur Führung der Wahl und für den Verschiebungsprozeß benutzt (Block 77). In Schritt 8 wird die Zeitunterbrechungs-Serviceroutine der Gerätetreiber registriert, damit sie während jedem Uhrsignal des Zeitnehmers aufgerufen wird (Block 78). In Schritt 9 informiert der Gerätetreiber den Protokoll-Manager, daß er initialisiert wurde und in der Lage ist, sich mit anderen Modulen im System zu verknüpfen (Block 79).
Schließlich kehrt die Steuerung zum Wirts-Betriebssystem zurück (Block 80).
Wie oben erwähnt, besteht ein Teil des Initialisierungsprozesses darin, das Konfigurations-Speicherbild auf Kennworte und Parameter abzutasten (Block 74). Das Konfigurations-Speicherbild, oder CMI, ist eine Struktur im Speicher, die durch den Protokoll-Manager in Systemen der Type DOS oder OS/2 erstellt wird. Der Protokoll-Manager lädt vor dem Gerätetreiber der vorliegenden Erfindung und erstellt das Konfigurations-Speicherbild. Die im CMI gefundenen Kennworte und Parameter helfen dem Gerätetreiber dabei, seine Umgebung zu bestimmen.
Der Prozeß zur Analyse des Konfigurationsbildes wird in Abb. 8 veranschaulicht. Der Algorithmus beginnt mit der Analyse des Konfigurationsspeicher-Bildes (Block 81). In Schritt 1 wird die Struktur des Konfigurations-Speicherbildes abgetastet, wobei mit dem ersten Modul begonnen wird. Wenn ein Modul gefunden wird, das das Kennwort DRIVERNAME enthält und einen Parameter, der unserem Gerätetreiber-Namen entspricht, so beginnen wir mit der Untersuchung der Kennworte dieses Moduls, wobei wir mit dem ersten Kennwort beginnen (Block 82). Im zweiten Schritt wird das Kennwort mit einer Liste von gültigen Kennworten verglichen. Wenn eine Übereinstimmung gefunden wird, so verzweigt sich der Algorithmus zu Schritt 3, anderenfalls verzweigt sich der Algorithmus zu Schritt 4 (Block 83). In Schritt 3 wird ein Verfahren aufgerufen, um die Parameter der Kennworte zu validieren und die Umgebungs-Variable gemäß den Parametern des Kennwortes einzustellen (Block 84). In Schritt 4 bewegt sich das Programm zum nächsten Kennwort in der CMI weiter (Block 85).
In Schritt S, kehrt die Routine, falls keine weiteren Kennworte vorhanden sind, zur Haupt-Initialisierungsroutine zurück, anderenfalls macht der Prozeß eine Schleife zu Schritt 2 zurück (Block 86). Schließlich kehrt die Routine zum Haupt- Initialisierungsmodul (Block 87) zurück.
Wie oben erwähnt, kann eine festgelegte Wirtsarchitektur einen Konfigurationsspeicher einschließen oder auch nicht, oder es ist möglich, daß der Konfigurationsspeicher nicht genügend Informationen enthält, nach denen die Wirts-Architektur unzweideutig identifiziert werden kann. Somit schließt der Teil des Initialisierungsprozesses, wie in Abb. 7 veranschaulicht, die Ausführung von Prüfungen zu Bestimmung der Wirtsumgebung ein. Im ersten System werden zwei Aspekte der Umgebung automatisch bestimmt. Die CPU-Type des Wirtsgerätes und, ob der Gerätetreiber virtuelle bis physische Adreßübersetzungen unter dem OS/2 Betriebssystem ausführen kann.
Das Flußdiagramm zum Ablauf dieser Prüfungen wird in Abb. 9 veranschaulicht. Somit wird, wie oben erwähnt, eine Bestimmung der CPU-Type an Block 90 begonnen.
Die erste Prüfung besteht in der Bestimmung, ob der Stapelzeiger vermindert wird oder nicht, bevor er sich auf den Stapel schiebt (Block 91). Wenn der Stapelzeiger vor dem Verschieben vermindert wird, so wird die Prüfung durchgeführt, um zu bestimmen, ob eine 32-Positionen-Versetzung durchgeführt werden kann (Block 92). Wenn der Stapelzeiger vor dem Verschieben nicht vermindert wird, so wird eine Prüfung durchgeführt, um zu bestimmen, ob durch den SGDT-Befehl OXFFFF im oberen Byte gespeichert wird (Block 93).
Wenn von Block 92 eine 32-Positionen-Versetzung vorgenommen werden kann, so wird bestimmt, daß es sich bei der CPU um eine 8086 oder eine 8088 handelt (Block 94). Wenn eine 32-Positionen-Versetzung nicht durchgeführt werden kann, so handelt es sich bei der CPU um eine 80186 oder 80188 (Block 95). Wenn von Block 93 bestimmt wird, daß mit dem SGDT-Befehl OXFFFF im oberen Byte gespeichert wird, so handelt es sich bei der CPU um eine 80286 (Block 96). Anderenfalls wird eine Prüfung vorgenommen, um zu bestimmen, ob ein Ausrichtungsprüfungs-Kennzeichen eingestellt werden kann (Block 97).
Falls das Ausrichtungs-Kennzeichen nicht eingestellt werden kann, so handelt es sich bei der CPU um eine 80386 (Block 98). Anderenfalls handelt es sich bei der CPU um eine 80486 (Block 99). Nachdem die CPU-Type bestimmt wurde, ist dieser Algorithmus abgeschlossen (Block 100).
Der Algorithmus zur Bestimmung, ob virtuelle Adreßübersetzungen in der OS/2 Umgebung zulässig sind, wird in Abb. 10 veranschaulicht. Sie beginnt an Block 101, wo eine Bestimmung der Fähigkeit zur Adreßübersetzung aufgerufen wird. Dies wird bestimmt durch Bestimmung, ob die GDTR der physischen Adresse von Selektor 8 an Block 102 entspricht. Falls die GDTR der physischen Adresse von Selektor 8 entspricht, so kann die Adreßübersetzung durch den Gerätetreiber (Block 103) durchgeführt werden. Anderenfalls können Adreßübersetzungen nicht durch den Gerätetreiber durchgeführt werden (Block 104). Hierdurch wird die Fähigkeit zur Adreßübersetzung abgeschlossen (Block 105).
Nachdem die ändernde Architektur des Wirts-Datenverarbeitungssystems bestimmt wurde, kann mit dem Verschiebungsprozeß begonnen werden. Dieser Prozeß wird in Abb. 11 veranschaulicht. Wie gezeigt, beginnt der Code- Verschiebungsprozeß bei Block 110. Der erste Schritt beinhaltet die Einstellung der Empfangsadresse für verschobene Codeblocks und die Untersuchung des ersten Funktionssegments (Block 111). Als nächstes wird bestimmt, welcher Verfahrens- Codeblock im Segment verschoben wird (Block 112). Der Verfahrens-Codeblock wird dann zur Empfangsadresse verschoben und die Empfangsadresse wird auf das Ende des verschobenen Verfahrens-Codeblock (Block 113) eingestellt. Als nächstes wird auf das nächste Segment bezug genommen, wenn weitere Segmente überprüft werden müssen (Block 114). Wenn weitere Codeblocks vorhanden sind, so macht der Algorithmus eine Schleife zu Block 112. Anderenfalls werden beim Prozeß Codes zur Freigabe von Speicher über die derzeitige Empfangsadresse (Block 115) hinaus eingestellt, die in Block 113 am Ende des letzten verschobenen Verfahrenscodeblock eingestellt wurde. Dieser Vorgang stellt das Ende des Verschiebungsvorgangs dar (Block 116).
Im bevorzugten System wird die Verschiebungstechnik unter Benutzung einer Maschinenumgebungs-Variable und mehrerer Tabellen benutzt. Die Maschinenumgebungs-Variable wird in Abb. 12 veranschaulicht. Sie schließt eine Bit-Schablone ein, mit der die ändernde Wirts-Architektur bestimmt wird. In dieser Variable sind die gesamten Informationen enthalten, die erforderlich sind, um zu wählen, welcher Codeblock verschoben wird. Sie wird im ResDataSegment gespeichert. Die Variable wird mit einem Wert aller Nullen übersetzt. Die Felder darin werden während der Initialisierung an verschiedenen Punkten eingestellt, bevor die Verschiebung des Codes vorgenommen wird, und sie werden niemals geändert. Die Felder in dieser Bit-Schablonen-Variable schließen ein:
CPU Type an Positionen 2 : 0. Dieses Feld enthält einen Code für die CPU, in dem der Treiber abläuft. Die Werte für dieses Feld im bevorzugten System schließen ein:
000 für 8088 oder 80886 CPU
001 für 80188 oder 80186 CPU
010 für 80286 CPU
011 für 80386 CPU
100 für 80486 CPU
Weitere Bit-Kombinationen sind undefiniert, können jedoch für eine Vielzahl verschiedener CPU-Prozessoren benutzt werden.
Betriebssystem, Bit 3. Dieses Feld enthält ein Bit, das anzeigt, unter welchem Betriebssystem der Gerätetreiber abläuft. Es ist für DOS freigegeben und für OS/2 eingestellt.
DevHelp Aufrufbefehle benutzen, Bit 4. In der OS/e Umgebung bezeichnet dieses Bit, ob die DevHelp Routinen in den leistungskritischen Routinen aufgerufen werden. Wenn dieses Bit eingestellt ist, werden die DevHelp Routinen immer aufgerufen. Wenn das Bit freigegeben wird, wird der Treiber Codes ausführen, die dieselbe Funktion ausüben wie die DevHelp Aufrufbefehle, die die Leistung möglicherweise steigern. Dieses Bit hat in DOS-Umgebungen keine Bedeutung.
AsyncTransferData. Bit 5. Dieses Bit zeigt an, ob eine asynchrone Übertragungsdaten-Routine benutzt wird oder nicht. Zu diesem Zeitpunkt ist die Funktion asynchrone Übertragung von Daten kein definierter Teil des NDIS Standard, für den die bevorzugte Ausführung implementiert wird. Wenn jedoch das Bit eingestellt wird, wird die Funktion Daten übertragen asynchron arbeiten. Wenn es freigegeben ist, wird es asynchron arbeiten, wie in NDIS V2.0.1 definiert.
EarlyReceiveLookAhead, bit 6. Dieses Bit zeigt an, ob eine Funktion EarlyReceiveLookAhead in das Protokoll aufgerufen werden sollte. Zu diesem Zeitpunkt ist die Funktion EarlyReceiveLookAhead kein definiertes Teil des NDIS. Wenn dieses Bit eingestellt ist, ruft der Treiber EarlyReceiveLookAhead auf. Wenn das Bit freigegeben ist, wird ReceiveLookAhead aufgerufen.
AllowGDTAddresses, Bit 7. Dieses Bit bestimmt, ob der Treiber die Benutzung von GDT Selektoren in den Rahmen-Deskriptors unterstützt. Wenn dieses Bit eingestellt ist, können die GDT-Wähler zum Beschreiben der Rahmen benutzt werden (das Feld Zeiger-Type in einem Datenblock-Deskriptor kann auf 2 eingestellt werden). Wenn dieses Bit freigegeben ist, können nur physische Adressen zur Beschreibung der Rahmen benutzt werden. Dieses Bit hat für DOS- Versionen des Treibers keine Bedeutung.
Die übrigen Bits in dieser 16-Bit-Schablone werden nicht benutzt und sind im bevorzugten System immer auf Null eingestellt.
Die Funktionen AsynchtransferData und EarlyReceiveLookAhead sind Optimierungen des NDIS-Treibers, deren Implementierung für die vorliegende Erfindung nicht wichtig sind. Ihre Präsenz in der Maschinenumgebungs-Variable zeigt jedoch an, daß diese Variable für eine Vielzahl von Code-Optimierungen für eine bestimmte Architektur benutzt werden kann, mit Ausnahme von denjenigen, die von der Wirts-CPU und vom Betriebssystem abhängig sind.
Der Verschiebungscode wird vollständig durch Tabellen angetrieben. Es gibt vier Tabellen-Typen, die in Abb. 13 veranschaulicht werden und die den Verschiebungscode durch seine Arbeit führen. Zu diesen zählt die Hauptverschiebungstabelle 140, die Verzeichnistabelle 141, die Grenzentabellen 142, und die Adressentabellen 143. Diese Tabellen haben ihren Standort alle im InitDataSeg Segment des Initialisierungsmoduls.
Die Haupt-Verschiebungstabelle 140 ist die Haupttabelle, von auf alle übrigen Tabellen zugegriffen werden kann.
Es gibt eine Haupt-Verschiebungstabelle. Jede Eingabe in diese Tabelle entspricht einem Funktionssegment, das zu verschiebende Blocks einschließt. Beispielsweise bearbeitet eine Eingabe in diese Tabelle die Wahl und Verschiebung des TransmitChain Verfahrens im TransmitChain Segment. Die Eingaben in der Haupt-Verschiebungstabelle werden in der Reihenfolge verarbeitet, in der sie in der Tabelle erscheinen. Daher wird die erste Type von Codeblock in der Tabelle der erste Codeblock sein, der verschoben wird. Die zweite Eingabe in der Tabelle wird direkt nach diesem Codeblock plaziert, und so weiter. Der Code wird an den Anfang des Segmentes TransmitChain verschoben. Die Reihenfolge der Eingaben in dieser Tabelle muß der Reihenfolge der Segment- Definitionen entsprechen.
Das erste Wort 144 in der Haupt-Verschiebungstabelle 140 enthält die Anzahl von Eingaben in die Tabelle. Für das oben angegebene System würde die Zahl 6 lauten. Es ist jedoch so implementiert, daß es eine vorzeichenlose Ganzzahl an jeder beliebigen Stelle im Bereich von 0 bis 65535 sein kann. Jede Tabelleneingabe, z. B. 145, enthält zwei Worte. Das erste Wort 145a ist eine Byteversetzung zur Verzeichnistabelle für das Funktionssegment. Das zweite Wort 145b ist eine Byteversetzung vom Anfang der Datengruppe zu einer Grenztabelle für das Funktionssegment. Deshalb ist mit jedem Funktionssegment, einschließlich zu verschiebender Blocks, wie der TransmitChain, eine Indextabelle 141 und eine Grenztabelle 142 verbunden. Die Indextabelle 141 und die Grenztabelle 142 ermöglichen, daß der richtige Codeblock auf der Basis der Variablen der Maschinenumgebung gewählt und verschoben wird.
Die Indextabelle 141 stellt einen Mechanismus zur Konvertierung der Bits der Variable der Maschinenumgebung in ein Verzeichnis für die Grenztabelle bereit. Jede Eingabe in der Haupt-Verschiebungstabelle 140 zeigt auf eine andere Verzeichnistabelle 141. Die Verzeichnistabellen sind im InitDataSeg Segment fixiert.
Die durch die Verzeichnistabelle ausgeführte Konvertierung ermöglicht, daß die Grenztabelle kleiner wird als wenn keine Konvertierung vorgenommen würde. In der Variablen der Maschinenumgebung sind 16 Bits enthalten, die dazu benutzt werden können, einen Codeblock zur Verschiebung zu wählen. Dies bedeutet, daß möglicherweise aus über 65.000 Blocks gewählt werden kann, wenn gewählt wird, welcher Codeblock verschoben werden soll. Um diese Anzahl so zu reduzieren, daß sie leichter zu bewältigen ist, bildet die Verzeichnistabelle ein Verzeichnis, das nur auf den Bits der Variablen in der Maschinenumgebung basiert, die für diese Codeblock-Type relevant sind.
Beispielsweise können zwei TransmitChain Codeblocks geschrieben werden: eine Version 286 und eine Version 386/486. Um einen dieser beiden Codeblocks zu wählen, bestimmt der Schieber, ob es sich bei dem Prozessor um eine Version 286 oder eine 386/486 handelt. Alle übrigen Bits in der Variablen der Maschinenumgebung können ignoriert werden, da sie nicht beeinträchtigen, welcher Codeblock gewählt wird. Durch diese Konvertierung wird die Anzahl der Codeblocks verringert, aus denen gewählt werden muß, auf 2. Hierdurch wird die Größe der Grenztabelle erheblich verringert.
Das erste Wort 146 in der Verzeichnistabelle 141 enthält eine Anzahl von Eingaben in die Tabelle. Bei diesen handelt es sich um eine vorzeichenlose Ganzzahl die im Bereich von 0 bis 65.535 liegen kann. Jede Eingabe enthält drei Worte. Die Eingaben in die Verzeichnistabelle werden in der Reihenfolge verarbeitet, in der sie in der Tabelle erscheinen, beginnend mit der ersten Eingabe an der Byteversetzung 02.
Das erste Wort 147a jeder Eingabe 147 ist eine Bit-Schablone, die spezifiziert, welche Bits in der Variablen der Maschinenumgebung eingestellt werden müssen, damit dieses Grenzverzeichnisfeld als Verzeichnis für die Grenztabelle verwendet werden kann. Das zweite Wort 147b ist eine Bit- Schablone, die spezifiziert, welche Bits in der Variablen der Maschinenumgebung freigegeben sein müssen, damit das Grenzverzeichnis dieser Eingabe als Verzeichnis für die Grenztabelle benutzt werden kann. Das letzte
Feld 147c ikn jeder Verzeichnistabellen-Eingabe ist ein Wort, das ein Verzeichnis in der Grenztabelle enthält. Dieser Wert wird nur als Verzeichnis der Grenztabelle benutzt, wenn sowohl die Einstellung als die freigegebenen Bedingungen, die in den beiden vorhergehenden Worten spezifiziert werden, erfüllt werden. Wenn der Schieber auf eine Eingabe stößt, die sowohl die Einstellung als die freigegebenen Bedingungen erfüllt, so wird das Verzeichnis in der Grenztabelle, das durch diese Eingabe spezifiziert wird, benutzt und die übrigen Eingaben in der übrigen Verzeichnistabelle werden nicht verarbeitet.
Unter Verwendung des Beispiels TransmitChain, das oben beschrieben wird, könnte die Verzeichnistabelle aussehen, wie in Abb. 14 veranschaulicht. Das erste Wort 150 zeigt an, daß in der Tabelle zwei Eingaben vorhanden sind, eine für jede der beiden Versionen des TransmitChain Verfahrens, das in der Grenztabelle identifiziert wird. Durch die erste Eingabe in der Verzeichnistabelle wird veranlaßt, daß die erste Eingabe an Verzeichnis 0 gewählt werden muß, wenn Bit 1 in der Variablen der Maschinenumgebung eingestellt ist und Bits 2 und 0 freigegeben sind. Hierdurch wird die Version 80286 der TransmitChain Routine gewählt. Die übrigen Bits der Variablen der Maschinenumgebung werden ignoriert.
Die zweite Eingabe an der Byteversetzung 08 veranlaßt, daß die zweite Eingabe in der Grenztabelle an Verzeichnis 1 (0001 h) gewählt wird, wenn Bits 1 und 0 der Variablen der Maschinenumgebung eingestellt werden und Bit 2 freigegeben ist. Hierdurch wird die Version 80386 in der TransmitChain Routine gewählt.
Die Grenztabelle 142 enthält Eingaben, die einen Codeblock beschreiben.
Jede Eingabe in der Haupt-Verschiebungstabelle zeigt auf eine andere Grenztabelle. Die Grenztabellen befinden sich im Segment InitDataSeg. Ein Verzeichnis der Grenztabelle wird gebildet, wenn die entsprechende Verzeichnistabelle wie oben beschrieben verarbeitet wird. Die Größe der
Grenztabelle wird deshalb durch den höchsten Wert des Feldes Grenzverzeichnis der entsprechenden Verzeichnistabelle bestimmt.
Jede Eingabe in der Grenztabelle 142 schließt die drei Worte 148a, 148b, 148c ein. Das erste Wort 148a in jeder Eingabe der Grenztabelle 148 enthält eine Byteversetzung vom Anfang des Funktionssegmentes an eine Adressentabelle 143. Mit jedem Codeblock ist eine Adressentabelle, wie nachstehend beschrieben, verbunden. Das zweite Wort 148b in der Eingabe der Grenztabelle 148 ist eine Byteversetzung von der Codegruppe des Funktionssegmentes zum Anfang von Codeblock 149. Das dritte Wort 148c in der Eingabe 148 der Grenztabelle ist eine Byteversetzung über das Ende von Codeblock 149 hinaus. Somit stellt das zweite und dritte Wort die Grenzen des Codeblocks bereit. Diese Informationen werden benutzt, wenn der Codeblock während eines Verschiebungsprozesses in den niedrigeren Speicher verschoben wird.
Die Adressentabelle 143 enthält eine Liste mit speicherstellenabhängigen Eingaben im speicherresidenten Datensegment, die so geändert werden müssen, daß sie sich auf die entsprechenden Speicherstellen in einem verschobenen Codeblock beziehen. Beispielsweise muß die Eingabe in der MAC oberen Sendetabelle, die die Adresse der TransmitChain Routine enthält, so aktualisiert werden, daß sie auf die neue Speicherstelle der verschobenen TransmitChain zeigt. Mit jedem Codeblock ist eine Adressentabelle verbunden. Diese Tabellen haben ihren Standort im InitDataSeg Segment.
Das erste Wort 150 in der Adressentabelle enthält eine Reihe von Eingaben in die Tabelle. Hier handelt es sich um eine vorzeichenlose Ganzzahl, die von 0 bis 65.535 reichen kann. Die Eingaben in die Adressentabellen folgen diesem Wort. Jede Eingabe 151 in die Adressentabelle schließt die drei Worte 151a, 151b, 151c ein. Das erste Wort 151a in jeder Adressentabellen-Eingabe 151 enthält eine Byteversetzung vom Anfang des Codeblocks. Auf die Eingabe an dieser Byteversetzung zeigt eine Variable in einem Datensegment. Wenn beispielsweise der Eingabepunkt des TransmitChain Verfahrens in der Byteversetzung 1a hex im Codeblock ist (wie von der Codegruppe des Funktionssegments unterschieden), so wird 1a hex im ersten Wort 151a der Eingabe 151 plaziert. Das zweite Wort 151b in jeder Adressentabelle 151 enthält eine Byteversetzung in der Codegruppe des Funktionssegments zu einem Zeiger, der auf diesen Codeblock zeigt. Die Speicherstelle, auf die dieses Wort zeigt, wird auf den Wert eingestellt, der durch hinzufügen der Start-Speicherstelle des verschiebenden Codeblocks plus der Byteversetzung, die im ersten Wort 151a in jeder Adressentabellen-Eingabe 151 angegeben wird. Das dritte Wort 151c in jeder Eingabe der Adressentabelle 151 enthält ein Kennzeichen, das angibt, ob es sich bei dem Zeiger in der Codegruppe des Funktionssegments um einen nahen oder entfernten Zeiger handelt. Wenn das Wort richtig eingestellt ist, so wird davon ausgegangen, daß sich an dieser Speicherstelle ein entfernter Zeiger befindet und der Wert des Codesegments wird zusammen mit der Byteversetzung geschrieben. Wenn dieses Wort falsch ist, so wird davon ausgegangen, daß sich an dieser Speicherstelle der nahe Zeiger befindet und nur die Byteversetzung wird geschrieben.

IMPLEMENTIERUNG VON CODE-BEISPIELEN

Der Code, der diese Tabellen benutzt und die Variable der Maschinenumgebung für das DOS Betriebssystem und das OS/2 Betriebssystem sind für die vorliegende Erfindung repräsentativ und werden nachstehend bereitgestellt. Außerdem werden Beschreibungen der Codeblocks im bevorzugten System bereitgestellt.

DOSRelocateCode

Beschreibung - Diese Routine wird von der DOSdevInitInterrupt Routine aufgerufen. Die Variable von MachineEnvironment und alle der Verschiebungstabellen führen diesen Code durch den Verschiebungsprozeß. Eine äußere Schleife wiederholt sich durch alle Eingaben in der Haupt- Verschiebungstabelle. Jede Eingabe in der Verzeichnistabelle für die derzeitige Eingabe in der Haupt-Verschiebungstabelle wird in einer inneren Schleife untersucht. Nachdem eine Eingabe gefunden wurde, die der Konfiguration der Variable MachineEnvironment entspricht, wird die innere Schleife beendet und die entsprechende Eingabe in der Grenztabelle wird verarbeitet.
Zur Verarbeitung der Grenztabelle wird das erste Feld, das die Byteverzweigung zu einer Adressentabelle enthält, benutzt. Jede Eingabe in der Adressentabelle wird untersucht und die entsprechende Adresse im Datensegment "wird festgelegt". Daraufhin werden das zweite und dritte Feld in der Grenztabelle benutzt, um den Codeblock in das neue Codesegment zu verschieben. Nachdem der Codeblock verschoben wurde, wird die nächste Eingabe in der Haupt- Verschiebungstabelle verarbeitet.
Segment: InitCodeSeg
Eingaben: DS zeigt auf das Datensegment.
MachineEnvironment. Alle Bits, welche die Codeverschiebung beeinträchtigen, müssen initialisiert werden.
Verschiebungstabellen. Die Maschinentabellen müssen die ordnungsgemäßen Werte zur Führung dieses Verfahrens enthalten.
Ausgaben: Übertragungskennzeichen. Wenn das Übertragungskennzeichen eingestellt wird, so ist ein Fehler unterlaufen. Anderenfalls kein Fehler.
DX. Wenn ein Fehler unterlaufen ist, enthält DX die Byteversetzung zur Fehlermeldung.
Das Codesegment wird geändert.
RelocateCodeEnd. Diese Variable ist vom Anfang des Gerätetreibers zum Byte über das letzte Byte des Code, der verschoben wurde hinaus auf die Byteversetzung eingestellt.

OS/2 RelocateCode

Beschreibung - Diese Route wird von der OS2devInitStrategy Routine aufgerufen. Dieser Code wird durch die Variable MachineEnvironment und alle Verschiebungstabellen durch den Verschiebungsprozeß geführt. Eine äußere Schleife wiederholt diesen Vorgang durch alle Eingaben in der Haupt- Verzeichnistabelle. Jede Eingabe in der Verzeichnistabelle für die Eingabe der aktuellen Haupt-Verschiebungstabellen wird in einer inneren Schleife untersucht. Nachdem eine Eingabe gefunden wurde, die mit der Konfiguration der Variable MachineEnvironment übereinstimmt, wird die innere Schleife beendet und die entsprechende Eingabe in Grenztabelle wird verarbeitet.
Um die Grenztabelle zu verarbeiten, wird das erste Feld benutzt, das die Byteversetzung zu einer Adressentabelle enthält. Jede Eingabe in der Adressentabelle wird untersucht und die entsprechende Adresse im Datensegment "festgelegt". Das zweite und das dritte Feld in der Grenztabelle werden daraufhin dazu benutzt, um den Codeblock in das neue Codesegment zu verschieben.
Nachdem der Codeblock verschoben wurde, wird die nächste Eingabe in der Haupt-Verschiebungstabelle verarbeitet.
Segment: InitCodeSeg
Eingaben: DS zeigt auf das Datensegment.
MachineEnvironment. Alle Bits, welche die Verschiebung des Codes beeinträchtigen, müssen initialisiert werden.
Verschiebungstabellen [Relocation Tables] Die Verschiebungstabellen müssen die ordnungsgemäßen Werte zur Durchführung dieses Verfahrens enthalten.
Ausgaben: Übertragungskennzeichen. Wenn Übertragung eingestellt ist, so ist ein Fehler unterlaufen. Sonst, kein Fehler.
DX. Falls ein Fehler unterlaufen ist, enthält DX die Byteversetzung zur Fehlermeldung
Das Codesegment wird geändert.
RelocateCodeEnd. Diese Variable ist auf die Byteversetzung vom Anfang des Gerätetreibers bis zum Byte jenseits des letzten Bytes des Codes eingestellt, der verschoben wurde.

DOS leistungskritischer Code

Der leistungskritische Code ist der Code, der zur Übertragung und zum Empfang von Paketen benutzt wird. Hierzu zählen die TransmitChain, TransferData, die XmitComplete und RcvComplete Pfade in der Routine Service unterbrechen und die Verfahren und die IndicationOn/IndicationOff [Anzeige Ein/Anzeige Aus]. Diese Verfahren werden nachstehend zusammenfassend als Beispiele zum Implementierung der Erfindung beschrieben.
Es gibt mehrere Versionen jedes leistungskritischen Codeabschnittes, von denen eine während der Codeverschiebung gewählt und verschoben wird. Dies sind folgende Versionen:
TransmitChain - Startet die Übertragung eines Paketes
286
386
TransferData - Kopiert ein eingegangenes Paket auf die protokollverwalteten Puffer.
286
386
IndicationOn/IndicationOff - Schaltet Anzeigen ein und aus
286 und 386
ISR Entry and RcvComplete - Verarbeitet Paketeingang.
286
386
IndicationComplete and ISR Exit - Ermöglicht Protokoll die Nachverarbeitung
286
386
Xmit Complete - Verarbeitet Abschluß von Übertragung
286
386

DOS 286 TransmitChain

Beschreibung - Mit dieser Routine wird die Übertragung eines Paketes gestartet. Sie wird durch das Protokoll immer dann aufgerufen, wenn das Protokoll ein Paket übermitteln möchte. Der Code in dieser Routine wurde speziell für die DOS 80286 Umgebung optimiert. Mit dieser Routine werden die request handle, protocol id, immediate data count, data block count, immediate data und die Datenblock-Deskriptoren auf den Adapter kopiert.
Segment: TransmitChainSeg
Eingaben: SS : SO + 6 - Unser Datensegment-Wert.
SS : SP + 8 - Zeiger an einen Übertragungsrahmen- Puffer-Deskriptor.
SS : SP + 12 - Anforderung verarbeiten
SS : SP + 14 - Protokoll-Identifizierung
XmitAreaPtr - Diese Variable enthält einen entfernten Zeiger zum Gebietsverzeichnis für die Adaptersteuerung.
Ausgaben: Ax enthält einen NDIS Rücklaufcode.
Unterbrechungs- Status: Beim Eintritt ausgeschaltet, beim Verlassen ausgeschaltet.

DOS 386 TransmitChain

Beschreibung - Mit dieser Routine wird die Übertragung eines Paketes angezeigt. Es wird durch das Protokoll immer dann aufgerufen, wenn das Protokoll ein Paket übermitteln möchte. Der Code in dieser Routine wurde speziell für die DOS 80386/80486 Umgebung optimiert. Mit dieser Routine werden die request handle, protocol id, immediate data count, data block count, immediate data und die Datenblock- Deskriptoren auf den Adapter kopiert.
Segment: TransmitChainSeg
Eingaben: SS : SP + 6 - Unser Datensegment-Wert
SS: SP + 8 - Zeiger auf einen Übertragungsrahmen- Pufferdeskriptor.
SS: SP + 12 - Anforderung verarbeiten.
SS: SP + 14 - Protokoll-Identifizierung.
AdapterSegment - Diese Variable enthält den Segment-Selektor des Adapter RAM.
Ausgaben: AX enthält einen NDIS Rücklaufcode.
Unterbrechungs- Status: Beim Eintritt ausgeschaltet und beim Verlassen eingeschaltet.

DOS 286 TransferData

Beschreibung - Mit dieser Routine wird ein empfangenes Paket auf protokollverwaltete Puffer kopiert. Der Code in dieser Routine wurde speziell für die DOS 80286 Umgebung optimiert. Die Anzahl der Übertragungs-Datenblocks, der Rahmen-Byteversetzung und Übertragungsdatenblock-Deskriptoren werden an den Adapter geschrieben. Die Übertragung wird dann durch Lesen des XferQueueStatus Verzeichnisses und der Treiber-Abfrager gestartet bis die Übertragung abgeschlossen ist. Wenn die Übertragung abgeschlossen ist, wird der Status der Übertragung an das Protokoll retourniert.
Segment: TransferDataSeg
Eingaben: SS : SP + 6 - Unser Datensegment-Wert
SS : SP + 8 - Entfernter Zeiger auf einen Übertragungsdaten-Deskriptor.
SS : SP + 12 - Startet Byteversetzung in Rahmen zur Übertragung.
SS : SP + 14 - Entfernter Zeiger auf ein Wort, das eine Anzahl von kopierten Bytes enthält AdapterSegment - Enthält den RAM-Segment- Selektor des Adapters.
Ausgaben: AX enthält einen NDIS Rücklaufcode.
Unterbrechungs- Status: Unverändert.

DOS 386 TransferData

Beschreibung - Mit dieser Routine wird ein empfangenes Paket auf protokollverwaltete Puffer kopiert. Der Code in dieser Routine wurde speziell für die DOS 80386/80486 Umgebung optimiert. Die Anzahl der Übertragungs- Datenblocks, der Rahmen-Byteversetzung und Übertragungsdatenblock- Deskriptoren werden an den Adapter geschrieben. Die Übertragung wird dann durch Lesen des XferQueueStatus Verzeichnisses und der Treiber-Abfrager gestartet bis die Übertragung abgeschlossen ist. Wenn die Übertragung abgeschlossen ist, wird der Status der Übertragung an das Protokoll retourniert.
Segment: TransferDataSeg
Eingaben: SS : SP + 6 - Unser Datensegment-Wert
SS : SP + 8 - Entfernter Zeiger auf einen Übertragungsdaten-Deskriptor.
SS : SP + 12 - Startet Byteversetzung in Rahmen zur Übertragung.
SS : SP + 14 - Entfernter Zeiger auf ein Wort, das eine Anzahl von kopierten Bytes enthält AdapterSegment - Enthält den RAM-Segment- Selektor des Adapters.
Ausgaben: AX enthält einen NDIS Rücklaufcode.
Unterbrechungs- Status: Unverändert.

DOS IndicationOn

Beschreibung - Mit dieser Routine werden die Anzeigen eingeschaltet. Der Adapter verarbeitet den Anzeigezähler und das Einschalten der Anzeigen. Mit dieser Routine wird einfach auf das IndicationOn Verzeichnis in der Adapter- Steuereinheit geschrieben.
Segment: IndicationsSeg
Eingaben: SS : SP + 6 - Unser Datensegment-Wert.
Ausgaben: AX enthält einen NDIS Rücklaufcode (immer ERFOLGREICH).
Unterbrechungs- Status: Wird beim Eintritt gelöscht und nicht wieder eingeschaltet.

DOS IndicationOff

Beschreibung - Mit dieser Routine werden die Anzeigen ausgeschaltet. Der Adapter verarbeitet den Anzeigenzähler und das Ausschalten der Anzeigen. Mit dieser Routine wird einfach auf das IndicationOff Verzeichnis in der Adapter-Steuereinheit geschrieben.
Segment: IndicationsSeg
Eingaben: SS : SP + 6 - Unser Datensegment-Wert.
Ausgaben: AX enthält einen NDIS Rücklaufcode (immer ERFOLGREICH).
Unterbrechungs- Status: Wird bei der Eingabe gelöscht und nicht wieder eingeschaltet.

DOS 286 ISREntry

Beschreibung - Diese Routine enthält den Vektor-Unterbrechungs- Eintrittspunkt. Der Code in dieser Routine wurde speziell für die DOS 80286 Umgebung optimiert. Der ISREntry Code verarbeitet die "Haushaltspflichten", die verrichtet werden müssen, bevor die Anzeige(n), welche die Unterbrechung verursacht haben, verarbeitet werden können. Mit dieser Routine wird zuerst geprüft, ob die Unterbrechung durch unseren Unterbrecher verursacht wurde oder ob wir mit einer anderen Unterbrechungs-Service-Routine verketten müssen. Dann werden alle Verzeichnisse auf dem Stapel gespeichert und wir schalten die Stapel auf unseren eigenen privaten Unterbrechungs-Stapel um. Alle Adapter- Unterbrechungen werden ausgeschaltet und System-Unterbrechungen wieder eingeschaltet.
Diese Routine enthält ebenfalls den Code zur Bearbeitung einer empfangenen Paketanzeige. Da es sich bei dieser Anzeige um die üblichste Type der Anzeige handelt, wird sie als "Fall-Through" Code behandelt. Die übrigen Anzeigen werden durch Springen durch eine Sendetabelle behandelt. Wenn die Anzeige durch ein empfangenes Paket verursacht wurde, wird RcvFrameStatus abgefragt, um zu überprüfen, ob das Paket vollständig empfangen wurde.
Daraufhin wird das Verzeichnis LengthLeftThresh, falls erforderlich, geändert und ReceiveLookAhead wird aufgerufen. Das LookAhead Fenster wird daraufhin erweitert.
Eine Sendetabelle wird benutzt, um zur nächsten Anzeige zu springen, die verarbeitet werden muß. Falls keine weiteren Anzeigen mehr verarbeitet werden müssen, springt die Sendetabelle zu dem Code, der von der Unterbrechungs- Service-Routine heausspringt.
Segment: ISREntrySeg
Eingaben: Keine.
Ausgaben: DS wird auf den RAM Segment-Selektor des Adapters eingestellt.
Unterbrechungs- Status: Beim Eintritt ausgeschaltet und beim Verlassen eingeschaltet.

DOS 386 ISREntry

Beschreibung - Diese Routine enthält den Vektor Unterbrechungs- Eintrittspunkt für die Adapter-Unterbrechung. Der Code in dieser Routine wurde speziell für die DOS 80386/80486 Umgebung optimiert. Der ISREntry Code bearbeitet die "Haushaltspflichten", die erledigt werden müssen, bevor die Anzeige(n) bearbeitet werden kann (können), die die Unterbrechung verursacht haben. Bei dieser Routine wird zuerst geprüft, ob unser Adapter die Unterbrechung erzeugt hat oder ob wir mit einer anderen Unterbrechungs-Service-Routine verknüpfen müssen. Daraufhin werden alle Verzeichnisse auf dem Stapel gespeichert und wir schalten die Stapel auf unseren eigenen privaten Unterbrechungs-Stapel um. Alle Adapter-Unterbrechungen werden ausgeschaltet und die System-Unterbrechungen wieder eingeschaltet.
Diese Routine enthält ebenfalls den Code zur Bearbeitung einer empfangenen Paketanzeige. Da es sich bei dieser Anzeige um die üblichste Type von Anzeigen handelt, wird sie als "Fall-Through" Code behandelt. Die übrigen Anzeigen werden durch Springen durch eine Sendetabelle bearbeitet. Falls die Anzeige durch ein empfangenes Paket verursacht wurde, wird der RcvFrameStatus abgefragt, um zu überprüfen, ob das Paket vollständig empfangen wurde.
Daraufhin wird das Verzeichnis LengthLeftThresh, falls erforderlich, geändert und ReceiveLookAhead wird aufgerufen. Anschließend wird das Fenster SlapStick LookAhead erweitert.
Eine Sendetabelle wird benutzt, um zur nächsten Anzeige zu springen, die verarbeitet werden muß. Falls keine weiteren Anzeigen mehr verarbeitet werden müssen, springt die Sendetabelle zu dem Code, der von der Unterbrechungs- Service-Routine herausspringt.
Segment: ISREntrySeg
Eingaben: Keine
Ausgaben: DS wird auf den RAM Segment-Selektor des Adapters eingestellt.
Unterbrechungs- Status: Beim Eintritt ausgeschaltet und beim Verlassen eingeschaltet.

DOS 286 XmitComplete

Beschreibung - Diese Routine wird durch die Tabelle PrimaryIntDispatch oder SecondaryIntDispatch aufgerufen, wenn eine XmitComplete Anzeige auftritt. Dieser Code wird speziell für die DOS 80286 Umgebung optimiert. Mit dieser Routine wird das XmitCompleteThresh Verzeichnis, falls erforderlich, eingerichtet und das Übertragungs-Bestätigungsverfahren aufgerufen.
Eine Sendetabelle wird benutzt, um zur nächsten Anzeige zu springen, die verarbeitet werden muß. Wenn keine weiteren Anzeigen mehr verarbeitet werden müssen, verzweigt sich die Sendetabelle zu dem Code, der bei der Unterbrechungs-Service-Routine herausspringt.
Segment: XmitCompleteSeg
Eingaben: DS wird auf den RAM Segment-Selektor des Adapters eingestellt.
Ausgaben: Keine.
Unterbrechungs- Status: Beim Eintritt unbekannt und unverändert.

DOS 286 XmitComplete

Beschreibung - Diese Routine wird durch die Tabelle PrimaryIntDispatch oder SecondaryIntDispatch aufgerufen, wenn eine XmitComplete Anzeige auftritt.
Dieser Code wird speziell für die DOS 80386/80486 Umgebung optimiert. Mit dieser Routine wird das XmitCompleteThresh Verzeichnis, falls erforderlich, eingerichtet und das Übertragungs-Bestätigungsverfahren aufgerufen.
Eine Sendetabelle wird benutzt, um zur nächsten Anzeige zu springen, die verarbeitet werden muß. Wenn keine weiteren Anzeigen mehr verarbeitet werden müssen, verzweigt sich die Sendetabelle zu dem Code, der bei der Unterbrechungs-Service-Routine herausspringt.
Segment: XmitCompleteSeg
Eingaben: DS wird auf den RAM Segment-Seiektor des Adapters eingestellt.
Ausgaben: Keine.
Unterbrechungs- Status: Beim Eintritt unbekannt und unverändert.

DOS 286 ISRExit

Beschreibung - Diese Routine wird verzweigt zur PrimaryIntDispatch oder SecondaryIntDispatch Tabelle. Diese Routine wird für die DOS 80286 Umgebung optimiert. Der Zweck dieser Routine ist das Aufrufen der vollständigen Anzeige, falls erforderlich und die Rückkehr vom Unterbrechungs-Kontext.
Segment: ISRExitSeg
Eingaben: DS enthält den RAM Segment-Selektor des Adapters.
Ausgaben: Keine.
Unterbrechungs- Status Beim Eintritt gelöscht, eingeschaltet, wenn IndicationComplete aufgerufen wird, eingeschaltet, wenn der IRET-Befehl ausgeführt wird.

DOS 386 ISRExit

Beschreibung - Diese Routine wird zur Tabelle PrimaryIntDispatch oder SecondaryIntDispatch verzweigt. Diese Routine wurde für die DOS 80386180486 Umgebung optimiert. Der Zweck dieser Routine ist das vollständige Aufrufen der Anzeige, falls erforderlich und die Rückkehr vom Unterbrechungs-Kontext. Segment: ISRExitSeg
Eingaben: DS enthält den RAM Segment-Selektor des Adapters.
Ausgaben: Keine.
Unterbrechungs- Status: Beim Eintritt gelöscht, eingeschaltet, wenn IndicationComplete aufgerufen wird, eingeschaltet, wenn der IRET- Befehl ausgeführt wird.

DOS OtherIndication

Beschreibung - Diese Routine wird von den übrigen Anzeige- Steuerprogrammen über die Tabelle PrimaryIntDispatch oder SecondaryIntDispatch aufgerufen. Der Zweck dieser Routine ist die Bearbeitung einer OtherIndication Anzeige (Bit 5 im Verzeichnis IndicationComplete). Die Anzeige OtherIndication kann durch eine von drei Ereignisse verursacht werden. Erstens, wenn das Protokoll zur Erstellung einer Unterbrechung aufgefordert hat, so wird diese Anzeige erstellt. Durch diese Routine wird die Unterbrechungs- Statusanzeige des Protokolls aufgerufen.
Zweitens, wenn das Protokoll dazu aufgefordert hat, daß der MAC-Treiber zurückgestellt wird, so wird diese Anzeige erstellt. Mit dieser Routine werden die Status-Anzeigen StartReset und Endreset aufgerufen und die tatsächliche Rückstellung des Adapters und des MAC-Treibers durchgeführt.
Der dritte Grund für die Erstellung dieser Anzeige ist, daß dem Sender ein Unterlauf-Fehler unterlaufen ist. Dies wird verursacht, wenn der Adapter ein Paket auf dem Netzwerk schneller überträgt, als der Bus-Hauptrechner das Paket auf den Adapter übertragen kann. In diesem Falle wird das Verzeichnis XmitStartThresh vergrößert, um zu ermöglichen, daß mehr Daten im Adapter speicherresident sein können, bevor die Übertragung beginnt.
Segment: SupportCodeSeg
Eingaben: DS enthält den RAM Segment-Selektor des Adapters.
Ausgaben: Keine.
Unterbrechungs- Status: Beim Eintritt unbekannt, kann jedoch eingeschaltet werden.

OS/2 LEISTUNGSKRITISCHER CODE

Für jeden leistungskritischen Code-Abschnitt gibt es mehrere Versionen, von denen eine gewählt und während der Code-Verschiebung verschoben wird. Diese Versionen für die OS/2 Umgebung schließen ein:
TransmitChain - Startet die Übertragung eines Paketes 286, Kein GDT zulässig
386, Kein GDT zulässig
286, GDT zulässig
386, GDT zulässig
TransferData - Kopiert ein empfangenes Paket auf protokollverwaltete Puffer
286, Kein GDT zulässig
386, Kein GDT zulässig
286, GDT zulässig
386, GDT zulässig
IndicationOn/IndicationOff - Schaltet die Anzeigen ein und aus. Version 286 und 386
ISR Entry und RcVComplete - Verarbeitet Paketempfang
286, Kein DevHlp
386, Kein DevHlp
386, Kein DevHlp
386, DevHfp
Indication Complete und ISR Exit - Ermöglicht Nachverarbeitung durch das Protokoll
286
386
XmitComplete - Verarbeitet Abschluß von Übertragung
286
386

OS/2 286 NoGDT TransmitChain

Beschreibung - Mit dieser Routine wird die Übertragung eines Paketes gestartet. Sie wird durch das Protokoll immer dann aufgerufen, wenn das Protokoll ein Paket übertragen möchte. Der Code in dieser Routine wurde speziell für die OS/2 Umgebung optimiert, wenn GDT-Adressen für Datenpuffer-Deskriptoren nicht zulässig sind. Durch diese Routine werden request handle, protocol id, immediate data count, data block count, immediate data und die Datenblock-Deskriptoren an den Adapter kopiert.
Segment: TransmitChainSeg
Eingaben: SS : SP + 6 - Unser Datensegment-Wert
SS : SP + 8 - Zeiger zu einem Puffer-Deskriptor
eines Übertragungsrahmens.
SS : SP + 12 - Bearbeitung anfordern.
SS : SP + 14 - Protokoll-ID.
SegmentSelector - Diese Variable enthält das Segment Selektor des Adapter RAM.
Ausgaben: AX enthält einen NDIS Rücklaufcode.
Unterbrechungs- Status: Beim Eintritt ausgeschaltet und beim Verlassen eingeschaltet.

OS/2 286 GDT TransmitChain

Beschreibung - Mit dieser Routine wird die Übertragung eines Paketes gestartet. Sie wird durch das Protokoll immer dann aufgerufen, wenn das Paket ein Protokoll übertragen möchte. Der Code in dieser Routine wurde speziell für die OS/2 Umgebung optimiert, wenn GDT-Adressen für Datenpuffer- Deskriptoren zulässig sind. Mit dieser Routine werden request handle protocol ID, immediate data count, data block count, immediate data und die Datenblock- Deskriptoren an den Adapter kopiert.
Segment: TransmitChainSeg
Eingaben: SS : SP + 6 - Unser Datensegment-Wert.
SS : SP + 8 - Zeiger zu einem Puffer-Deskriptor eines Übertragungsrahmens.
SS : SP + 12 - Bearbeitung anfordern.
SS : SP + 14 - Protokoll-ID.
XmitAreaPtr - Diese Variable enthält einen
entfernten Zeiger zum XmitArea Verzeichnis.
Ausgaben: AX enthält einen NDIS Rücklaufcode.
Unterbrechungs- Status: Beim Eintritt ausgeschaltet und beim Verlassen eingeschaltet.

OS/2 386 GDT Transmit/Chain

Beschreibung - Mit dieser Routine wird die Übertragung eines Paketes gestartet. Sie wird durch das Protokoll immer dann aufgerufen, wenn das Paket ein Protokoll übertragen möchte. Der Code in dieser Routine wurde speziell für die OS/2 80386/80486 Umgebung optimiert, wenn GDT-Adressen für Datenpuffer-Deskriptoren zulässig sind.
Mit dieser Routine werden request handle, protocol ID, immediate data count, data block count, immediate data und die Datenblock-Deskriptoren an den Adapter kopiert.
Segment: TransmitChainSeg
Eingaben: SS : SP + 6 - Unser Datensegment-Wert.
SS : SP + 8 -Zeiger zu einem Puffer-Deskriptor eines Übertragungsrahmens.
SS : SP + 12 - Bearbeitung anfordern.
SS : SP + 14 - Protokoll-ID.
SegmentSelector - Diese Variable enthält den Segment-Selektor des Adapter RAM.
Ausgaben: AX enthält einen NDIS Rücklaufcode.
Unterbrechungs- Status: Beim Eintritt ausgeschaltet und beim Verlassen eingeschaltet.

OS/2 NoGDT TransferData

Beschreibung - Mit dieser Routine wird ein eingegangenes Protokoll an protokollverwaltete Puffer kopiert. Der Code in dieser Routine wurde speziell für die OS/2 80286 Umgebung optimiert, wenn GDT-Selektoren in Datenpuffer-Deskriptoren nicht zulässig sind. Die Anzahl der Übertragungs- Datenblocks, die Rahmen-Byteversetzung und die Übertragungsdaten- Blockdeskriptoren werden an den Adapter geschrieben. Daraufhin wird die Übertragung durch Lesen des XferQueueStatus Verzeichnisses und der Antriebs- Abfragung gestartet bis die Übertragung abgeschlossen ist. Wenn die Übertragung abgeschlossen ist, wird der Status der Übertragung zum Protokoll retourniert.
Segment: TransferDataSeg
Eingaben: SS : SP + 6 - unser Datensegment-Wert.
SS : SP + 8 - Entfernter Zeiger zu einem Übertragungsdaten-Deskriptor.
SS : SP + 12 - Starten der Byteversetzung in Rahmen zur Übertragung.
SS : SP + 14 - Entfernter Zeiger auf ein Wort, da die Anzahl der kopierten Bytes enthält.
SegmentSeletor - Enthält den Segmentselektor des Adapers.
Ausgaben: AX enthält einen NDIS-Rücklaufcode
Unterbrechungs- Status: Unverändert.

OS/2 386 NoGDT TransferData

Beschreibung - Mit dieser Routine wird ein empfangenes Paket auf protokollverwaltete Puffer kopiert. Der Code in dieser Routine wurde speziell für die OS/2 80386/80486 Umgebung optimiert, wenn GDT-Selektoren in Datenpuffer- Deskriptoren nicht zulässig sind. Die Anzahl der Übertragungs-Datenblocks, der Rahmen-Byteversetzung und der Übertragungs-Datenblock Deskriptoren werden an den Adapter geschrieben. Daraufhin wird die Übertragung durch Lesen des XferQueueStatus und der Antriebs-Abfragungen gestartet, bis die Übertragung abgeschlossen ist. Wenn die Übertragung abgeschlossen ist, kehrt die Übertragung zum Protokoll zurück
Segment: TransferDataSeg
Eingaben: SS : SP + 6 - Unser Datensegment-Wert
SS : SP + 8 - Entfernter Zeiger auf einen Übertragungsdaten-Deskriptor.
SS : SP + 12 - Startet Byteversetzung in Rahmen zur Übertragung.
SS : SP + 14 - Entfernter Zeiger auf ein Wort, das eine Anzahl von kopierten Bytes enthält.
SegmentSelector -Enthält den RAM-Segment-Selektor des Adapters.
Ausgaben: AX enthält einen NDIS Rücklaufcode.
Unterbrechungs- Status: Unverändert.

OS/2 286 GDT TransferData

Beschreibung - Mit dieser Routine wird ein empfangenes Paket auf protokollverwaltete Puffer kopiert. Der Code in dieser Routine wurde speziell für die OS/2 80386/80486 Umgebung optimiert, wenn GDT-Selektoren in Datenpuffer- Deskriptoren nicht zulässig sind. Die Anzahl der Übertragungs-Datenblocks, der Rahmen-Byteversetzung und der Übertragungs-Datenblock Deskriptoren werden an den Adapter geschrieben. Daraufhin wird die Übertragung durch Lesen des XferQueueStatus und der Antrieb-Abfragungen gestartet, bis die Übertragung abgeschlossen ist. Wenn die Übertragung abgeschlossen ist, kehrt die Übertragung zum Protokoll zurück.
Segment: TransferDataSeg
Eingaben: SS : SP + 6 - Unser Datensegment-Wert
SS : SP + 8 - Entfernter Zeiger auf einen Übertragungsdaten-Deskriptor.
SS : SP + 12 - Startet Byteversetzung in Rahmen zur Übertragung.
SS : SP + 14 - Entfernter Zeiger auf ein Wort, das eine Anzahl von kopierten Bytes enthält.
SegmentSelector - Enthält den RAM-Segment-Selektor des Adapters.
Ausgaben: AX enthält einen NDIS Rücklaufcode.
Unterbrechungs- Status: Unverändert.

OS/2 386 GDT TransferData

Beschreibung - Mit dieser Routine wird ein empfangenes Paket auf protokollverwaltete Puffer kopiert. Der Code in dieser Routine wurde speziell für die OS/2 80386/80486 Umgebung optimiert, wenn GDT-Selektoren in Datenpuffer- Deskriptoren nicht zulässig sind. Die Anzahl der Übertragungs-Datenblocks, der Rahmen-Byteversetzung und der Übertragungs-Datenblock Deskriptoren werden an den Adapter geschrieben. Daraufhin wird die Übertragung durch Lesen des XferQueueStatus und der Antriebs-Abfragungen gestartet, bis die Übertragung abgeschlossen ist. Wenn die Übertragung abgeschlossen ist, kehrt der Status der Übertragung zum Protokoll zurück.
Segment: TransferDataSeg
Eingaben: SS : SP + 6 - Unser Datensegment-Wert
SS : SP + 8 - Entfernter Zeiger auf einen Übertragungsdaten-Deskriptor.
SS : SP + 12 - Startet Byteversetzung in Rahmen zur Übertragung.
SS : SP + 14 - Entfernter Zeiger auf ein Wort, das eine Anzahl von kopierten Bytes enthält.
SegmentSelector - Enthält den RAM-Segment-Selektor des Adapters.
Ausgaben: AX enthält einen NDIS Rücklaufcode.
Unterbrechungs- Status: Unverändert.

OS/2 IndicationOn

Beschreibung - Mit dieser Routine werden die Anzeigen eingeschaltet. Der Adapter bearbeitet den Anzeigezähler und das Einschalten der Anzeigen. Mit dieser Routine wird einfach auf das IndicationOn Verzeichnis der Adapter- Steuereinheit geschrieben.
Segment: IndicationSeg
Eingaben: SS : SP + 6 - Unser Datensegment-Wert.
SegmentSelector - Enthält RAG-Segment-Selektor des Adapters.
Ausgaben: AX enthält einen NDIS Rücklaufcode (immer ERFOLGREICH).
Unterbrechungs- Status: Wird beim Eintritt gelöscht und nicht wieder eingeschaltet.

OS/2 IndicationOff

Beschreibung - Mit dieser Routine werden die Anzeigen ausgeschaltet. Der Adapter bearbeitet den Anzeigezähler und das Ausschalten der Anzeigen. Mit dieser Routine wird einfach an das IndicationOff-Verzeichnis der Adapter-Steuereinheit geschrieben.
Segment: IndicationsSeg
Eingaben: SS : SP + 6 - Unser Datensegment-Wert
SegmentSelector -Enthält den RAM-Segment-Selektor des Adapters.
Ausgaben: AX enthält einen NDIS Rücklaufcode. (immer ERFOLGREICH)
Status: Wird beim Eintritt gelöscht und nicht wieder eingeschaltet.

OS/2 286 NoDevHlp ISREntry

Beschreibung - Diese Routine enthält den Unterbrechungs-Eintrittspunkt für die Adapter-Unterbrechung. Der Code in dieser Routine wurde speziell für die OS/2 Umgebung optimiert, wenn DevHelp Aufrufe vermieden werden sollten. Der ISREntry Code bearbeitet die "Haushaltspflichten", die verrichtet werden müssen, bevor die Anzeige(n), welche die Unterbrechung verursacht hat (haben), verarbeitet werden können. Mit dieser Routinen wird zuerst geprüft, ob die Unterbrechung durch unseren Adapter verursacht wurde oder ob wir mit einer anderen Unterbrechungs-Service-Routine verketten müssen. Alle Adapter-Unterbrechungen werden ausgeschaltet und System-Unterbrechungen wieder eingeschaltet.
Diese Routine enthält ebenfalls den Code zur Bearbeitung einer empfangenen Paketanzeige. Da es sich bei dieser Anzeige um die gebräuchlichste Type der Anzeige handelt, wird sie als "Fall-Through" Code behandelt. Die übrigen Anzeigen werden durch Springen durch eine Sendetabelle behandelt. Wenn die Anzeige durch ein empfangenes Paket verursacht wurde, wird RcvFrameStatus abgefragt, um zu überprüfen, ob das Paket vollständig empfangen wurde.
Daraufhin wird das Verzeichnis LengthLeftThresh, falls erforderlich, geändert und ReceiveLookAhead aufgerufen. Das LookAhead Fenster wird daraufhin erweitert. Eine Sendetabelle wird benutzt, um zur nächsten Anzeige zu springen, die verarbeitet werden muß. Falls keine weiteren Anzeigen mehr verarbeitet werden müssen, springt die Sendetabelle zu dem Code, der von der Unterbrechungs- Service-Routine herausspringt.
Segment: ISREntrySeg
Eingaben: DS ist auf den Datensegment-Selektor des Treibers eingestellt.
Ausgaben: DS wird auf den RAM Segment-Selektor des Adapters eingestellt.
Unterbrechungs- Status: Beim Eintritt ausgeschaltet und beim Verlassen eingeschaltet.

OS/2 386 NoDevHlp ISREntry

Beschreibung - Diese Routine enthält den Unterbrechungs-Eintrittspunkt für die SlapStick Adapter-Unterbrechung. Der Code in dieser Routine wurde speziell für die OS/2 80386/80486 Umgebung optimiert, wenn devHelp Aufrufe vermieden werden sollten. Der ISREntry Code verarbeitet die "Haushaltspflichten", die verrichtet werden müssen, bevor die Anzeige(n), welche die Unterbrechung verursacht haben, verarbeitet werden kann (können). Mit dieser Routine wird zuerst geprüft, ob die Unterbrechung durch unseren Adapter verursacht wurde, oder ob wir mit einer anderen Unterbrechungs-Service-Routine verknüpfen müssen. Alle Adapter-Unterbrechungen werden ausgeschaltet und die System-Unterbrechungen werden wieder eingeschaltet.
Diese Routine enthält ebenfalls den Code zur Bearbeitung einer empfangenen Paketanzeige. Da es sich bei dieser Anzeige um die gebräuchlichste Type von Anzeigen handelt, wird sie als "Fall-Through" Code behandelt. Die übrigen Anzeigen werden durch Springen durch eine Sendetabelle bearbeitet. Falls die Anzeige durch ein empfangenes Paket verursacht wurde, wird der RcvFrameStatus abgefragt, um zu überprüfen, ob das Paket vollständig empfangen wurde. Das Verzeichnis LengthLeftThres wird, falls erforderlich, geändert und ReceiveLookAhead wird aufgerufen. Anschließend wird das Fenster LookAhead erweitert.
Eine Sendetabelle wird benutzt, um zur nächsten Anzeige zu springen, die verarbeitet werden muß. Falls keine weiteren Anzeigen mehr verarbeitet werden müssen, springt die Sendetabelle zu dem Code, der von der Unterbrechungs- Service-Routine herausspringt.
Segment: ISREntrySeg
Eingaben: DS wird auf den Datensegment-Selektor des Treibers eingestellt.
Ausgaben: Es wird auf den RAM Segment-Selektor des Adapters eingestellt.
Unterbrechungs- Status: Beim Eintritt ausgeschaltet und beim Verlassen eingeschaltet.

OS/2 286 DevHID ISREntrv

Beschreibung - Diese Routine enthält den Unterbrechungs-Eintrittspunkt für die Adapter-Unterbrechung. Der Code in dieser Routine wurde speziell für die OS/2 80286 Umgebung optimiert, wenn devHelp Aufrufe immer aufgerufen werden sollten. Der ISREntry Code erledigt "Haushaltspflichten", die verrichtet werden müssen, bevor die Anzeige(n), welche die Unterbrechung verursacht haben, verarbeitet werden können. Mit dieser Routinen wird zuerst geprüft, ob die Unterbrechung durch unseren Adapter verursacht wurde oder ob wir mit einer anderen Unterbrechungs-Service-Routine verketten müssen. Alle Adapter- Unterbrechungen werden ausgeschaltet und System-Unterbrechungen wieder eingeschaltet.
Diese Routine enthält ebenfalls den Code zur Bearbeitung einer empfangenen Paketanzeige. Da es sich bei dieser Anzeige um die gebräuchlichste Type von Anzeigen handelt, wird sie als "Fall-Through" Code behandelt. Die übrigen Anzeigen werden durch Springen durch eine Sendetabelle bearbeitet. Falls die Anzeige durch ein empfangenes Paket verursacht wurde, wird der RcvFrameStatus abgefragt, um zu überprüfen, ob das Paket vollständig empfangen wurde. Daraufhin wird das Verzeichnis LengthLeftThresh, falls erforderlich, geändert und ReceiveLookAhead wird aufgerufen. Anschließend wird das Fenster LookAhead erweitert.
Eine Sendetabelle wird benutzt, um zur nächsten Anzeige zu springen, die verarbeitet werden muß. Falls keine weiteren Anzeigen mehr verarbeitet werden müssen, springt die Sendetabelle zu dem Code, der von der Unterbrechungs- Service-Routine herausspringt.
Segment: ISREntrySeg
Eingaben: DS wird auf den Datensegment-Selektor des Treibers eingestellt.
Ausgaben: Es wird auf den RAM Segment-Selektor des Adapters eingestellt.
Unterbrechungs- Status: Beim Eintritt ausgeschaltet und beim Verlassen eingeschaltet.

OS/2 386 DevHlp ISREntry

Beschreibung - Diese Routine enthält den Unterbrechungs-Eintrittspunkt für die SlapStick Adapter-Unterbrechung. Der Code in dieser Routine wurde speziell für die OS/2 80386 Umgebung optimiert, wenn devHelp Aufrufe immer aufgerufen werden sollten. Der ISREntry Code erledigt "Haushaltspflichten", die verrichtet werden müssen, bevor die Anzeige(n), welche die Unterbrechung verursacht haben, verarbeitet werden können. Mit dieser Routinen wird zuerst geprüft, ob die Unterbrechung durch unseren Adapter verursacht wurde oder ob wir mit einer anderen Unterbrechungs-Service-Routine verketten müssen. Alle Adapter- Unterbrechungen werden ausgeschaltet und die System-Unterbrechung wieder eingeschaltet.
Diese Routine enthält ebenfalls den Code zur Bearbeitung einer empfangenen Paketanzeige. Da es sich bei dieser Anzeige um die gebräuchlichste Type von Anzeigen handelt, wird sie als "Fall-Through" Code behandelt. Die übrigen Anzeigen werden durch Springen durch eine Sendetabelle bearbeitet. Falls die Anzeige durch ein empfangenes Paket verursacht wurde, wird der RcvFrameStatus abgefragt, um zu überprüfen, ob das Paket vollständig empfangen wurde. Daraufhin wird das Verzeichnis LengthLeftThresh, falls erforderlich, geändert und ReceiveLookAhead wird aufgerufen. Anschließend wird das Fenster Slapstick LookAhead erweitert.
Eine Sendetabelle wird benutzt, um zur nächsten Anzeige zu springen, die verarbeitet werden muß. Falls keine weiteren Anzeigen mehr verarbeitet werden müssen, springt die Sendetabelle zu dem Code, der von der Unterbrechungs- Service-Routine herausspringt.
Segment: ISREntrySeg
Eingaben: DS wird auf den Datensegment-Selektor des Treibers eingestellt.
Ausgaben: Es wird auf den RAM Segment-Selektor des Adapters eingestellt.
Unterbrechungs- Status: Beim Eintritt ausgeschaltet und beim Verlassen eingeschaltet.

OS/2 286 XmitComplete

Beschreibung - Diese Routine wird durch die PrimaryIntDispatch oder SecondaryIntDispatch Tabelle aufgerufen, wenn eine XmitComplete Anzeige auftritt. Diese Coee wird speziell für die OS/2 80286 Umgebung optimiert. Durch diese Routine wird das XmitCompleteThresh Verzeichnis, falls erforderlich, eingerichtet und das Verfahren Übertragung bestätigen [transmit confirm] des Protokolls aufgerufen.
Eine Sendetabelle wird benutzt, um zur nächsten Anzeige zu springen, die verarbeitet werden muß. Falls keine weiteren Anzeigen verarbeitet werden müssen, springt die Sendetabelle zu dem Code, der von der Unterbrechungs-Service- Routine herausspringt.
Segment: XmitCompleteSeg
Eingaben: Es wird auf den RAM-Segment-Selektor des Treibers eingestellt.
Ausgaben: Keine
Unterbrechungs- Status: Beim Eintritt unbekannt und unverändert.

OS/2 386 XmitComDlete

Beschreibung - Diese Routine wird durch die PrimaryIntDispatch oder SecondaryIntDispatch Tabelle aufgerufen, wenn eine XmitComplete Anzeige auftritt. Diese Code wird speziell für die OS/2 80386/80486 Umgebung optimiert. Durch diese Routine wird das XmitCompleteThresh Verzeichnis, falls erforderlich, eingerichtet und das Verfahren Übertragung bestätigen [transmit confirm] des Protokolls aufgerufen.
Eine Sendetabelle wird benutzt, um zur nächsten Anzeige zu springen, die verarbeitet werden muß. Falls keine weiteren Anzeigen verarbeitet werden müssen, springt die Sendetabelle zu dem Code, der von der Unterbrechungs-Service- Routine herausspringt.
Segment: XmitCompleteSeg
Eingaben: Es wird auf den RAM-Segment-Selektor des Adapters eingestellt.
Ausgaben: Keine
Unterbrechungs- Status: Beim Eintritt unbekannt und unverändert.

OS/2 286 ISRExit

Beschreibung - Auf diese Routine wird durch die PrimaryIntDispatch oder SecondaryIntDispatch Tabelle verzweigt. Diese Routine wird für die OS/E 80286 Umgebung optimiert. Der Zweck dieser Routine besteht darin, Anzeige komplett [indication complete], falls erforderlich, aufzurufen und vom Unterbrechungs- Kontext zurückzukehren.
Segment: ISRExitSeg
Eingaben: Es enthält den RAM-Segment-Selektor des Adapters.
Ausgaben: Keine.
Unterbrechungs- Status: Beim Eintritt gelöscht, eingeschaltet, wenn IndicationComplete aufgerufen wird, eingeschaltet, wenn der IRET-Befehl ausgeführt wird.

OS/2 386 ISRExit

Beschreibung - Auf diese Routine wird über die PrimaryIntDispatch oder die SecondaryIntDispatch Tabelle verzweigt. Diese Routine wurde für die OS/2 80386/80486 Umgebung optimiert. Der Zweck dieser Routine besteht darin, Anzeige komplett [Anzeige komplett] aufzurufen und vom Unterbrechungs-Kontext zurückzukehren.
Segment: ISRExitSeg
Eingaben: Es enthält den RAM-Segment-Selektor des Adapters.
Ausgaben: Keine.
Unterbrechungs- Status: Beim Eintritt gelöscht, eingeschaltet, wenn IndicationComplete aufgerufen wird, eingeschaltet, wenn der IRE-Befehl ausgeführt wird.

OS/2 OtherIndication

Beschreibung - Diese Routine wird von den anderen Steuerprogrammen über PrimaryIntDispatch oder die SecondaryIntDispatch Tabelle aufgerufen. Der Zweck dieser Routine ist die Verarbeitung einer OtherIndication Anzeige (Bit 5 im IndicationComplete Verzeichnis). Die OtherIndication Anzeige kann durch eines von drei Ereignissen verursacht werden. Erstens wird diese Anzeige erzeugt, wenn das Protokoll angefordert hat, daß eine Unterbrechung erzeugt wird. Durch diese Routine wird die Unterbrechungs- Status-Anzeige des Protokolls erzeugt.
Zweitens wird diese Anzeige erzeugt, wenn das Protokoll angefordert hat, daß der MAC-Treiber zurückgestellt wird. Mit dieser Routine werden die StartReset und EndReset Status-Anzeigen aufgerufen und die tatsächliche Rückstellung des Adapters und des MAC-Treibers durchgeführt.
Der dritte Grund, aus dem diese Anzeige erzeugt werden kann, ist der, wenn im Sender ein DMA-Zeitunterschreitungsfehler auftritt. Dies wird dann verursacht, wenn der Adapter ein Paket im Netzwerk schneller überträgt, als der als der Bus- Hauptrechner das Paket auf den Adapter laden kann. In diesem Falle wird das XmitStartThresh Verzeichnis erweitert, damit mehr Daten im Adapter speicherresident sein können, bevor die Übertragung beginnt.
Segment: SupportCodeSeg
Eingaben: Es enthält den RAM-Segment-Selektor des Adapters.
Ausgaben: Keine.
Unterbrechungs- Status: Beim Eintritt unbekannt und kann eingeschaltet werden.

SCHLUSSFOLGERUNG

Zusammenfassend, wird ein in sich geschlossenes, ausführbares Modul eines Betriebssystems, das normalerweise in einem Großspeicher zur Benutzung für irgendeine einer Vielfältigkeit von ändernden Wirts-Architekturen bereitgestellt, das zuerst in Benutzer-Speicherraum der Zentraleinheit geladen wird und dann zur Optimierung des Moduls von irgendeiner einer Vielfältigkeit von ändernden Wirts- Architekturen ausgeführt wird. Es schließt ein: Abfühlen der Art der benutzten Zentraleinheit, Verschieben eines Teils der geladenen, ausführbaren Datei in ein optimiertes Segment von benutzerzugänglichem Speicherraum, was das Überschreiben anderer Teile des Speicherraums, der durch das Modul selbst belegt wird, Umleitung aller Unterbrechungsanzeiger gemäß der benutzten CPU-Type und des verschobenen Codeblocks und Ablegen aller überschüssigen Segmente des ausführbaren Codes im geladenen Modul, um den Speicher zur Benutzung durch andere Anwendungsprogramme und/oder Betriebssystem-Module freizugeben.
Die Erfindung kann entweder in der Form einer ausführbaren Datei implementiert werden oder kann in der Form eines Gerätetreibers implementiert werden. Das verschobene Segment des ausführbaren Code-Moduls kann Speicherstellen oder andere Teile desselben ausführbaren Codes überschreiben oder als Alternative kann das Segment des Codes in einen geschützten Speicherraum verschoben werden, wie im Zusammenhang mit der Zentraleinheit und/oder des Betriebssystems definiert, um eine maximale Menge von benutzerzugänglichem Speicherraum für andere Programme freizugeben.
Deshalb wird das Ziel der Bereitstellung des schnellstmöglichen Software- Moduls in so wenig Speicherraum wie möglich, in der vorliegenden Erfindung erzielt. Die Erfindung ist besonders in Systemen wie Gerätetreiber für Netzwerk- Schnittstellen nützlich, die im Wirtsspeicher während der gesamten Verarbeitung, die das Netzwerk einschließt, speicherresident bleiben müssen. Diese Systeme belegen einen Teil eines Wirtsspeichers und begrenzen die Benutzung des Wirtsspeichers für andere Anwendungen. Es ist erforderlich, daß ein derartiger Code für Geschwindigkeit und Raum optimiert wird, wie durch die vorliegende Erfindung gezeigt.
Die vorstehende Beschreibung der bevorzugten Ausführungen der vorliegenden Erfindung wurde zum Zwecke der Veranschaulichung und Beschreibung bereitgestellt. Es wird nicht beabsichtigt, daß diese erschöpfend ist oder die Erfindung auf die genau offengelegten Formen zu beschränken. Es ist offensichtlich, daß sich für Praktiker, die in dieser Technik bewandert sind, viele Änderungen und Variationen zeigen werden. Die Ausführungen wurden gewählt und beschrieben, um die Grundsätze der Erfindung und ihre praktische Anwendung am besten zu erklären, wodurch anderen, die in dieser Technik bewandert sind, ermöglicht wird, die Erfindung für verschiedene Ausführungen und mit verschiedenen Änderungen wie sie für die besondere vorgesehene Benutzung geeignet sind, zu verstehen. Es wird beabsichtigt, daß der Umfang der Erfindung durch die nachstehenden Ansprüche definiert wird.

Claims

1. Ein Verfahren zur Initialisierung in einem Wirts-Datenverarbeitungssystem (12), wobei der Wirt irgendeine einer Vielfältigkeit von ändernden Architekturen besitzt, bestehend aus:

Laden eines Software-Moduls in den Wirtsspeicher (28), einschließlich eines Satzes von Codeblocks (16, 18, 20,22), wobei jeder Codeblock mindestens einer der Vielfältigkeit von ändernden Architekturen angepaßt ist;

Identifizierung der ändernden Architektur des Wirts;

Wahl eines Untersatzes aus dem Satz von Codeblocks, die für die identifizierte ändernde Architektur angepaßt wurden;

Lokalisierung des Untersatzes innerhalb des Wirtsspeichers (28) in benachbarten Speicherstellen; und

Freigabe von Speicherstellen im Software-Modul im Wirtsspeicher (28) außerhalb der benachbarten Speicherstellen.

2. Das Verfahren von Anspruch 1, wobei mindestens eine aus der Vielfältigkeit von ändernden Architekturen eine Konfigurationstabelle einschließt, in der die Variablen gespeichert werden, die die Attribute der Wirtsarchitektur identifizieren, wobei der Schritt der Identifizierung folgendes einschließt: Analyse (74) der Konfigurationstabelle.

3. Das Verfahren von Anspruch 1, wobei der Schritt der Identifizierung folgendes einschließt: Ausführung von Prüfungen zur Bestimmung der Merkmale der Wirtsarchitektur.

4. Das Verfahren von Anspruch 1, wobei die Wirtsarchitektur einen begrenzten Adressenraum und der Untersatz des Software-Moduls während dem Ablauf anderer Software Wirtsspeicher (28) belegt.

5. Ein Verfahren gemäß Anspruch 1, bei dem die genannte Software Betriebssystem-Software zur Steuerung eines Zusatzgerätes (56) betreibt und es sich bei dem genannten Software-Modul um ein Initialisierungsmodul handelt, in dem die Codeblocks Betriebssystem-Codeblocks für das Zusatzgerät sind.

6. Das Verfahren von Anspruch 5, wobei die Wirtsarchitektur einen begrenzten Adressenraum und den Untersatz von Codeblocks für das Zusatzgerät während dem Ablauf von Anwendungs-Software Wirtsspeicher belegt.

7. Das Verfahren von Anspruch 1 oder 5, wobei der Satz von Codeblocks im Software-Modul aus einer Vielfältigkeit von Funktions-Segmenten besteht, wobei jedes Funktions-Segment in der Vielfältigkeit mindestens einen Codeblock einschließt und der Schritt zur Wahl eines Untersatzes schließt ein: Wahl eines Codeblocks aus jedem Funktionssegment in der Vielfältigkeit von Funktionssegmenten.

8. Das Verfahren von Anspruch 1 oder 5, wobei das Software-Modul außerdem Tabellen zur Identifizierung von Speicherstellen von Codeblocks und speicherstellenabhängige Eintritte innerhalb der Codeblocks, die auf der identifizierten ändernden Architektur basieren, einschließt; und der Schritt zur Wahl schließt ein:

Zugriff auf die Tabellen als Antwort auf die identifizierte ändernde Architektur zur Identifizierung der gewählten Codeblocks; und

der Schritt der Lokalisierung schließt den Zugriff auf gewählte Codeblocks und die Aktualisierung der speicherstellenabhängigen Eintritte in ausgewählten Codeblocks ein.

9 Ein Verfahren gemäß Anspruch 1, bei dem die genannte Software Betriebssystem-Software zur Steuerung eines Zusatzgerätes (56) betreibt und der Wirt begrenzten Wirtsspeicher besitzt, wobei:

es sich bei dem genannten Software-Modul um ein Initialisierungs-Modul handelt, in dem der genannte Satz von Codeblocks aus einer Vielfältigkeit von Funktionssegmenten besteht, wobei jedes Funktionssegment in der Vielfältigkeit mindestens einen Codeblock für das Zusatzgerät (56) einschließt, wobei das Initialisierungs-Modul außerdem eine Umfeld-Variable und Tabellen zur Identifizierung eines Codeblocks in jedem Funktionssegment als Antwort auf die Umfeld-Variable einschließt;

der genannte Schritt zur Identifizierung der ändernden Architektur des Wirts außerdem die Aktualisierung der Umfeld-Variablen zur Anzeige der identifizierten ändernden Architektur einschließt; und

der genannte Schritt des Wählens aus dem Zugriff auf die Tabellen als Antwort auf die aktualisierte Umfeld-Variable zur Wahl eines Codeblocks, der an die angegebene ändernde Architektur angepaßt wird, von jedem der Vielfältigkeit von Funktionssegmenten besteht.

10. Das Verfahren von Anspruch 9, wobei die Tabellen im Initialisierungs-Modul speicherstellenabhängige Eintritte innerhalb des gewählten Codeblocks identifizieren; und der Schritt des Lokalisierung schließt ein: Zugriff auf die gewählten Codeblocks und Aktualisierung der speicherstellenabhängigen Eingaben in den Codeblocks.

11. Das Verfahren von Anspruch 1, 5 oder 9, wobei der Schritt des Ladens die Speicherung des Software-Moduls in einer Speicherstelle einschließt, die an einer ersten Adresse beginnt und an einer zweiten Adresse endet; und die benachbarten Speicherstellen an der ersten Adresse beginnen und an der dritten Adresse enden; und

der Schritt der Freigabe schließt die Freigabe von Speicherstellen zwischen der dritten und zweiten Adresse ein.

12. Das Verfahren von Anspruch 5 oder 9, wobei mindestens eine der Vielfältigkeit von ändernden Architekturen eine Konfigurationstabelle einschließt, Variable speichert, die Attribute der Wirtsarchitektur identifiziert und das Initialisierungs-Modul schließt einen Architektur-Variable ein und der Schritt der Identifizierung schließt ein:

Analyse der Konfigurationstabelle; und

Aktualisierung der Architektur-Variablen als Antwort auf Eingaben in die Konfigurationstabelle.

13. Das Verfahren von Anspruch 5 oder 9, wobei das Initialisierungs-Modul eine Umgebungs-Variable einschließt und der Schritt der Identifizierung schließt ein: Ausführung von Prüfungen zur Bestimmung der Merkmale der Wirtsarchitektur; und

Aktualisierung der Umgebungs-Variablen als Antwort auf die Ergebnisse der Prüfungen.

14. Das Verfahren von Anspruch 5 oder 9, wobei das Zusatzgerät aus einer Netzwerk-Schnittstelle besteht und die Betriebssystem-Software für die Netzwerk- Schnittstelle einen Code zur Übermittlung und zum Empfang von Daten durch die Netzwerk-Schnittstelle einschließt.

15. Ein Verfahren zur automatischen Optimierung der Verwendung einer Mikroprozessor-Einheit (30) in einem Computersystem (12), das ebenfalls aus einem benutzerzugänglichen Speicher (28) besteht, wobei die genannte Methode aus folgenden Schritten besteht:

Laden einer ausführbaren Version eines Computer- Betriebssystemprogramms in den Speicher (28), wobei die ausführbare Version ausführbare Codes zur einmaligen Identifizierung jeder einzelnen der Vielfältigkeit von Mikroprozessoreinheiten (30) besitzt;

Ausführung des genannten Betriebssystem-Programms zum Abfühlen der Mikroprozessor-Einheit, die im genannten Computersystem in Betrieb ist, zur Retournierung eines Kennzeichen-Signals (32), mit dem die Mikroprozessor-Type identifiziert wird;

Freigabe von Speicherstellen von genanntem Speicher (28), der die ersten Teile des genannten Betriebssystem-Programms enthält, die von der genannten Mikroprozessor-Type (30) nicht benötigt werden, gemäß dem genannten Kennzeichen-Signal (32); und

Verschieben zweiter Teile des genannten Betriebssystem-Programms innerhalb genanntem Speicher (28) zur Verbesserung der Verwendung des Speicherraums, die auf den Entscheidungen des genannten Kennzeichen-Signals basieren.

16. Das Verfahren gemäß Anspruch 15, wobei der genannte Schritt des Verschiebens das Verschieben der genannten zweiten Teile über und an die Stelle der genannten ersten Teile einschließt.

17. Das Verfahren gemäß Anspruch 16, wobei der genannte Schritt des Verschiebens der genannten Vektors den Betrieb mit den zweiten Teilen, wie verschoben, einschließt.

18. Das Verfahren gemäß Anspruch 15, wobei der genannte Schritt des Verschiebens die Rückstellung der Vektors zum Betrieb mit den zweiten Teilen, wie verschoben, einschließt.

19. Die Methode gemäß Anspruch 15, wobei der genannte Schritt des Verschiebens das Verschieben der genannten Codesegmente außerhalb des benutzerzugänglichen Speichers (28) der Mikroprozessor-Einheit (30) und die Rückstellung des Vektors und Unterbrechungen zum Betrieb mit den benötigten zweiten Teilen des genannten Betriebssystemprogramm-Moduls wie verschoben, einschließt.

20. Das Verfahren gemäß Anspruch 15, wobei das genannte Betriebssystem- Programm als Gerätetreiber geladen wird.