Der Artikel"Multi-application card controllers go 32-bit"von Bernd Meier in der Zeitschrift SECURE-The Silicon Trust Report, herausgegeben von Infineon Technologies AG, Nr. 5,2002, Seiten 32-35, verfügbar unter http ://www. silicon-trust. conz/pdf/secure 5/32 techno l. pdf, beschreibt ein virtuelles Speicherverwaltungssystem für tragbare Datenträger. Der auf dem Datenträger vorhandene Speicher ist, ebenso wie ein virtueller Adreßraum, in Seiten von je 64 Byte Länge gegliedert. Eine Speicherverwaltungseinheit ordnet Seiten in einem virtuellem Adreßraum den jeweiligen Seitenrahmen im physischen Speicher zu. Programme können noch nach der Personalisie- rung des Datenträgers in diesen nachgeladen werden. Ein Dateisystem zur Speicherung solcher Programme und anderer Dateien ist jedoch nicht beschrieben.

Allgemein besteht bei Dateisystemen für tragbare Datenträger das Bedürfnis, die darin gespeicherten Dateien möglichst speicherplatzsparend-im Ideal- fall verschnittfrei-anzuordnen. Wenn eine solche nach den Kriterien des Dateisystems im Speicher angeordnete Datei jedoch ein Programm enthält, muß dieses zur Ausführung durch den Datenträger in der Regel kopiert oder verschoben werden. Dies ist erforderlich, weil die Speicherverwaltungs- einheit des Datenträgers Seitenrahmen (page frames) im Speicher vorgibt, an

deren Grenzen das Programm ausgerichtet sein muß, um ausgeführt werden zu können. Es wäre reiner Zufall, wenn das im Dateisystem befindliche Pro- gramm bereits die erforderliche Lage im Speicher aufweisen würde. Der zeit- und speicheraufwendige Kopier-oder Verschiebevorgang stellt einen erheblichen Nachteil dar.

Die Erfindung hat demgemäß die Aufgabe, eine Technik zur Speicherver- waltung bei tragbaren Datenträgern zu schaffen, die es ermöglicht, in einem Dateisystem gespeicherte Programme unmittelbar an ihrem Speicherort im Dateisystem auszuführen ("execute in place"). Vorzugsweise soll die Erfin- dung im Zusammenhang mit den unterschiedlichsten Dateisystemen ein- setzbar sein, wobei keine oder allenfalls eine geringe Anpassung des vorge- sehenen Dateisystems erforderlich sein soll. Es können dann z. B. besonders zuverlässige und/oder besonders speicherplatzsparende Dateisysteme ver- wendet werden.

Erfindungsgemäß wird die genannte Aufgabe ganz oder zum Teil gelöst durch ein Verfahren gemäß Anspruch 1, einen tragbaren Datenträger gemäß Anspruch 10 sowie ein Computerprogrammprodukt gemäß Anspruch 12.

Die abhängigen Ansprüche betreffen bevorzugte Ausgestaltungen der Erfin- dung.

Die Erfindung geht von der Grundüberlegung aus, in dem Dateisystem eingetragene Programme in Speicherblöcken abzulegen, die in ihrer Lage im Speicher mit den durch die Speicherverwaltungseinheit vorgegebenen Sei- tenrahmen des Speichers verträglich sind. Ein im Dateisystem eingetragenes Programm kann daher ohne Kopier-oder Verschiebevorgänge unmittelbar in den Speicherblöcken, in denen das Programm gespeichert ist, ausgeführt werden. Der Eintrag eines solchen Programms enthält zumindest Verweise

auf die Speicherblöcke, in denen sich das Programm befindet ; in manchen Ausgestaltungen kann der Eintrag statt der Verweise oder zusätzlich zu den Verweisen auch alle oder einige der Speicherblöcke enthalten.

Die Erfindung ermöglicht somit ein"execute i ? 2 place"der im Dateisystem eingetragenen Programme, ohne zwingend zu erfordern, daß alle Daten- strukturen des Dateisystems vollständig an den durch die Speicherverwal- tungseinheit vorgegebenen Grenzen der Speicherrahmen ausgerichtet bzw. gerastert sind. Eine vollständige Rasterung des Dateisystems hätte insbeson- dere bei kleinen Dateigrößen und/oder großen Seitenrahmen den Nachteil eines erheblichen Speicherverschnitts. Zwar umfaßt die Erfindung allgemein auch solche Ausführungsformen ; es werden jedoch Ausgestaltungen bevor- zugt, bei denen zumindest manche Datenstrukturen des Dateisystems unab- hängig von den Seitenrahmengrenzen im Speicher des Datenträgers ange- ordnet sind. Dies betrifft insbesondere Datenstrukturen, die nicht Bestandteil von ausführbaren Programmen sind, z. B. Verzeichnisse oder reguläre, nicht- ausführbare Dateien. Auf diese Weise läßt sich eine besonders gute Speicher- platzausnutzung erreichen.

Erfindungsgemäß wird hinsichtlich des eingesetzten Dateisystems lediglich gefordert, daß das Dateisystem Einträge für Programme aufzunehmen ver- mag, wobei jeder Eintrag seinerseits zumindest Verweise auf Speicherblöcke enthält. In manchen Ausgestaltungen können die Einträge reguläre Dateien sein, in denen die Verweise enthalten sind. In anderen Ausgestaltungen ent- sprechen die Einträge dagegen internen Verwaltungsinformationen des Dateisystems.

Die Erfindung kann in so gut wie jedes bekannte Dateisystem mit allenfalls geringem Änderungsaufwand integriert werden. Hierbei sind insbesondere

Dateisysteme zu nennen, die Speicherverschnitt vermeiden, weil sie mit Da- tenstrukturen unterschiedlicher Größe (z. B. sogenannten Extents) arbeiten.

Es können jedoch auch Dateisysteme eingesetzt werden, die rein block- orientiert arbeiten. Vorzugsweise wird ein erprobtes und als zuverlässig bekanntes Dateisystem eingesetzt.

Erfindungsgemäß sollen die Speicherblöcke, in denen sich die Programme im Speicher befinden, in ihrer Lage im Speicher mit den durch die Speicher- verwaltungseinheit vorgegebenen Seitenrahmen (page frames) des Speichers verträglich sein. Hierbei soll unter einem"Seitenrahmen"gemäß dem übli- chen Sprachgebrauch ein Bereich des realen Speichers verstanden werden, dessen Grenzen durch die Speicherverwaltungseinheit vorgegeben sind und der durch die Speicherverwaltungseinheit einem einstellbaren Bereich virtueller Adressen zugeordnet wird..

In bevorzugten Ausgestaltungen werden die Speicherblöcke dann als ver- täglich mit den durch die Speicherverwaltungseinheit vorgegebenen Seiten- rahmen angesehen, wenn die Grenzen jedes Speicherblocks auf Seitenrah- mengrenzen fallen. Hierbei kann in manchen Ausführungsformen jeder Speicherblock mehrere Seitenrahmen vollständig enthalten. Besonders be- vorzugt sind jedoch Ausgestaltungen, in denen die Speicherblöcke und die Seitenrahmen zusammenfallen, also die gleiche Größe und die gleiche Aus- richtung im Speicher aufweisen. Auch Ausführungsformen, bei denen jeder Seitenrahmen mehrere Speicherblöcke enthält, sind nicht ausgeschlossen.

Hierbei muß jedoch darauf geachtet werden, daß ausführbare Programme stets in Gruppen aufeinanderfolgender Speicherblöcke abgelegt werden, weil sonst der im Speicher befindliche Programmcode nicht mit der Anord- nung der Seitenrahmen verträglich wäre.

Die Speicherblöcke, in denen die im Dateisystem eingetragenen Programme gespeichert sind, können in unterschiedlichen Ausgestaltungen in dem Dateisystem und/oder in einem gesonderten Rasterbereich enthalten sein.

Ferner kann vorgesehen sein, das gesamte Dateisystem in Speicherblöcke zu gliedern, die mit den Seitenrahmen verträglich sind. Verwaltungsinforma- tionen des Dateisystems oder nicht-ausführbare Dateien brauchen hierbei nicht an den Blockgrenzen ausgerichtet zu werden, so daß der Verschnitt gering gehalten werden kann.

Zur Ausführung eines gespeicherten Programms wird vorzugsweise ein virtueller Adreßraum aufgebaut, indem die Speicherverwaltungseinheit auf Grundlage der im Dateisystem enthaltenen Verweise geeignet konfiguriert wird. Die Konfigurationsinformationen können in dem Hauptspeicher des Datenträgers oder ganz oder teilweise in einem separaten Cache-Bereich abgelegt werden.

In vorteilhaften Ausgestaltungen weist der Datenträger ein UNIX (E)-artiges Betriebssystem auf. Besonders bevorzugt werden ein Linux (E)-Betriebssystem und ein dafür. vorgesehenes Dateisystem in geeignet modifizierter Form eingesetzt. Solche Dateisysteme sind z. B. unter den Namen Ext2fs, Ext3fs, ReiserFS, XFS und JFS an sich bekannt. Das Buch"Understanding tlie Linux Kernel"von D. P. Bovet und M. Cesati, O'Reilly Verlag, 2. Auflage, Dezember 2002, auf das hiermit verwiesen wird, enthält eine detaillierte technische Beschreibung des LinuxOO-Betriebssystems.

Der erfindungsgemäße Datenträger enthält ein Dateisystem und Speicher- blöcke mit ausführbaren Programmen.

Das erfindungsgemäße Computerprogrammprodukt kann ein körperliches Medium mit gespeicherten Programmbefehlen sein, beispielsweise ein Halb- leiterspeicher oder eine Diskette oder eine CD-ROM. Das Computerpro- grammprodukt kann jedoch auch ein nicht-körperliches Medium sein, bei- spielsweise ein über ein Computernetzwerk übermitteltes Signal. Insbeson- dere kann das Computerprogrammprodukt ein Betriebssystem oder ein Betriebssystemmodul enthalten, das im Zuge der Herstellung oder der Initialisierung oder der Personalisierung eines tragbaren Datenträgers in diesen eingebracht wird.

In bevorzugten Ausgestaltungen weisen der Datenträger und/oder das Computerprogrammprodukt Merkmale auf, die den oben beschriebenen und/oder den in den abhängigen Verfahrensansprüchen genannten Merk- . malen entsprechen.

Weitere Merkmale, Vorteile und Aufgaben der Erfindung gehen aus der folgenden Beschreibung mehrerer Ausführungsbeispiele und Ausführungs- alternativen hervor. Es wird auf die Zeichnung verwiesen, in denen zeigen : Fig. 1 ein Blockdiagramm eines Datenträgers mit einem Dateisystem und einem separaten Rasterbereich nach einem Ausführungsbeispiel der Erfin- dung, Fig. 2 ein Flußdiagramm eines Verfahrens zur Ausführung eines Programms bei einem erfindungsgemäßen Datenträger, und Fig. 3 eine Darstellung eines Dateisystems und einer Blockbelegungstabelle in einer gegenüber Fig. 1 abgewandelten Ausführungsform.

Der in Fig. 1 dargestellte Datenträger 10 weist auf einem einzigen Halbleiter- chip einen Prozessor 12, einen Speicher 14 und eine Schnittstellenschaltung 16 zur kontaktlosen oder kontaktgebundenen Kommunikation mit einem externen Terminal (nicht gezeigt) auf.

Der Speicher 14 ist in mehrere Speicherfelder unterteilt. Im vorliegenden Ausführungsbeispiel sind als Speicherfelder ein als RAM ausgestalteter Arbeitsspeicher 18, ein als ROM ausgestalteter Festwertspeicher 20 und ein als EEPROM ausgestalteter, nicht-flüchtiger Speicher 22 vorgesehen. Im Speicher 14-und zwar teils im Festwertspeicher 20 und teils im nicht-flüch- tigen Speicher 22-befindet sich Programmcode, der ein Betriebssystem 24 implementiert. Das Betriebssystem 24 ist im vorliegenden Ausführungsbei- spiel eine auf den Einsatz im Datenträger 10 zugeschnittene Variante des unter der Marke Linux bekannten Betriebssystems.

Der Prozessor 12 beinhaltet einen Prozessorkern 26 und eine Speicherver- waltungseinheit (MMU-memory management unit) 28. Der Prozessorkern 26 vermag über einen internen Adreßbus 30, einen externen Adreßbus 32 und einen Datenbus 34 auf den Speicher 14 zuzugreifen. Die Speicherverwal- tungseinheit 28 ist zwischen den internen und den externen Adreßbus 30,32 geschaltet, um logische Adressen, die der Prozessorkern 26 bei der Pro- grammausführung auf den internen Adreßbus 30 ausgibt, in physische Adressen des Speichers 14 umzusetzen.

Die Adreßumsetzung erfolgt mit einer hardwaremäßig vorgegebenen Granularität. Die Speicherverwaltungseinheit 28 ordnet je einer Seite des virtuellen Adreßraums je eine reale Seite im Speicher 14 zu, falls eine solche reale Seite verfügbar ist. Die realen Seiten im Speicher 14 sind in einem durch die Speicherverwaltungseinheit 28 vorgegebenen Raster angeordnet.

Jedes Feld in diesem Raster, also jeder Speicherbereich, der eine Speicher- seite aufzunehmen vermag, wird als Seitenrahmen bezeichnet. Die Größe jedes Seitenrahmens kann z. B. 1 KByte betragen.

Die Abbildung virtueller Speicherseiten in die Seitenrahmen des Speichers 14 wird durch Seitenzuordnungsdaten 36 bestimmt, die in der konzeptuellen Darstellung von Fig. 1 der Speicherverwaltungseinheit 28 zugeordnet sind.

Die Seitenzuordnungsdaten 36 können eine Seitentabelle oder mehrere hierarchisch gegliederte Seitentabellen aufweisen. Ferner kann ein Cache vorgesehen sein, um Zugriffe auf häufig benötigte Teile der Seitenzuord- nungsdaten 36 zu beschleunigen. In unterschiedlichen Ausgestaltungen können die Seitenzuordnungsdaten 36 ganz oder teilweise im Speicher 14 oder ganz oder teilweise in einem speziellen Cache-Bereich des Prozessors 12 enthalten sein.

Der nicht-flüchtige Speicher 22 enthält ein Dateisystem 38, das eine Vielzahl von Einträgen aufweist. In Fig. 1 sind als Einträge des Dateisystems 38 bei- spielhaft ein Verzeichnis 40 und drei Dateien 42,44, 46 gezeigt. Das Datei- system 38 weist im vorliegenden Ausführungsbeispiel eine an sich bekannte Struktur auf ; beispielsweise kann eines der unter den Namen Ext2fs, Ext3fs, ReiserFS, XFS und JFS bekannten Systeme als Dateisystem 38 eingesetzt werden. Das Dateisystem 36 kann blockorientiert sein und z. B. eine Block- rasterung verwenden, die mit der durch die Speicherverwaltungseinheit 28 vorgegebenen Rasterung der Seitenrahmen übereinstimmt. In anderen Aus- gestaltungen nutzt das Dateisystem 38 den zur Verfügung stehenden Spei- cherbereich dagegen ohne Rücksicht auf die Seitenrahmeneinteilung.

Im nicht-flüchtigen Speicher 22 ist ferner ein Rasterbereich 48 vorgesehen, der in dem in Fig. 1 gezeigten Ausführungsbeispiel nicht Bestandteil des

Dateisystems 38 ist. Der Rasterbereich 48 ist so gegliedert, daß die Raster- felder mit den durch die Speicherverwaltungseinheit 28 definierten Seiten- rahmen verträglich sind. In dem Ausführungsbeispiel von Fig. 1 entspricht jedes im Rasterbereich 48 gezeigte Feld genau einem Seitenrahmen ; einige dieser Seitenrahmen sind beispielhaft mit den Bezugszeichen 50.1, 50.2, 50.3, 50.4-im folgenden zusammenfassend mit 50. x bezeichnet-versehen.

Im Beispiel von Fig. 1 enthält der Speicher 14 zwei Programme, die in Spei- cherblöcke untergliedert und in dem Rasterbereich 48 gespeichert sind.

Die Speicherblöcke des ersten Programms sind in Fig. 1 beispielhaft durch eine senkrechte Schraffur gezeigt, und die Speicherblöcke des zweiten Pro- gramms sind durch eine waagerechte Schraffur gezeigt. Ein Speicherblock des ersten Programms, nämlich der in dem Seitenrahmen 50.2 befindliche, ist beispielhaft mit dem Bezugszeichen 52. 1 versehen. Der in dem Seitenrahmen 50.4 befindliche Speicherblock des zweiten Programms trägt das Bezugszei- chen 52.2. Die Speicherblöcke 52.1 und 52.2 sowie weitere Speicherblöcke, die Teile von ausführbaren Programmen enthalten, werden im folgenden zusammenfassend mit 52. x bezeichnet.

Der Rasterbereich 48 weist im Seitenrahmen 50.1 eine Blockbelegungstabelle 54 auf, die-z. B. in Form eines Bitfeldes-angibt, welche Seitenrahmen 50. x durch Speicherblöcke 52. x belegt und welche Seitenrahmen 50. x frei sind.

Die freien Seitenrahmen 50. x sind in Fig. 1. ohne Schraffur dargestellt. Die Blockbelegungstabelle 54 braucht nicht notwendigerweise an dem Seitenrah- menraster ausgerichtet zu sein ; in Ausführungsalternativen ist vorgesehen, die Blockbelegungstabelle 54 außerhalb des Rasterbereichs 48 zu speichern.

Die Verknüpfung zwischen einem Eintrag eines ausführbaren Programms im Dateisystem 38 und den zugehörigen Speicherblöcken 52. x erfolgt über

Verweise, die im Eintrag enthalten sind. So wird beispielsweise in der Dar- stellung von Fig. 1 der das erste Programm betreffende Eintrag durch die Datei 42 gebildet, die ihrerseits Verweise-z. B. Zeiger oder Adreßinforma- tionen-auf die Speicherblöcke 52. x des ersten Programms enthält. So zeigt z. B. der in der Datei 42 angelegte Verweis 56.1 auf den Speicherblock 52.1 des ersten Programms im Seitenrahmen 50.2, und der in der Datei 46 enthal- tene Verweis 56.2 zeigt auf den Speicherblock 52.2 des zweiten Programms im Seitenrahmen 50.4. Zusammenfassend werden die im Dateisystem 38 angelegten Verweise auf Speicherblöcke 52. x im folgenden mit 56. x bezeich- net.

In dem hier beschriebenen Ausführungsbeispiel sind die Verweise 56. x in regulären Dateien des Dateisystems 38-hier z. B. den Dateien 42 und 46- gespeichert. Im Hinblick auf die Verwaltungsstrukturen des Dateisystems 38 besteht daher kein Unterschied zwischen diesen Dateien 42 und 46 und der Datei 44, die nicht mit einem ausführbaren Programm in Beziehung steht.

Diese Ausgestaltung hat den Vorteil, daß keinerlei Besonderheiten des Datei- systems 38 berücksichtigt werden müssen. In Ausführungsalternativen kann jedoch vorgesehen sein, die Einträge im Dateisystem 38, die sich auf ausführ- bare Programme beziehen, nicht als reguläre Dateien anzulegen, sondern diese Einträge z. B. in Verwaltungsinformationen des Dateisystems zu inte- grieren.

In dem bislang beschriebenen Ausführungsbeispiel stimmte die Speicher- blöcke 52. x in ihrer Größe und Ausrichtung im Rasterbereich 48 genau mit den durch die Speicherverwaltungseinheit 28 vorgegebenen Seitenrahmen 50. x überein. In Ausführungsalternativen kann dagegen vorgesehen sein, daß ein Speicherblock 52. x mehrere Seitenrahmen 50. x vollständig ausfüllt.

Ebenso kann vorgesehen sein, daß mehrere Speicherblöcke 52. x in einen

Seitenrahmen 50. x fallen ; hierbei muß jedoch durch die Verwaltung des Rasterbereichs 48 sichergestellt werden, daß solche in einem einzigen Sei- tenrahmen 50. x befindliche Speicherblöcke 52. x stets einen einzigen, zusam- menhängenden Abschnitt des jeweiligen Programms enthalten.

Fig. 2 zeigt einen beispielhaften Ablauf, der von dem Datenträger 10 ausge- führt wird, um ein im Rasterbereich 48 enthaltenes Programm zu starten.

Der Ablauf beginnt in Schritt 60 damit, daß das Betriebssystem 24 einen Befehl zur Ausführung des Programms erhält. In Schritt 62 wird der das Programm betreffende Eintrag im Dateisystem 38 geöffnet ; in dem Ausfüh- rungsbeispiel von Fig. 1 ist dieser Eintrag als Verweisdatei-z. B. als Datei 42 - ausgestaltet. Die in der Verweisdatei enthaltenen Verweise 56. x werden in Schritt 64 gelesen.

In Schritt 66 werden Seitenzuordnungsinformationen erzeugt und an die Speicherverwaltungseinheit 28 übergeben. Hierbei sind in der Regel Ver- arbeitungsschritte erforderlich, um aus dem Inhalt des Eintrags bzw. der Verweisdatei die Seitenzuordnungsdaten 36 in dem von der Speicherver- waltungseinheit 28 benötigten Format zu generieren. Die in Schritt 66 er- wähnten Seitenzuordnungsinformationen können den unverarbeiteten Roh- daten oder den Seitenzuordnungsdaten 36 oder Zwischeninformationen, die bei der Verarbeitung anfallen, entsprechen. In besonders einfachen Ausge- staltungen enthält der Eintrag im Dateisystem 38 bereits die benötigten Seitenzuordnungsdaten 36 in einer von der Speicherverwaltungseinheit 28 unmittelbar verwendbaren Form.

Nach dem Schließen der Verweisdatei-z. B. der Datei 42-in Schritt 68 stellt die Speicherverwaltungseinheit 28 in Schritt 70 einen virtuellen Adreßraum für das Programm zur Verfügung. Hierbei können in manchen Ausgestal-

tungen weitere Verarbeitungsschritte der Seitenzuordnungsdaten 36 erfol- gen, während in anderen Ausführungsformen die Speicherverwaltungs- einheit 28 schon im Zusammenhang mit Schritt 66 vollständig konfiguriert wurde.

Die Speicherverwaltungseinheit 28 ist nun so konfiguriert, daß sie die logi- schen Adressen des virtuellen Adreßraums des Programms auf die entspre- chenden Speicherblöcke 52. x im Rasterbereich 48 abbildet. Das Programm kann damit-ohne daß ein Kopier-oder Verschiebevorgang erforderlich wäre-unmittelbar an dem Speicherort der Speicherblöcke 52. x im Raster- bereich 48 ausgeführt werden. Die Tatsache, daß das Programm im realen Adreßraum des Speichers 14 möglicherweise in Speicherblöcken 52. x vor- liegt, die nicht zusammenhängen und/oder in ihrer Reihenfolge vertauscht sind, wird durch die von der Speicherverwaltungseinheit 28 vorgenommene Adreßabbildung ausgeglichen. Für das Programm kann somit, falls ge- wünscht, z. B. ein großer zusammenhängender Adreßraum zur Verfügung gestellt werden.

Bei dem Ausführungsbeispiel von Fig. 1 ist der Rasterbereich 48 von dem Dateisystem 38 getrennt. Fig. 3 zeigt eine Ausführungsalternative mit einem blockorientierten Dateisystem 38', das den gesamten zur Verfügung stehen- den Speicherplatz einnimmt. Das gesamte Dateisystem 38'ist gemäß den durch die Speicherverwaltungseinheit 28 (Fig. 1) vorgegebenen Seitenrah- men 50.1', 50.2', 50.3', 50.4',...-allgemein mit 50. x' bezeichnet-gerastert.

Jeder Seitenrahmen 50. x' im Dateisystem 38'kann, sofern er nicht leer ist, entweder Strukturen des Dateisystems 38'oder einen Speicherblock 52.1', 52. 2',...-allgemein mit 52. x' bezeichnet-eines ausführbaren Programms aufweisen.

Als Strukturen des Dateisystems 38'sind in Fig. 3 beispielhaft ein Dateibaum mit einem Verzeichnis 40'und drei Dateien 42', 44', 46'dargestellt. Die Da- teien 42'und 44'beziehen sich nicht auf ausführbare Programme. Diese Dateien 42', 44'werden daher gemäß der durch das Dateisystem 38'vorge- sehenen Struktur angelegt. Insbesondere ist in manchen Ausgestaltungen vorgesehen, nicht-ausführbare Dateien und andere Strukturen des Datei- systems 38'-z. B. Verzeichnisse oder Verwaltungsinformationen-nicht an den Grenzen der Seitenrahmen 50. x zu orientieren, sondern sie möglichst verschnittfrei im Speicher 14 anzuordnen. Dies ist in Fig. 3 am Beispiel der Datei 42'veranschaulicht, die sich über einen zusammenhängenden Speicherbereich, welcher je einen Teil der Seitenrahmen 50. 1' und 50.2' einnimmt, erstreckt.

Die Datei 46'stellt einen Eintrag eines ausführbaren Programms im Datei- system 38'dar. Wie bereits im Zusammenhang mit Fig. 1 erläutert, ist die Datei 46'als Verweisdatei ausgestaltet, die je einen Verweis 56.1', 56.2',...- allgemein mit 56. x' bezeichnet-auf die Speicherblöcke 52. x' des ausführ- baren Programms aufweist. Diese mit Programmcode belegten Speicher- blöcke 52. x' sind in Fig. 1 schraffiert gezeigt ; jeder Speicherblock 52. x' füllt exakt einen Seitenrahmen 50. x' des gerasterten Dateisystems 38'aus. In Aus- führungsalternativen können, wie oben bereits erwähnt, die Größen der Seitenrahmen 50. x'und der Speicherblöcke 52. x' voneinander abweichen, sofern nur die Lage der Speicherblöcke 52. x' mit den vorgegebenen Grenzen der Seitenrahmen 50. x' verträglich ist.

Fig. 3 zeigt ferner eine Blockbelegungstabelle 54', deren Inhalt die beispiel- hafte Belegung des in Fig. 3 dargestellten Abschnitts des gerasterten Datei- systems 38'widerspiegelt. Die Blockbelegungstabelle 54'kann in dem Datei- system 38'gespeichert oder von diesem getrennt sein.

Diverse Abwandlungen, die oben bereits im Zusammenhang mit Fig. 1 be- schrieben worden sind, lassen sich entsprechend auf das Dateisystem 38'von Fig. 3 anwenden. Insbesondere kann es vorteilhaft sein, Einträge im Datei- system 38', die ausführbaren Programmen entsprechen, nicht als reguläre Dateien-wie z. B. die Datei 46'-anzulegen. Vielmehr können solche Einträ- ge in den eigentlichen Dateibaum integriert werden, indem die entsprechen- den Verweise 56. x' z. B. in Verwaltungsinformationen des Dateisystems 38' aufgenommen werden. Solche Verwaltungsinformationen können in man- chen Ausgestaltungen sogenannte index nodes oder inodes sein.

Der Aufruf eines in dem gerasterten Dateisystem 38'von Fig. 3 gespeicherten Programms erfolgt z. B. gemäß dem oben beschriebenen und in Fig. 2 darge- stellten Verfahren.