-
Die Erfindung betrifft ein Verfahren zur Implementierung virtueller Adressräume auf einem eingebetteten System.
-
Eingebettete Systeme sind heutzutage nicht mehr aus der Industrie, insbesondere der Prozessanalyse, wegzudenken. Gerade in der Prozessanalyse finden eingebettete Systeme eine immer größer werdende Anwendung. Ein eingebettetes System ist in der Regel auf einen bestimmten technischen Kontext, in welchem es eine bestimmte Aufgabe, meist eine Regelung oder Steuerung, übernimmt, zugeschnitten. Durch diese individuelle Konzeption arbeiten eingebettete Systeme besonders optimiert und sicher. Somit werden eingebettete Systeme den immer höheren Ansprüchen bezüglich Effizienz und Fehlerfreiheit in der Prozessanalyse gerecht.
-
Eingebettete Systeme, welche auf eine spezielle Aufgabe zugeschnitten sind, besitzen jedoch häufig eine statische Firmware, deren Komponenten in einem einzigen Adressraum laufen. Software-Fehler in einer Komponente, wie z.B. Speicherüberschreiber können sich dadurch auch auf die restlichen Komponenten auswirken, indem z.B. Daten korrumpiert werden bzw. das Gesamtsystem zum Absturz gebracht wird. Sollte es außerdem im Laufe des Betriebslebens des eingebetteten Systems zu einer Änderung der Aufgabe des eingebetteten Systems kommen, erschwert eine statische, innerhalb eines Adressraums laufende Firmware ein nachträgliches Einbringen von neuer Funktionalität.
-
Virtuelle Adressräume eignen sich besonders gut, einem eingebetteten System in seiner Funktionalität mehr Flexibilität zu verleihen und Fehler in den einzelnen Komponenten voneinander zu isolieren. Durch die Implementierung virtueller Adressräume in einem eingebetteten System können zum Beispiel verschiedene Programme gleichzeitig ausgeführt werden. Jedes Programm wird hierbei isoliert von anderen Programmen ausgeführt, so dass ein Programm nicht ein zweites Programm manipulieren kann, oder auf einen Speicherbereich des zweiten Programms zugreifen kann. Ein weiterer Vorteil von virtuellen Adressräumen ist, dass Code und Daten des ausgeführten Programms fragmentiert in einem physischen Hauptspeicher des eingebetteten Systems gespeichert sind, jedoch unfragmentiert in den virtuellen Adressraum eingeblendet werden können. Dies erleichtert ein nachträgliches Nachladen von Funktionalität. Da jedes Programm seinen eigenen linearen Adressraum besitzt, muss ein Programm zu seinem Erstellzeitpunkt und zur Laufzeit nichts über seine Platzierung innerhalb des physischen Hauptspeichers des konkreten eingebetteten Systems wissen, auf dem das Programm ausgeführt wird.
-
Um einen virtuellen Adressraum in einem eingebetteten System zu implementieren, wird eine Abbildungsvorschrift benötigt, die angibt, wie eine virtuelle Adresse im virtuellen Adressraum auf eine physische Adresse im physischen Hauptspeicher des eingebetteten Systems abgebildet wird. Greift ein Programm auf eine virtuelle Adresse zu, dann muss diese in eine physische Adresse umgerechnet werden. Diese Umrechnung wird gewöhnlich durch eine spezielle Hardware, die sogenannte Memory-Management-Unit, auch MMU genannt, welche im Hauptprozessor des eingebetteten Systems angesiedelt ist, ausgeführt. Für diese Umrechnung benötigt die MMU ein hohes Niveau an Energie- und/oder Rechen-Ressourcen, verglichen zu den restlichen Komponenten des eingebetteten Systems.
-
Es gibt eingebettete Systeme, die mit stark limitierten Ressourcen arbeiten, beispielsweise um Herstellkosten einzusparen oder weil nur ein begrenztes Energiebudget zur Verfügung steht. Da eine MMU eine komplexe Hardware-Einheit ist, besitzen eingebettete Systeme mit stark limitierten Ressourcen häufig keine MMU. Daher wird darauf verzichtet, bei solchen Anwendungsgebieten virtuelle Adressräume zu implementieren.
-
Es ist daher eine Aufgabe der Erfindung, ein Verfahren zur ressourcenschonenden Implementierung virtueller Adressräume auf einem eingebetteten System vorzuschlagen, welches ohne Hardware-Unterstützung zur Adressumrechnung auskommt.
-
Diese Aufgabe wird erfindungsgemäß gelöst durch ein Verfahren gemäß Anspruch 1.
-
Das erfindungsgemäße Verfahren zum Implementieren eines virtuellen Adressraumes umfasst die folgenden Schritte:
- - Bereitstellen eines eingebetteten Systems mit einem physischen Speicher, einem Lader und einer Ausführungseinheit, wobei der physische Speicher einen physischen Adressraum definiert,
- - Bereitstellen eines Programms, wobei das Programm von dem eingebetteten System ausführbar ist, mindestens einen Programmbereich mit jeweils einer Zugriffseigenschaft aufweist und ein vorbestimmtes Speicherlayout für den virtuellen Adressraum aufweist, wobei der mindestens eine Programmbereich einer virtuellen Adresse im virtuellen Adressraum zugewiesen ist und eine Programmgröße aufweist,
- - Erstellen des virtuellen Adressraums im eingebetteten System, welcher mindestens zwei Segmente mit jeweils einer gleichen Segmentgröße und jeweils einer separaten virtuellen Anfangsadresse umfasst, davon ein erstes Segment und ein zweites Segment, durch den Lader,
- - Erstellen einer Umrechnungstabelle im eingebetteten System für das Programm, zum Umrechnen einer virtuellen Adresse des mindestens einen Programmbereichs in eine physische Adresse in dem physischen Speicher, durch den Lader,
- - Umrechnen eines Speicherzugriffs auf die virtuelle Adresse in die physische Adresse unter Benutzung der Umrechnungstabelle, durch die Ausführungseinheit oder das Programm.
-
Anhand des erfindungsgemäßen Verfahren wird ermöglicht, virtuelle Adressräume selbst bei eingebetteten Systemen mit limitierten Ressourcen zu implementieren.
-
Ein Vorteil des erfindungsgemäßen Verfahrens ist, dass das Verfahren durch Einschränkungen des Aufbaus des virtuellen Adressraums sowie durch die gewählte Datenstruktur zur Umrechnung von virtuellen Adressen in physische Adressen effizient in Software implementierbar ist. Das Verfahren ist so konzipiert, dass eine Umrechnung einer virtuellen Adresse in eine physische Adresse mit konstantem Aufwand und einer geringen Zahl von Instruktionen durchführbar ist. Somit wird keine MMU nötig.
-
Gemäß einer Ausführungsform der Erfindung ist das Speicherlayout so aufgebaut, dass Programmbereiche mit unterschiedlichen Zugriffseigenschaften in unterschiedliche Segmente geschrieben werden, dass ein Segment immer von seiner virtuellen Anfangsadresse aus befüllt wird, dass das erste Segment niemals auf den physischen Adressraum abgebildet wird, dass sich der mindestens eine Programmbereich über mehrere Segmente erstrecken darf, wenn die Programmgröße die Segmentgröße übersteigt und gleichzeitig Programmbereiche mit unterschiedlichen Zugriffseigenschaften in unterschiedliche Segmente geschrieben werden sowie ein Segment von seiner virtuellen Anfangsadresse aus befüllt wird.
-
Gemäß einer weiteren Ausführungsform der Erfindung ist der virtuelle Adressraum in eine Anzahl an Segmenten unterteilt, wobei die Anzahl eine Zweierpotenz ist.
-
Die oben genannte Aufgabe wird auch erfindungsgemäß gelöst durch ein Verfahren gemäß Anspruch 4.
-
Das erfindungsgemäße Verfahren zum Generieren eines Programms für ein eingebettetes System, wobei das Programm auf einem Quellcode und einer Speicherkonfiguration basiert, so dass das Programm ein vorbestimmtes Speicherlayout aufweist. Das Programm ist von dem eingebetteten System ausführbar und weist mindestens einen Programmbereich auf. Der mindestens eine Programmbereich ist einer virtuellen Adresse im virtuellen Adressraum zugewiesen und weist eine Zugriffseigenschaft sowie eine Programmgröße auf.
-
Gemäß einer Ausführungsform der Erfindung ist das Speicherlayout so aufgebaut, dass Programmbereiche mit unterschiedlichen Zugriffseigenschaften in unterschiedliche Segmente geschrieben werden, dass ein Segment immer von seiner virtuelle Anfangsadresse aus befüllt wird, dass ein erstes Segment niemals auf den physischen Adressraum abgebildet wird, dass sich der mindestens eine Programmbereich über mehrere Segmente erstrecken darf, wenn die Programmgröße die Segmentgröße übersteigt und gleichzeitig Programmbereiche mit unterschiedlichen Zugriffseigenschaften in unterschiedliche Segmente geschrieben werden sowie ein Segment von seiner virtuelle Anfangsadresse aus befüllt wird.
-
Gemäß einer Ausführungsform der Erfindung wird der Schritt des Generierens eines Programms durch ein dem eingebetteten System externes Entwicklungssystem realisiert.
-
Gemäß einer Ausführungsform der Erfindung umfasst das Entwicklungssystem eine Werkzeugkette, welche den Schritt des Generierens des Programms ausführt, wobei die Werkzeugkette einen Compiler, einen Assembler und einen Linker umfasst.
-
Die Erfindung wird anhand der nachfolgenden Figurenbeschreibung näher erläutert. Es zeigen:
- - 1: eine schematische Darstellung des erfindungsgemäßen Verfahrens zum Implementieren eines virtuellen Adressraumes in einem eingebetteten System,
- - 2: ein Beispiel eines Quellcodes für ein ausführbares Programm,
- - 3: ein aus dem in 2 dargestellten Quellcode generiertes ausführbares Programm,
- - 4: eine beispielhafte Unterteilung des virtuellen Adressraums in Segmente,
- - 5: eine beispielhafte Konfiguration eines Speicherlayouts des ausführbaren Programms aus 3,
- - 6: eine beispielhafte Ausführungsform einer Umrechnungstabelle,
- - 7: ein Beispiel einer erfolgreichen Umrechnung einer virtuellen Adresse in eine physische Adresse,
- - 8: ein Beispiel einer fehlerhaften Umrechnung einer virtuellen Adresse in eine physische Adresse und
- - 9: ein weiteres Beispiel einer fehlerhaften Umrechnung einer virtuellen Adresse in eine physische Adresse.
-
1 zeigt eine schematische Darstellung des erfindungsgemäßen Verfahrens zum Implementieren eines virtuellen Adressraumes V in einem eingebetteten System 10.
-
Der Gesamtaufbau des Verfahrens, das eine effiziente Implementierung von virtuellen Adressräumen V umsetzt, besteht, wie in 1 durch die gestrichelten Linien dargestellt, aus zwei Systemen: das eingebettete System 10 und ein Entwicklungssystem 100.
-
Das Entwicklungssystem 100 erstellt ein Programm P, welches dazu geeignet ist, auf dem eingebetteten System 10 ausführt zu werden. Das eingebettete System 10 ist dazu eingerichtet, das vom Entwicklungssystem 100 erstellte Programm P zu empfangen, was durch den Pfeil zwischen den Systemen dargestellt ist. Das Programm P kann zum Beispiel durch eine USB-Schnittstelle oder eine Funk-Schnittstelle des eingebetteten Systems 10 an dieses übertragen werden (nicht dargestellt).
-
Auf dem Entwicklungssystem 100 wird ein Quellcode Q mittels einer Werkzeugkette W in ein ausführbares Programm P übersetzt. Die Werkzeugkette W umfasst zum Beispiel einen Compiler, einen Assembler und einen Linker. Zusätzlich zum Quellcode Q erhält die Werkzeugkette W eine Speicherkonfiguration K als Eingabe (z.B. in Form eines Linker-Scripts).
-
Die Speicherkonfiguration K beschreibt, dass das Speicherlayout L des Programms P vorbestimmten Regeln entsprechen muss, welche eine effiziente Adressumrechnung von einer virtuellen Adresse V0 zu einer physischen Adresse H0 auf dem eingebetteten System 10 ermöglichen. Diese vorbestimmten Regeln werden weiter unten genauer erläutert.
-
Das Programm P umfasst mindestens einen Programmbereich B, zum Beispiel einen ersten Programmbereich B1, welcher dem ausführbaren Code C entspricht und zum Beispiel ein zweiter Programmbereich B2, welcher den Daten D entspricht. Jeder Programmbereich B enthält eine Beschreibung eines Speicherlayouts L. Das Programm P weist eine Programmgröße G1 auf. Das Speicherlayout L enthält eine Information darüber, wo im virtuellen Adressraum V der Code C des Programms P und die Daten D des Programms P gespeichert sein sollen. Die Daten D sind beispielweise initialisierte oder uninitialisierte globale Variablen des Programms P.
-
2 zeigt ein Beispiel eines Quellcodes Q für ein ausführbares Programm P. 3 zeigt ein aus dem in 2 dargestellten Quellcode Q generiertes ausführbares Programm P.
-
Das in 3 dargestellte Programm P gibt für das Speicherlayout L an, dass der Code C des Programms P 0xb94 Bytes groß (Feld „memsz“ der ersten Zeile des Abschnitts „Program Header“) ist, an eine erste virtuelle Adresse V1 0x40000000 (Feld „vaddr“ der ersten Zeile des Abschnitts „Program Header“) geladen werden soll und nur lesbar sowie ausführbar ist, was durch die Bezeichnung „flags r-x“ dargestellt ist.
-
Der Datenbereich des durch das Programm P gespeicherten Daten D ist 0x464 Bytes groß (Feld „memsz“ der zweiten Zeile des Abschnitts „Program Header“), soll an die zweite virtuelle Adresse V2 0x80000000 (Feld „vaddr“ der zweiten Zeile des Abschnitts „Program Header“) geladen werden und soll nur lesbar und schreibbar sein, was durch die Bezeichnung „flags rw-“ dargestellt ist. Das Programm P enthält natürlich auch den ausführbaren Code C, der mit dem mit „Disassembly of section text“ eingeleiteten Bereich angedeutet ist.
-
Die Bezeichung „flags“ signalisiert, dass die nachfolgenden Bezeichnungen eine Zugriffseigenschaft Z1 kennzeichnen. Die Bezeichnung r steht für „read“, was lesbar bedeutet. Die Bezeichnung w steht für „write“, was schreibbar bedeutet. Die Bezeichnung x steht für „execute“ was ausführbar bedeutet. Zudem sei angemerkt, dass Zahlen, welche mit 0x beginnen, durch die nachfolgenden Zeichen eine Hexadezimalzahl darstellen.
-
Das eingebettete System 10 umfasst einen physischen Speicher 12, einen Lader 14 und eine Ausführungseinheit 16.
-
Auf dem eingebetteten System 10 bereitet der Lader 14 das Programm P für die Ausführung vor. Die Aufgabe des Laders 14 besteht darin, Code C und Daten D aus dem Programm P in den physischen Speicher 12 des eingebetteten Systems 10 zu kopieren. Hierbei stimmen die physischen Adressen H0 in der Regel nicht mit den virtuellen Adressen V0 des Speicherlayouts L des Programms P überein. Stattdessen erstellt der Lader 14 eine Abbildung von den virtuellen Adressen V0 auf physische Adressen H0. Der Lader muss dazu unbelegte, ausreichend große Speicherbereiche im physischen Hauptspeicher identifizieren, auf welche die virtuellen Adressen abbildbar sind. Der Aufbau dieser Abbildungs-Datenstruktur wird später noch beschrieben. Erlaubt das Speicherlayout L des Programms P keine effiziente Abbildung von virtuellen Adressen V0 auf physische Adressen H0, so bricht der Lader 14 mit einem Fehler ab.
-
Nach Abschluss des Ladevorgangs kann eine Ausführungseinheit 16 (z.B. in Form eines Interpreters) das Programm P ausführen. Speicherzugriffe auf virtuelle Adressen V0 werden mit Hilfe der erstellten Abbildung auf physische Adressen H0 umgerechnet. Handelt es sich bei der Ausführungseinheit 16 um einen Interpreter, so kann der Interpreter Speicherzugriffe entsprechend umrechnen.
-
Eine andere Alternative ist, dass die Ausführungseinheit 16 dem Hauptprozessor des eingebetteten Systems 10 entspricht, der das Programm P direkt ausführt, der Compiler der Werkzeugkette W das Programm P aber aus dem Quellcode Q so übersetzt, dass das Programm P vor jedem Speicherzugriff zunächst eine Adressumrechnung durchführt, siehe 7 bis 9.
-
Der tatsächlich durchgeführte Speicherzugriff erfolgt dann über physische Adressen H0. In 1 ist dies mittels der durchgezogenen gestrichelten Doppelpfeile zwischen Ausführungseinheit 16 und Code C an der ersten virtuellen Adresse V1 und Daten D an der zweiten virtuellen Adresse V2 im virtuellen Adressraum V und dem Code C an der ersten physischen Adresse H1 und den Daten D an der zweiten physischen Adresse H2 im physischen Adressraum H angedeutet.
-
Um eine effiziente Abbildung zu ermöglichen, wird der virtuelle Adressraum V in eine kleine Anzahl an gleich großen Segmenten S unterteilt, wobei die Anzahl eine Zweierpotenz ist. 4 zeigt ein Beispiel für einen 32-Bit virtuellen Adressraum V, der in acht Segmente S zu je 512 MB unterteilt wurde.
-
Das Speicherlayout L eines Programms P muss nun folgende Randbedingungen, bzw. Regeln erfüllen:
-
Erstens, Programmbereiche B des Programms P mit unterschiedlichem Zugriffseigenschaften Z1 müssen in unterschiedlichen Segmenten S platziert werden. Z.B. ist es nicht erlaubt, dass ein nur lesbarer Code-Bereich des Codes C und ein les- und schreibbarer Datenbereich der Daten D hintereinander in einem Segment S platziert werden.
-
Zweitens, ein Segment S muss immer von seiner virtuelle Anfangsadresse VA0 aus befüllt werden. Zum Beispiel, ein Bereich, der in einem dritten Segment S2 eines 32-Bit virtuellen Adressraums V mit acht Segmenten zu je 512 MB liegt, muss also bei Adresse 0x40000000 beginnen.
-
Drittens, ein erstes Segment S0 wird niemals auf den physischen Speicher 12 abgebildet. Somit können Null-Pointer-Zugriffe abgefangen werden.
-
Viertens, ein Programmbereich B eines Programms P darf sich auch über mehrere Segmente S erstrecken, solange die zuvor genannten drei Randbedingungen bzw. Regeln erfüllt sind.
-
Diese Randbedingungen bzw. Regeln stellen keine praktischen Einschränkungen für das Programm P innerhalb des eingesetzten eingebetteten Systems 10 dar. In einem ressourcen-beschränkten eingebetteten System 10 ist der gesamte verfügbare physische Speicher 12 wesentlich kleiner als die Größe eines Segments S, und die Anzahl der Speicherbereiche eines Programms P ist gering (Code, Daten, Stack, Heap). Ein segmentierter virtueller Adressraum V mit den oben beschriebenen Randbedingungen bietet daher immer noch genügend Platzierungsmöglichkeiten für die einzelnen Programmbereiche B, ohne in die Gefahr zu kommen, dass die Segmente S nicht ausreichen.
-
5 zeigt eine beispielhafte Konfiguration K eines Speicherlayouts L, die für den Quellcode Q des Programms P erzwingt, dass Code C und nur lesbare Daten D im dritten Segment S2 platziert werden, les- und schreibbare Daten D in einem vierten Segment S4.
-
Das in 5 dargestellte Beispiel ist ein Linker-Skript der GNU Linker-Software. Dieser Linker erlaubt es, Programmbereiche B des Programms P mit bestimmten Zugriffseigenschaften Z1 an unterschiedlichen virtuellen Adressen V0 zu platzieren, was im dargestellten Beispiel gemacht wurde.
-
6 zeigt eine Umrechnungstabelle T1 zur Abbildung von virtuellen Adressen V0 auf physische Adressen H0, die beispielhaft mit zum Programm P aus 3 passenden Adressen vom Lader14 befüllt wurde.
-
Die Umrechnungstabelle T1 hat das Ziel, die Abbildungsvorschriften von virtuellen Adressen V0 auf physische Adressen H0 so einzuschränken, dass eine effiziente Umrechnung von virtuellen Adressen V0 auf physische Adressen H0 möglich ist, trotzdem aber weiterhin alle in einem eingebetteten System 10 nützlichen Anwendungsfälle von einem virtuellen Adressraum V darstellbar sind. Zusätzlich wird eine speichereffiziente Datenstruktur für die Abbildungsvorschrift ermöglicht. Die Programme P, die in dem eingebetteten System 10 ausgeführt werden, müssen das Speicherlayout L besitzen, welches den Einschränkungen, d.h. den oben genannten Regeln des virtuellen Adressraums V entspricht.
-
Die Umrechnungstabelle T1 weist mehrere Zeilen und Spalten auf, wobei die Zeilen den Segmenten S des virtuellen Adressraums V entsprechen. Die Anzahl der Zeilen in der Umrechnungstabelle T1 ist also identisch mit der Anzahl der Segmente S, in die der virtuelle Adressraum V unterteilt wurde. Jede zu einem Segment S gehörende Zeile hat eine physische Adresse H0, mehrere Felder, die die Länge des Speicherbereichs angeben und eine Zugriffseigenschaft Z1. 6 zeigt eine beispielhafte Umrechnungstabelle T1 für das Programm P aus 3. Die Spalte des Segments S in 6 dient nur als Annotation für den Leser, um leichter zu erkennen, welche Zeile zu welchem Segment gehört. Die Spalte des Segments S ist nicht Teil der Umrechnungstabelle, weshalb diese in den 7 bis 9 nicht dargestellt ist.
-
Die erste Spalte enthält die physische Anfangsadresse HA0 auf die das Segment S abgebildet wurde. Die zweite Spalte bis zur vierten Spalte enthalten die Länge des Speicherbereichs. Die fünfte Spalte enthält die Zugriffseigenschaft Z1 als Bitmap (je ein Bit für die Attribute lesbar, schreibbar, ausführbar).
-
Speicherzugriffe haben unterschiedliche Zugriffsbreiten, z.B. ein Byte, zwei Bytes oder vier Bytes. Es gibt in der Umrechnungstabelle T1 ein Längenfeld pro möglicher Zugriffsbreite. Länge-i, also in 6 Länge Eins L1, Länge Zwei L2 und Länge Vier L4, gibt an, unterhalb welches Segment-Offsets eine virtuelle Adresse V0 liegen muss, damit ein Zugriff der Breite i innerhalb des abgebildeten Speicherbereichs bleibt.
-
Zur Adressumrechnung einer virtuellen Adresse V0 werden bei einem Speicherzugriff folgende Schritte von der Ausführungseinheit 16 durchgeführt: die erste virtuelle Adresse V1 wird in eine Segmentnummer N und ein Segment-Offset O aufgespalten. Da die Anzahl n an Segmenten S eine Zweierpotenz ist, bilden die höherwertigen log2 n Bits von der ersten virtuellen Adresse V1 die Segmentnummer N. Die restlichen Bits ergeben den Segment-Offset O.
-
7 und 8 zeigen ein Beispiel einer Umrechnung in sechs Schritten I bis VI einer ersten virtuellen Adresse V1 = 0x40000b90 in eine erste physische Adresse H1 = 0x41b90. Es handelt sich im Beispiel um einen 32-Bit virtuellen Adressraum mit acht Segmenten.
-
In einem ersten Schritt I wird das Segment S, welches der ersten virtuellen Adresse V1 zugewiesen ist, sowie dessen physische Anfangsadresse HA0 ermittelt. Dazu wird die erste virtuelle Adresse V1 untersucht. Bei acht Segmenten bilden die höherwertigsten drei Bits der 32 Bit Hexadezimalzahl 0x40000b90 die Segmentnummer N=2, welche die Zeile des dritten Segments S2 der Umrechnungstabelle T1 angibt. Die verbleibenden niederwertigen 32 - 3 = 29 Bits der Hexadezimalzahl 0x40000b90 bilden den Segment-Offset 0 = 0xb90. Anschließend wird die zur Segmentnummer N korrespondierende Zeile der Umrechnungstabelle T1 zur Adressumrechnung herangezogen. Die erste Spalte der Umrechnungstabelle T1 gibt die physische Anfangsadresse HA0 an.
-
In einem zweiten Schritt II wird die Zugriffseigenschaft Z1 der zuvor identifizierten Zeile, nämlich des dritten Segments S2 ermittelt. Wie in 7 dargestellt, erlaubt diese das Lesen „r“ und das Ausführen „x“.
-
In einem dritten Schritt III wird die Zugriffseigenschaft Z1 der zuvor identifizierten Zeile, nämlich des dritten Segments S2 mit der Zugriffseigenschaft Z1 des Speicherzugriffs auf die erste virtuellen Adresse V1 verglichen. Die Zugriffseigenschaft Z1 des dritten Segments S2 muss den entsprechenden Typ des Speicherzugriffs (z.B. lesen „r“, schreiben „w“ oder ausführen „x“) erlauben. Ansonsten schlägt die Umrechnung fehl.
-
8 zeigt ein Beispiel einer fehlgeschlagenen Umrechnung. Dort forderte die Zugriffseigenschaft Z1 des Speicherzugriffs auf die erste virtuellen Adresse V1 das Schreiben „w“. Die Zugriffseigenschaft Z1 der zuvor identifizierten Zeile, nämlich des dritten Segments S2 erlaubte aber nur das Lesen „r“ oder das Ausführen „x“. In diesem Fall sind die Längen-Prüfung und die Adressumrechnung an sich nicht weiter notwendig. Die Adressumrechnung schlägt fehl, wodurch das Programm P den Speicherzugriff nicht durchführen darf und somit beispielsweise mit einem Fehler abgebrochen wird.
-
Ist der Zugriff erlaubt, wie in 7 für einen Zwei-Byte-Lesezugriff dargestellt, dann wird der Segment-Offset O in einem vierten Schritt IV ermittelt, indem von der ersten virtuellen Adresse V1 die niederwertigsten Bits extrahiert werden. Anschließend wird in einem fünften Schritt V der ermittelte Segment-Offset O mit dem der Zugriffsbreite entsprechenden Längenfeld L1, L2, L4. verglichen.
-
Liegt der Segment-Offset O unter dem Wert im Längenfeld L1, L2, L4, kann die erste virtuelle Adresse V1 umgerechnet werden. In diesem Fall wird in einem sechsten Schritt VI die erste physische Adresse H1 angegeben. Im Beispiel von 7 ist dies H1= 0x41b90.
-
Die Umrechnung von der ersten virtuellen Adresse V1 auf eine korrespondierende erste physische Adresse H1 erfolgt, indem der Segment-Offset O auf die im Eintrag der Segmentnummer N hinterlegte physische Anfangsadresse HA0 addiert wird. Die einzelnen Schritte der Umrechnung sind effizient, da sie mit konstantem Laufzeitbedarf realisierbar sind.
-
Falls der Segment-Offset O nicht unter dem Wert im Längenfeld L1, L2, L4 liegt, wird das Programm P abgebrochen. 9 zeigt einen Abbruch bei Schritt V aufgrund eines versuchten Zugriffs außerhalb des Speicherbereichs. Das Segment S das zu der zweiten virtuellen Adresse V2 = 0x40000b92 gehört, ist insgesamt 0xb94 Bytes lang. D.h. der für dieses Segment gültige virtuelle Adressbereich liegt im Intervall [0x40000000, x40000b93]. Der Vier-Byte-Zugriff im Beispiel würde aber versuchen, die vier Bytes von den Adressen 0x40000b92, 0x40000b93, 0x40000b94 und 0x4000b95 zu laden. Die letzten beiden Adressen sind jedoch außerhalb des Bereichs. Dies wird durch den Längenvergleich im Schritt V festgestellt, was zu einem Fehler führt und somit die Umrechnung (und damit das Programm) abbricht. In diesem Fall ist die Adressumrechnung nicht weiter notwendig.
-
Die Erfindung ermöglicht in einem eingebetteten System 10 ohne MMU eine effiziente Umrechnung von virtuellen Adressen V0 auf physische Adressen H0. Aufgrund des Designs der Umrechnungstabelle T1 ist eine Adressumrechnung von einer virtuellen Adresse V0 in eine physische Adresse H0 in konstanter Zeit möglich.
