WO1994027222A1 - Verfahren zum umsetzen einer virtuellen speicheradresse mit einer ersten länge in eine realadresse mit einer zweiten länge - Google Patents

Verfahren zum umsetzen einer virtuellen speicheradresse mit einer ersten länge in eine realadresse mit einer zweiten länge Download PDF

Info

Publication number
WO1994027222A1
WO1994027222A1 PCT/EP1994/001453 EP9401453W WO9427222A1 WO 1994027222 A1 WO1994027222 A1 WO 1994027222A1 EP 9401453 W EP9401453 W EP 9401453W WO 9427222 A1 WO9427222 A1 WO 9427222A1
Authority
WO
WIPO (PCT)
Prior art keywords
bit string
address
bits
entry
bit
Prior art date
Application number
PCT/EP1994/001453
Other languages
English (en)
French (fr)
Inventor
Jochen Liedtke
Original Assignee
Jochen Liedtke
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from DE4405845A external-priority patent/DE4405845C2/de
Application filed by Jochen Liedtke filed Critical Jochen Liedtke
Priority to US08/549,731 priority Critical patent/US5790979A/en
Publication of WO1994027222A1 publication Critical patent/WO1994027222A1/de

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/10—Address translation
    • G06F12/1009—Address translation using page tables, e.g. page table structures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/65—Details of virtual memory and virtual address translation
    • G06F2212/652—Page size control

Definitions

  • the invention relates to a method for mapping a first bit string with a first length onto a second bit string with a second length.
  • Such a method can be used in particular when it comes to converting the address of the virtual memory into the address of the real memory in the case of computers with virtual memories in the so-called MMU (Memory Management Unit).
  • MMU Memory Management Unit
  • the virtual ⁇ real address conversion is conventionally carried out in a multi-stage process in which so-called page tables are used.
  • a first table is addressed using the first bits of a virtual address and the value stored under this table address is read out.
  • the value read out is the start address of a second table which is addressed by the next group of bits of the virtual address. Since the groups each comprise a number of bits which is fixed in advance and constant from group to group, the known method runs in several stages until the final table on the data storage side, namely the real memory, is finally reached.
  • the last table shows the data page (also called tile).
  • the remaining bit group (last bits of the virtual address) then represents the address (offset) within the data page.
  • High-resolution MMUs must be able to process 64-bit or even wider virtual addresses (128-bit addresses and even wider addresses are conceivable), page sizes from 8 bytes (8, 16, 32, ..., 1K, 2K, 4K , ...) can be managed, these page sizes should be miscible in the address space and high-resolution MMUs should require a maximum of 16 to 32 bytes (depending on the size of the virtual and the real address space) administration information per allocated page with any assignment of the address space.
  • a single conversion step of a virtual (binary) address v for an action x is to be considered below using a page table with the address p according to the conventional method.
  • v is divided into a higher-order part u (consisting of a certain number of higher-order bits) and one low-order part V (consisting of the low-order bits) split.
  • u an entry of the page table initially addressed by p is then selected. This entry contains an access attribute a and a new address p 'as the start address for the next table or the next page table of the tree.
  • the actions are composed of the read / write or execute operation and the user / kernel operating mode.
  • the access attributes are constructed accordingly, each permitting certain (in extreme cases all or no) actions.
  • the amount and semantics of the specific actions and access attributes and the method of checking "action against attribute" are irrelevant from the point of view of the method presented here. It is only decisive that it is decided on the basis of action x and access attribute a whether the action is permitted or must be terminated. If the access attribute prohibits the action (x> ⁇ a), the implementation is aborted and page fault is signaled. If the action is permissible (x _ a), x, p 'and V are used as input parameters in the implementation of the next stage.
  • V is shorter than v by the bit width of u.
  • p points to the beginning of the data page and V is the offset within the page.
  • the situation according to FIG. 19 results for a two-stage conversion. If 64-bit virtual addresses are to be converted in this way and the minimum page size is to be 16 bytes, this can be done, for example, by a 10-stage conversion (4 KB per page table). to reach. Sparsely populated address spaces therefore require an unbearable administrative effort. 1024 16-byte pages can be allocated in such a way that 20 Kbytes of administrative data are required per 16 data bytes, which is 0.08% user data.
  • each table consists of one entry per tile of the real memory, each of which contains the virtual address of the assigned page of the virtual address space. It is accessed using a hash function.
  • the process is illustrated in Fig. 20.
  • the virtual address v is converted into the real address r, the low-order part w is adopted directly.
  • the higher-value part u is mapped to a value p by the hash function, which both identifies the presumed tile in the real memory and is used for indexing the inverted page table. If the corresponding entry contains the correct virtual address u, there is a hit. Otherwise (not shown in FIG.
  • TLB translation look-aside buffer
  • mapping unit a translation look-aside buffer
  • the invention is based on the object of specifying a method for mapping a first bit string with a first length onto a second bit string with a second length, with which an effective and efficient mapping of a first bit can be achieved with a reduced number and / or size of page tables Bit strings can be implemented on a second bit string, particularly in the case of sparsely occupied (small data pages and / or tiles) large address spaces.
  • an MMU should be described in terms of its mode of operation, which allows the implementation of huge, sparsely populated address spaces (2 64 bytes or more) with the finest possible granularity with reasonable memory and time expenditure.
  • the advantages of the tree-like page tables described above (sharing of subtrees, support for hierarchical operations) are to be retained.
  • the invention provides a method for mapping a first bit string with a first length to a second bit string with a second length, in which a) a first memory area with a first start address (p) and a first length is specified, b) it is checked whether the length of the first memory area is less than or equal to 2 exponentiated with the length of the first bit string (v) and, if this is the case, the sum of the first start address (p) of the first memory area and the first bit string (v) results in the second bit string (data side reached), and if the above test is negative, the first memory area is taken as a first table and c) bits (u) are selected from the first bit string (v) at certain locations, the non-selected remaining bits form a residual bit string (w, v '), d) the selected bits (u) of the first bit string (v) determine an entry of the first table, e) this entry of the first table is read out, f) from the read table entry g the starting address
  • step b) 1) the method from step b) with the non-extracted remaining part (V) of the residual bit string (w, v ') as the first bit string (v) and the start address (p') and length of the further memory area as the start address (p) and length of the first memory area is continued.
  • a first bit string which for example represents a virtual address
  • this first bit string is mapped (implemented, converted or the like) to a second bit string, which in particular represents the real address.
  • a first memory area is specified which has a start address and a length. If an area with a length greater than that of the first memory area cannot be fully addressed with the first bit string, the second bit string is obtained from the sum of the start address of the first table and the first bit string, i.e. from the sum of the numbers represented by the start address and the first bit string. In this case the data page is reached.
  • the length of the first bit string is greater than the length of the first memory area.
  • the first memory area is a first table that is used for address conversion and the number of entries of which is usually a power of two. From the first bit string bits are determined at ten digits selected so that the mapping of the selected bits to the entries in the first table is unambiguous, ie the number of selected bits is equal to the two-logarithm of the number of table entries. The unselected remaining bits of the first bit string then form a residual bit string. The selected bits of the first bit string determine the entry in the first table which is to be read out. This entry contains information about the start address and the length of a further memory area.
  • bit sequence with a certain bit length is also stored in this entry of the table.
  • This bit sequence is the data value which will later also be referred to as "guard”. It is now checked whether the remaining bit string begins, for example, with this bit sequence. If this is the case, an error message is output stating that the image is not defined. If, on the other hand, the test is positive, the remaining bit string is "shortened” by the bits of the bit sequence, ie in this example the leading bits are cut off. Then the method begins again, the remaining part of the remaining bit string being taken as the new first bit string and the start address and length of the further memory area being taken as the start address and length of the new first memory area.
  • a variant of the method is to permute the residual bit string before checking whether it contains the guard and, under certain circumstances, to (re) permute it afterwards.
  • guard a value in the form of the bit sequence in a table next to the starting address for the table of the next level or the data page, which value indicates how much (and below) Around- Which bits would be separated from the remaining bit sequences in order to address the next memory area (table or data page) whose start address is contained in the read-out entry of the previous table with the start bits of the remaining non-separated part of the remaining bit sequences and the entry of the read the address of this table specified in this way.
  • An error message that the implementation is not defined or is possible is always output when the bit sequence representing the guard is not contained in the remaining bit sequence of the first bit string or in the first bit string itself. The longer the guard is, the fewer implementation stages (cycles) are required.
  • the first bits of the first bit string are advantageously taken in order to specify the address of the first table to be read out.
  • the guard is preferably also compared for identity with the first bits of the remaining bit sequence of the first bit string. You can also use bits other than the first bit in both cases.
  • FIG. 1 is a pictorial representation of an implementation step of the inventive method according to the embodiment as a "simple guarded page tables",
  • FIG. 2 shows an example of three binary page tables with two entries each for a 20-bit address conversion with the aid of the method according to FIG. 1,
  • FIG. 3 shows a pictorial representation of the method according to the invention according to the exemplary embodiment in the form with “K-associative guarded page tables”,
  • FIG. 5 shows the method according to FIG. 4, but with a stored information element
  • FIG. 6 shows a schematic illustration for the use of a plurality of TLBs to be processed successively (referred to in the claims with an imaging unit) for the “guarded page table” method
  • 7 shows an implementation for a cache with TLB 0 function
  • FIG. 8 shows a first alternative of an implementation for the module designated TLBi in FIG. 6,
  • FIG. 10 shows a pictorial representation of an implementation step of the method according to the invention in accordance with a further embodiment (user-level mapping),
  • FIG. 11 shows a schematic representation of a part of the tree structure to illustrate the processing of the same according to the method according to FIG. 10,
  • FIG. 13 shows a pictorial representation of an implementation step according to a further exemplary embodiment of the invention
  • 15 shows a first alternative of a hardware implementation of the translator of an MMU according to the invention
  • 16 shows a second alternative of a hardware implementation of the translator of an MMU according to the invention
  • the central idea of the guarded page tables is to add a bit string g of variable length to each page table entry, which is referred to as a guard.
  • a page table entry of a page table with the starting address p is selected by the most significant part u of the virtual address v and the action x is checked against the access attribute a.
  • the selected entry not only contains the access attribute and pointer (start address) for the next page table, but also a further bit sequence, the so-called guard g.
  • the remaining virtual address is divided into a higher value part w (same length as g) and low-order part v 'split.
  • g w.
  • the conversion is terminated with Page Fault, in the case of equality, it is continued with x, p 'and v' in the next stage or p '+ v' is delivered from the last stage as a real address.
  • guards can vary from entry to entry. Your current length is therefore encoded as a length field or otherwise appropriately encoded in the page table entry.
  • the procedure works exactly like the conventional one. But whenever a conventional page table with exactly one entry is required, a guard can be used instead. A guard can even replace a sequence of such page tables that only contain one valid entry each. This saves both memory and conversion steps, i.e. Guards act as a shortcut.
  • each page table entry in the part labeled p contains not only the pointer to the next level page table or data page, but also a size specification s for this object.
  • s denotes the number of entries; All powers of 1, 2, 4, 8 are permissible ...
  • the length of u is then derived from the current page table size. It can be shown that, because of the flexible tree structure above, with the help of the guards pate table trees can be constructed in such a way that a maximum of two page table entries are required per data page, irrespective of the address space size and page size.
  • guards up to 30-bit in length can be used. Then, with 32-bit addresses, a maximum of 16 bytes of administration information is required per page. With 64-bit addresses, longer guards may be necessary in some cases, which are then implemented with an additional 8-byte entry. In the worst case (never more than one page per 2 31 bytes and only 16 byte pages), 40% of the data is user data.
  • the address translation trees can furthermore be constructed in such a way that the highest n / 2 levels are necessary for an n-bit address conversion, the memory requirement mentioned above not being exceeded. With 64-bit addresses a maximum of 30 levels are required, with 32-bit addresses 14 levels are required to reach 16-byte pages.
  • Fig. 3 shows an implementation step for the method with k-associative guarded page tables.
  • k-associative guarded page tables not a page table entry is selected in each step, but k pieces.
  • 8-associative guarded page tables allow n-bit address conversion in a maximum of n / 4 steps with a maximum of two (simple) entries per data page.
  • 64-bit addresses a maximum of 15 levels are required, with 32-bit addresses 7 levels are required to reach 16-byte pages.
  • k / j- associative guarded page tables have the same semantics as k-associative. You only need k / j times the parallelism for the implementation. For the highest possible speed, one only needs k / j parallel works and parallel data paths for k / j entries. (Here, k should be divisible by j without a remainder. In addition, both should be powers of two.)
  • the cluster comprising k entries is divided into j (equally large and connected) subclusters (subareas). If k> s in a page table, k is shortened to s for this conversion step.
  • the conversion operation is then carried out sequentially (k / j-parallel) on different sub-clusters until either a hit occurs or all j sub-clusters are processed. If no hit is found, the address conversion is aborted with Page Fault; in the event of a hit, the procedure is as described in FIG. 3.
  • each p in page table entries as well as in the root or in TLBs is supplemented by a field H with k hint elements (this is relative with k log 2 (j) bits small).
  • k hint elements this is relative with k log 2 (j) bits small.
  • 8/2 associative guarded page tables with hints allow n-bit address conversion in a maximum of n / 4 steps with a maximum of 2 2/7 entries per data page. You need essentially the same time as 8-associative, but you only need 4 instead of 8 parallel works and correspondingly narrower data paths.
  • guarded page table translators must also be supported by TLBs. Special problems are the different page sizes, larger working sets (because of the smaller granularity more pages) and deeper trees with huge address spaces (depth 15 with 60-bit address conversion), ie higher costs with TLB-miss.
  • a multi-stage TLB as shown in FIG. 6 is used for the solution.
  • TLB 0 is a more or less conventional TLB on a page basis or a virtually addressable cache; a hit directly gives the corresponding real address.
  • TLB X operates on larger regions (e.g. 16 MB), so that in the event of a 'near miss' (TLB 0 miss and TLB 1 hit) a lateral entry into the page table tree is possible and only a small part of the tree passes are needed. If necessary, this procedure can be extended naturally by additional TLBx levels.
  • TLB 0 The main problem of the TLB 0 shown in FIG. 6 is the differently sized pages.
  • Known solution for a fully associative TLB (such as for the MIPS R4000), which requires a lot of circuitry, or a virtually addressed cache, which is faster than a real addressed cache, but causes problems with synonyms and consistency problems for multiprocessors .
  • Another solution is a virtually and real addressable cache, which combines the advantages of a virtually addressed (TLB for small, many and differently sized pages) and a real addressed cache (synonyms possible, suitable for multiprocessor systems).
  • TLB virtually addressed
  • a real addressed cache synonyms possible, suitable for multiprocessor systems.
  • FIG. 7 the field a contains the end access attribute, which is created by combining the access attributes of the individual stages in the address conversion.
  • TLB 0 As for the TLB 0 , several solutions are possible for the TLB X and (and for higher levels). One is shown in Fig. 8. For example, a special cache (direct mapped or n-fold associative) can be used for the individual regions. It is associated with the region (e.g. v - 2 24 ) addresses and delivers the next possible entry into the page table tree when a hit occurs.
  • a special cache directly mapped or n-fold associative
  • TLBi-hit and permitted action x ⁇ _ ä
  • TLB X Another alternative for the TLB X according to FIG. 6 is shown in the upper part of FIG. 9. If a sufficiently large TLB 0 or a virtually addressable data cache is used, there is no need for a special cache for TLB X. Instead, a two-level (or multi-level) hierarchy of address translation trees can be used. The address space then looks linearized, for example, as shown in the lower part of FIG. 9.
  • a separate tree is used for each region.
  • the roots of these trees can be reached via a special area in the virtual address space ('region roots'). If a TLB 0 miss is attempted, the corresponding one is now attempted To address the regional tree via its virtual address in the 'region roots' area. If the TLB 0 hit succeeds with the corresponding virtual region root address, there is a TLBi hit. Then only the (not very deep) regional tree needs to be parsed. Otherwise, a complete address conversion of the virtual region root address is carried out starting with 'root' and the regional tree is then parsed. This method requires less hardware, but in extreme cases (only one page per region) an additional page table entry may be required for each accessible page. If the smallest page is larger than a page table entry, the additional memory requirement can increase correspondingly due to fragmentation of the region root area.
  • a further special feature is to be dealt with below, particularly in the case of fine-granular mapping with large address spaces which are sparsely populated.
  • Fine-granular mapping enables access control on the level of logical memory objects (program variables). It can thus be used meaningfully both in the field of classic imperative programming languages and in object-oriented and declarative languages, particularly in the case of distributed or massively parallel systems.
  • Typical applications are:
  • Mapping a virtual memory object to another virtual memory object This can be used for example for object synthesis, but also for the construction of alternative views or simply for parameter transfer.
  • Special access semantics can thus be coupled to memory areas, for example 'delay in read access' (value of the variable has not yet been calculated), 'signal in write access', 'remote object invocation', 'representative access' or simply 'access protocol'.
  • MMU multi-dimensional address space
  • the method to be described in the following can also be built into other MMUs, in particular fine or coarse granular imaging.
  • These MMUs should preferably be based on converting a virtual address into a real address using a page table tree.
  • Page table entries conventionally consist of an access attribute a, which determines the valid actions on the memory area, and a pointer ⁇ , which is used in the normal paint address conversion is the real address p of the next level page table level or the data page.
  • each page table entry also has a type T, which among other things determines the interpretation of the pointer ⁇ .
  • alias type the pointer it is interpreted as a virtual alias address v. If the address conversion at any stage meets an alias entry whose access attribute a allows the access action x, v is added to the undecoded residual address v 'or the new address is formed from v and V in some other way. This situation is shown in Fig. 10 for a conversion step.
  • reference mapping assigns algorithms to address space areas. These can, for example, skip, emulate or treat the causal instruction similarly to a page fault: re-map the memory area in question by alias and restart the instruction, skipping and emulating individual instructions can be accelerated under certain circumstances by special instructions of the processor (see below under the additional instructions “getmap”, “getlength” and “execute”).
  • the emulation can be accelerated by not only assigning the associated procedure ic and v orig as parameters, but also - in the case of write access - the identifier 'write access', the operand length (byte, word, .. .) and the operand value, - for read access - the identifier 'read access', the operand length (byte, word, ...) and the number (address) of the target register.
  • the operation Mov, Add, Ine, (7), the operand length (byte, word, ...), the register / memory address of the source and the register / memory address of the Be passed.
  • the instruction set of the processor is extended by the non-privileged instruction 'map'. This allows user level software to change alias and call on reference entries directly.
  • a page table entry is clearly identified by the virtual address range (this does not apply the other way round, since an entry can be responsible for several virtual address space ranges due to real sharing), which it covers precisely in the primary address conversion.
  • Primary address conversion is understood here to mean the translation process which converts the original virtual address until either a page fault is diagnosed, an alias, call on reference or an entry pointing to a data page is found. Accordingly, the addressed entry is specified by virtual base address b and size s of the associated address space area. Then the instruction loads
  • T For coupling certain hardware actions to address areas, e.g. Triggering complex bus protocols to access remote memory, additional (special) types can be used for T.
  • an address area is sometimes to be blocked, so that access to it by other processors is automatically delayed until it is released.
  • access must be allowed to at least one processor.
  • This can be achieved, inter alia, by virtual or real aliasing.
  • Locking can be brought about by coupling an empty routine to the address area, ie using a call on reference page table entry and having it point directly to a ret instruction. Unlocking is then achieved by changing the mapping to alias.
  • Locked entries differ only in the type of translate entries. Changes between the two therefore only require the types of the corresponding cache and TLB entries (for larger objects, a TLB flush is probably more efficient) to be changed consistently, but no change in the virtual ⁇ real mapping. There are two further instructions for switching between locked and translate:
  • Lock sets the addressed page table entry to locked and unlock back to translate, provided the target entry exists and is accessible from the current mode (user / kernel) and is already of the translate or locked type. In all other cases, page fault is triggered.
  • the method can also be used for coding variable long bit strings up to the maximum length n-1, for example for the guards of the guarded page tables. If there is a bit string b of length
  • the decoding hardware takes the least significant 1-bit occurring as a separator from the bit string (or the base address) b.
  • bit string or the base address
  • FIGS. 15 to 17 briefly describe possible hardware implementations of an MMU translator working according to the invention.
  • TLB 0 and TLB X are present as independent hardware. Instead of the cache (see right part of FIG. 15), a normal memory could of course also be connected directly. If a virtually addressable cache is used, it can take over the functionality of TLB 0 , as shown in FIG. 16 is. The block diagram becomes even simpler if the TLBi is implemented by the translator, as described above in connection with FIG. 9, by means of cache + TLB 0 . The block diagram according to FIG. 17 then results.

Abstract

Mit dem Verfahren lassen sich einfach und schnell virtuelle Adressen eines großen feingranularen und spärlich besetzten Adressraums in Realadressen umsetzen. Die Umsetzung erfolgt in mehreren Stufen, wobei der Verweis von Stufe zu Stufe durch eine zusätzlich gespeicherte Information gesteuert ist. Aufgrund dieser Information, dem sogenannten Guard, kann von der üblicherweise starren Stufeneinteilung abgerückt werden. Es ist möglich, daß infolge des Guards einzelne Stufen übersprungen werden, was zu einer Abkürzung des Umsetzverfahrens durch Überspringen bzw. Auslassen von Zwischenstufen führt.

Description

VERFAHREN ZUM UMSETZEN EINER VIRTUELLEN SPEICHERADRESSE MIT EINER ERSTEN LANGE IN EINE REALADRESSE MIT EINER ZWEITEN LANGE
Die Erfindung betrifft ein Verfahren zum Abbilden eines ersten Bitstrings mit einer ersten Länge auf einen zwei¬ ten Bitstring mit einer zweiten Länge.
Ein solches Verfahren ist insbesondere einsetzbar, wenn es darum geht, bei Rechnern mit virtuellen Speichern in der sogenannten MMU (Memory Management Unit) die Adresse des virtuellen Speichers in die Adresse des Realspeichers umzusetzen.
Die Adressenumsetzung virtuell → real erfolgt herkömmlich in einem mehrstufigen Verfahren, bei dem sogenannte Page Tables eingesetzt werden. Mittels der ersten Bits einer virtuellen Adresse wird eine erste Tabelle adressiert und der unter dieser Tabellenadresse gespeicherte Wert ausge¬ lesen. Der ausgelesene Wert ist die Anfangsadresse einer zweiten Tabelle, die durch die nächste Gruppe von Bits der virtuellen Adresse adressiert wird. Da die Gruppen jeweils eine im vorhinein feste und von Gruppe zu Gruppe konstante Anzahl von Bits umfaßt, läuft das bekannte Verfahren in mehreren Stufen ab, bis man schließlich mit der letzten Tabelle auf der Datenspeicherseite, nämlich dem Realspeicher, angelangt ist. Die letzte Tabelle gibt die Datenseite (auch Kachel genannt) an. Die verbleibende Bitgruppe (letzten Bits der virtuellen Adresse) repräsen¬ tiert dann die Adresse (Offset) innerhalb der Datenseite. Dieses Verfahren ist daten- und zeitintensiv, und zwar insbesondere dann, wenn man sich Adressräume von 264 Byte vorstellt, die spärlich besetzt und/oder feingranular sind. Ferner sind bei bekannten Verfahren Variationen der Größe der Datenseiten nur recht eingeschränkt möglich, z.B. 4 MB und 4 KB große Datenseiten gleichzeitig reali¬ sierbar. Dies ist aber oftmals nicht ausreichend, da es wünschenswert und notwendig sein kann, daß viele unter¬ schiedlich große Datenseiten vorgesehen werden können.
DurchmoderneBetriebssystementwicklungen (beispielsweise Mach, L3) , die Ideen der Objektorientierung mit vielen kleinen Objekten und insbesondere durch das Aufkommen von Prozessoren mit großen Adressräumen (64-bit Adressen) werden wesentliche Defizite der bisher verfügbaren MMUs deutlich. Zu diesen Defiziten zählen die zu grobe und zu uniforme Granularität für große Adressräume, der immense Aufwand für spärlich belegte Adressräume (264-Byte Adressräume sind immer spärlich belegt) und die mangelnde Unterstützung hierarchischer Strukturen. Für derart große Adressräume werden hochauflösende MMUs benötigt. Hochauf¬ lösende MMUs müssen 64-bit oder noch breitere virtuelle Adressen verarbeiten können (denkbar sind 128-bit Adres¬ sen sowie noch breitere Adressen) , Seitengrößen ab 8 Byte (8, 16, 32, ..., 1K, 2K, 4K, ...) verwalten können, wobei diese Seitengrößen im Adressraum mischbar sein sollen und hochauflösende MMUs sollen bei beliebiger Belegung des Adressraums maximal 16 bis 32 Bytes (je nach Größe des virtuellen und des realenAdressraumes) Verwaltungsinfor¬ mation pro allokierter Seite benötigen.
Wie bereits oben erwähnt, werden bisher virtuelle Adres¬ sen schrittweise anhand eines Baums von einzelnen Page Tables (den einzelnen Tabellen) in Realadressen umge¬ setzt. Anhand von Fig. 18 soll nachfolgend ein einzelner Umsetzschritt einer virtuellen (Binär-)Adresse v für eine Aktion x anhand einer Page Table mit der Adresse p nach dem herkömmlichen Verfahren betrachtet werden. Dazu wird v in einen höherwertigen Teil u (bestehend aus einer bestimmten Anzahl der höherwertigen Bits) und einem niederwertigen Teil V (bestehend aus den niederwertigen Bits) aufgespaltet. Mittels u wird dann ein Eintrag der durch p anfangsadressierten Page Table ausgewählt. Dieser Eintrag beinhaltet ein Accessattribut a und eine neue Adresse p' als Anfangsadresse für die nächste Tabelle bzw. den nächsten Page Table des Baums. Bei vielen Rech¬ nern setzen sich die Aktionen aus der Operation read/ write oder auch execute und dem Betriebsmodus user/kernel zusammen. Entsprechend sind die Accessattribute aufge¬ baut, die jeweils gewisse (im Extremfall alle oder keine) Aktionen zulassen. Die Menge und Semantik der konkreten Aktionen und Accessattribute und die Methode der Prüfung "Aktion gegen Attribut" ist aus der Sicht des hier vorge¬ stellten Verfahrens irrelevant. Entscheidend ist nur, daß jeweils aufgrund von Aktion x und Accessattribut a ent¬ schieden wird, ob die Aktion erlaubt ist oder abgebrochen werden muß. Verbietet das Accessattribut die Aktion (x >■ a) , wird die Umsetzung abgebrochen und Page Fault signa¬ lisiert. Ist die Aktion zulässig (x _ a) , gehen x, p' und V als Eingangsparameter in die Umsetzung der nächsten Stufe ein. Man beachte, daß V um die Bitbreite von u kürzer ist als v. Ist die letzte Stufe erreicht, zeigt p' auf den Anfang der Datenseite und V ist der Offset innerhalb der Seite. Bei einer zweistufigen Umsetzung ergibt sich die Situation gemäß Fig. 19. Wenn auf diese Weise 64-bit breite virtuelle Adressen umgesetzt werden sollen und die minimale Seitengröße 16 Bytes betragen soll, kann man das beispielsweise durch eine zehnstufige Umsetzung (4 KB pro Page Table) erreichen. Spärlich be¬ setzte Adressräume erfordern damit allerdings einen untragbaren Verwaltungsaufwand. So können 1024 16-byte- Seiten so allokiert werden, daß pro 16 Datenbytes 20 Kbytes Verwaltungsdaten nötig sind, das sind 0,08 % Nutzdaten. Bei Verwendung einer 60-stufigen Umsetzung (8 Byte pro Page Table) reduziert sich der Verwaltungsauf¬ wand auf das Minimum, 400 Bytes, das sind aber immer noch nur 4 % Nutzdaten. Außerdem dürfte ein 60-stufiger Um¬ setzprozeß viel zu zeitaufwendig sein. Betrachtet man kleinere Adressräume mit beispielsweise 32-bit-breiten Adressen, werden die entsprechenden Werte zwar besser, sind aber immer noch untragbar. So würde eine 14-stufige Umsetzung (16 Byte pro Page Table) im schlechtesten Fall zu nur 8 % Nutzdaten führen.
Bei einem weiteren bekannten Adressumsetzungsverfahren (kurz Inverted Page Tables genannt) besteht jede Tabelle aus einem Eintrag pro Kachel des Realspeichers, der je¬ weils die virtuelle Adresse der zugeordneten Seite des virtuellen Adressraums enthält. Zugegriffen wird mit Hilfe einer Hashfunktion. Das Verfahren ist bildlich in Fig. 20 wiedergegeben. Bei der Umsetzung der virtuellen Adresse v in die Realadresse r wird der niederwertige Teil w direkt übernommen. Der höherwertige Teil u wird durch die Hashfunktion auf einen Wert p abgebildet, der sowohl die vermutliche Kachel im Realspeicher identifi¬ ziert als auch zur Indizierung der invertierten Page Table benutzt wird. Wenn der entsprechende Eintrag die richtige virtuelle Adresse u enthält, liegt ein Treffer vor. Andernfalls (in Fig. 20 nicht dargestellt) müssen vermittels Rehash oder Weiterkettung weitere Kacheln untersucht werden, bis ein Treffer vorliegt oder auf Page Fault entschieden wird. Da bei Inverted Page Tables die Verwaltungsinformation nur von der Größe des Real- speichers (und der Seitengröße) abhängt, aber nicht von der Größe und der Zahl der virtuellen Adressräume, treten keine Platzprobleme auf. Trotzdem machen die drei nach¬ folgenden Einschränkungen die Methode für feingranulare riesige Adressräume wenig brauchbar:
1. Alle Seiten müssen gleich groß sein, d.h. minimale Seitengröße haben. In der Praxis fast immer günsti¬ ger dürfte aber eine Mischung aus kleinen (16 ... 256 Bytes) und mittleren (2 ... 16 Kbytes) sein. Man könnte mehrere Seitengrößen erlauben, indem man für jede Größe eine eigene Hashfunktion und inver¬ tierte Page Table verwendet. Ohne eine feste Auf¬ teilung des Adressraumes müßten dann aber bei jeder Adressumsetzung in der Regel mehrere (im Extremfall alle) sequentiell durchprobiert werden. Aufgrund der Tabellengröße erscheint eine parallele Imple¬ mentierung kaum möglich.
2. Bei kleinen Seiten, großen Realspeichern und riesi¬ gen Adressräumen muß die verwendete Hashfunktion extrem gut sein, um eine ausreichend hohe Treffer¬ rate zu gewährleisten. Wahrscheinlich sind Verfah¬ ren wie Universal Hashing nötig, die die Hashfunk¬ tion dynamisch ändern. Der Hardware und Software- overhead dürfte immens sein.
3. Sharing von Seiten oder ganzen Adressraumteilen ist nicht möglich. Die von modernen Betriebssystemen geforderten hierarchischen Operationen (lazy copying, copy on write, mapping, locking) sind nicht mit akzeptabler Effizienz realisierbar.
Aus Kostengründen kann nicht bei jedem Speicherzugriff eines Programms der Page Table Baum parsiert werden. Dieser Overhead wird mit Hilfe eines speziellen Caches für die Adressumsetzung vermieden, eine Translation Lookaside Buffers (sogenannter TLB - nachfolgend auch Abbildungseinheit genannt) . Normalerweise werden mehr als 90 % aller Adressumsetzungen zu Nullkosten durch TLB Treffer erledigt. Nur bei einem TLB Miss werden die Page Tables parsiert. Konventionelle TLBs halten typischer¬ weise 32 bis 128 Einträge, von denen jeder die Adressum¬ setzung einer Seite beschreibt. Sie sind teilweise voll assoziativ, häufig aber nur 4-Wege-assoziativ aufgebaut. Manchmal werden anstatt oder zur Ergänzung dieser TLB's virtuell adressierte Caches benutzt.
Der Erfindung liegt die Aufgabe zugrunde, ein Verfahren zum Abbilden eines ersten Bitstrings mit einer ersten Länge auf einen zweiten Bitstring mit einer zweiten Länge anzugeben, mit dem sich bei reduzierter Anzahl und/oder Größe von Page Tables eine effektive und effiziente Ab¬ bildung eines ersten Bitstrings auf einen zweiten Bit¬ string realisieren läßt und dies insbesondere bei spär¬ lich besetzten (kleine Datenseiten und/ oder Kacheln) großen Adressräumen.
Insbesondere soll eine MMU von ihrer Funktionsweise her beschrieben werden, die mit vertretbarem Speicher- und Zeitaufwand die Realisierung riesiger, spärlich besetzter Adressräume (264 Bytes oder mehr) mit möglichst feiner Granularität erlaubt. Dabei sollen die Vorteile der zuvor beschriebenen baumartigen Page Tables (Sharing von Teil- bäumen, Unterstützung hierarchischer Operationen) erhal¬ ten bleiben. Die Granularität soll nicht uniform sein müssen, d.h. die Seitengröße soll im Adressraum von Stelle zu Stelle variieren können. Dabei sind Seiten stets ausgerichtet, d.h. für die virtuelle Anfangsadresse v einer Seite mit Größe 21 gilt stets v mod 21 = 0. Als noch vertretbarer Speicheraufwand wird für den Extremfall (nur Seiten mit Minimalgröße, zufällig verteilt) eine Verteilung von Nutzdaten zu Verwaltungsinformation (Page Tables) von etwa 1 : 1 angesehen. Das Verhältnis sollte mit zunehmender Seitengröße drastisch besser werden. Als vertretbarer Zeitaufwand wird ungefähr der Aufwand kon¬ ventioneller MMUs angesehen.
Zur Lösung dieser Aufgabe wird mit der Erfindung ein Verfahren zum Abbilden eines ersten Bitstrings mit einer ersten Länge auf einen zweiten Bitstring mit einer zwei¬ ten Länge vorgeschlagen, bei dem a) ein erster Speicherbereich mit einer ersten An¬ fangsadresse (p) und einer ersten Länge vorgegeben wird, b) geprüft wird, ob die Länge des ersten Speicherbe¬ reichs kleiner oder gleich 2 potenziert mit der Länge des ersten Bitstrings (v) ist und, wenn dies der Fall ist, die Summe aus der ersten Anfangs- adresse (p) des ersten Speicherbereichs und dem ersten Bitstring (v) den zweiten Bitstring ergibt (Datenseite erreicht) , und, wenn die obige Prüfung negativ ist, der erste Speicherbereich als eine erste Tabelle genommen wird und c) aus dem ersten Bitstring (v) Bits (u) an be¬ stimmten Stellen ausgewählt werden, wobei die nicht-ausgewählten verbleibenden Bits einen Restbitstring (w,v') bilden, d) die ausgewählten Bits (u) des ersten Bitstrings (v) einen Eintrag der ersten Tabelle bestimmen, e) dieser Eintrag der ersten Tabelle ausgelesen wird, f) aus dem ausgelesenen Tabelleneintrag die An¬ f ngsadresse (p' ) sowie Länge eines weiteren Speicherbereichs und eine eine Anzahl von Bits umfassende Bitfolge (g) abgeleitet werden, g) aus dem Restbitstring (w,v') eine Anzahl von Bits ausgewählt wird, die gleich der Anzahl der Bits der aus dem Tabelleneintrag der ersten Tabelle abgeleiteten Bitfolge (g) ist, h) geprüft wird, ob die ausgewählten Bits des Restbitstrings (w,V) als Folge betrachtet gleich der aus dem Tabelleneintrag der ersten Tabelle abgeleiteten Bitfolge (g) ist, i) eine Fehlermeldung dergestalt, daß die Abbildung für den ersten Bitstring (v) nicht definiert ist, erzeugt wird, wenn die obige Prüfung nega¬ tiv ist, k) die Bitfolge (g) aus dem Restbitstring (w, v' ) extrahiert wird, wenn die obige Prüfung positiv ist, und
1) das Verfahren ab Schritt b) mit dem nicht-extra¬ hierten verbleibenden Teil (V ) des Restbit- strings (w,v') als erstem Bitstring (v) sowie der Anfangsadresse (p') und Länge des weiteren Speicherbereichs als Anfangsadresse (p) und Länge des ersten Speicherbereichs fortgesetzt wird.
Bei dem erfindungsgemäßen Verfahren wird von einem ersten Bitstring, der beispielsweise eine virtuelle Adresse re¬ präsentiert, ausgegangen und dieser erste Bitstring auf einen zweiten Bitstring abgebildet (umgesetzt, konver¬ tiert o.dgl.), der insbesondere die Realadresse dar¬ stellt. Vorgegeben werden ein erster Speicherbereich, der eine Anfangsadresse und eine Länge aufweist. Läßt sich mit dem ersten Bitstring ein Bereich mit einer größeren Länge als der des ersten Speicherbereichs nicht vollstän¬ dig adressieren, so erhält man den zweiten Bitstring aus der Summe der Anfangsadresse der ersten Tabelle und dem ersten Bitstring, d.h. aus der Summe der durch die An¬ fangsadresse und dem ersten Bitstring jeweils repräsen¬ tierten Zahlen. In diesem Fall ist die Datenseite er¬ reicht.
Der Normalfall wird sein, daß im ersten Umsetzschritt 2 potenziert mit der Länge des ersten Bitstrings größer ist als die Länge des ersten Speicherbereichs. In diesem Fall handelt es sich bei dem ersten Speicherbereich um eine erste Tabelle, die zur Adressumsetzung benutzt wird und deren Anzahl an Einträgen üblicherweise eine Zweier- Potenz ist. Vom ersten Bitstring werden Bits an bestimm- ten Stellen ausgewählt, so daß die Abbildung der ausge¬ wählten Bits auf die Einträge der ersten Tabelle einein¬ deutig ist, d.h. daß die Anzahl der ausgewählten Bits gleich dem Zweier-Logarithmus der Anzahl der Tabellenein¬ träge ist. Die nicht ausgewählten verbleibenden Bits des ersten Bitstrings bilden dann einen Restbitstring. Die ausgewählten Bits des ersten Bitstrings bestimmen den¬ jenigen Eintrag der ersten Tabelle, der ausgelesen werden soll. In diesem Eintrag befinden sich Informationen über die Anfangsadresse und die Länge eines weiteren Speicher¬ bereichs. Ferner ist in diesem Eintrag der Tabelle aber auch eine Bitfolge mit einer bestimmten Bitlänge abge¬ legt. Bei dieser Bitfolge handelt es sich um den später auch mit "Guard" bezeichneten Datenwert. Es wird nun überprüft, ob der Restbitstring z.B. mit dieser Bitfolge beginnt. Ist dies der Fall, so wird eine Fehlermeldung ausgegeben, die besagt, daß die Abbildung nicht definiert ist. Ist die Prüfung hingegen positiv, so wird der Rest¬ bitstring um die Bits der Bitfolge "gekürzt", d.h. in diesem Beispiel werden die führenden Bits abgeschnitten. Dann beginnt das Verfahren von vorn, wobei der verblei¬ bende Teils des Restbitstrings als neuer erster Bitstring und die Anfangsadresse sowie Länge des weiteren Speicher¬ bereichs als Anfangsadresse und Länge des neuen ersten Speicherbereichs genommen werden.
Eine Variante des Verfahrens ist, den Restbitstring vor der Prüfung darauf, ob er den Guard enthält, zu permu¬ tieren und ihn unter Umständen danach (zurück-) zu permutieren.
Der Hauptgedanke der Erfindung spiegelt sich in der Maßnahme wieder, in einer Tabelle neben der Anfangs- adresse für die Tabelle der nächsten Stufe oder die Datenseite einen Wert (Guard genannt) in Form der Bit- folge zu speichern, der angibt, wieviel (und unter Um- ständen welche) Bits von den Restbitfolgen abgetrennt werden, um mit den Anfangsbits des verbleibenden nicht- abgetrennten Teils der Restbitfolgen den nächsten Speicherbereich (Tabelle oder Datenseite) deren Anfangs¬ adresse in dem ausgelesenen Eintrag der vorherigen Tabelle enthalten ist, zu adressieren und den Eintrag der derart spezifizierten Adresse dieser Tabelle auszulesen. Eine Fehlermeldung, daß die Umsetzung nicht definiert oder möglich ist, wird immer dann ausgegebenen, wenn die den Guard darstellende Bitfolge nicht in der Restbitfolge des ersten Bitstrings oder in dem ersten Bitstring selbst enthalten ist. Je länger der Guard ist, umso weniger Um¬ setzungsstufen (Zyklen) sind erforderlich.
Vorteilhafterweise werden die ersten Bits des ersten Bitstrings genommen, um die auszulesende Adresse der ersten Tabelle zu spezifizieren. Vorzugsweise wird auch der Guard mit den ersten Bits der verbleibenden Rest- bitfolge des ersten Bitstrings auf Identität verglichen. Man kann in beiden Fällen auch andere als die ersten Bits verwenden.
Eine vorteilhafte Weiterbildung der Erfindung ist in An¬ spruch 4 angegeben. Hierbei wird die identische Abbildung als Spezialfall einer Permutation betrachtet.
Schließlich ist es von Vorteil, das erfindungsgemäße Ver¬ fahren dahingehend abzuändern, daß pro Umsetzschritt mehrere Guards daraufhin untersucht werden, ob ihre je¬ weilige Bitfolge in dem betreffenden Restbitstring ent¬ halten ist. Diese Weiterbildung ist in Anspruch 5 ange¬ geben. Hierdurch wird eine Beschleunigung der Umsetzung bzw. eine Reduktion der für die Tabellen benötigte Speichergröße erzielt. Wenn man das bisherige erfindungs¬ gemäße Verfahren mit " (einfachen) guarded Page Tables" bezeichnen würde, so würde es sich bei dem Verfahren nach Anspruch 5 um "k-assoziative guarded Page Tables" han¬ deln, wobei k für die Anzahl von pro Umsetzschritt zu vergleichender Guard-Bitfolgen steht.
Die Merkmale weiterer vorteilhafter Ausgestaltungen der Erfindung sind in den übrigen Unteransprüchen angegeben.
Nachfolgend werden anhand der Figuren Ausführungsbei- spiele der Erfindung näher erläutert. Im einzelnen zei¬ gen:
Fig. 1 eine bildliche Darstellung eines Umsetzungs- schritts des erfindungsgemäßen Verfahrens gemäß dem Ausführungsbeispiel als "einfache guarded Page tables",
Fig. 2 ein Beispiel für drei binäre Page Tables mit je zwei Einträgen bei einer 20-bit Adressumsetzung unter Zuhilfenahme des Verfahrens gemäß Fig. 1,
Fig. 3 eine bildliche Darstellung des erfindungsgemäßen Verfahrens gemäß dem Ausführungsbeispiel in der Form mit "K-assoziativen guarded Page Tables",
Fig. 4 das erfindungsgemäße Verfahren in der Ausge¬ staltung mit "k/j-assoziativen guarded Page Tables",
Fig. 5 das Verfahren gemäß Fig. 4, jedoch mit einem abgespeicherten Hinweiselement,
Fig. 6 eine schematische Darstellung für die Verwendung von mehreren sukzessive abzuarbeitenden TLBs (in den Ansprüchen mit Abbildungseinheit bezeichnet) für das "guarded Page Table"-Verfahren, Fig. 7 eine Realisierung für eine Cache mit TLB0-Funk- tion,
Fig. 8 eine erste Alternative einer Realisierung für den in Fig. 6 mit TLBi bezeichneten Baustein,
Fig. 9 eine zweite Alternative für die Realisierung der in Fig. 6 mit TLBX bezeichneten Funktion,
Fig. 10 eine bildliche Darstellung eines Umsetzungs¬ schritts des erfindungsgemäßen Verfahrens gemäß einer weiteren Ausführungsform (User-Level- Mapping) ,
Fig. 11 eine schematische Darstellung eines Teils der Baumstruktur zur Verdeutlichung der Abarbeitung desselben gemäß dem Verfahren nach Fig. 10,
Fig. 12 eine Darstellung des konventionellen "realen" Aliasing zur Verdeutlichung des Unterschieds dieses Verfahrens gegenüber demjenigen nach den Fign. 10 und 11,
Fig. 13 eine bildliche Darstellung eines Umsetzungs- schritts gemäß einem weiteren Ausführungsbei- spiel der Erfindung,
Fig. 14 eine bildliche Darstellung eines Umsetzungs- schrittes, wie er bei einer weiteren Ausfüh¬ rungsform des erfindungsgemäßen Verfahrens ab¬ laufen kann,
Fig. 15 eine erste Alternative einer Hardware-Realisie¬ rung des Translators einer MMU gemäß der Erfin¬ dung, Fig. 16 eine zweite Alternative einer Hardware-Realisie¬ rung des Translators einer MMU gemäß der Erfin¬ dung,
Fig. 17 eine dritte Alternative einer Hardware-Realisie¬ rung des Translators einer MMU gemäß der Erfin¬ dung,
Fig. 18 eine bildliche Darstellung eines Umsetzungs- schrittes bei dem konventionellen Page-Table- Verfahren,
Fig. 19 das konventionelle Page-Table-Verfahren grafisch dargestellt als zweistufiges Verfahren und
Fig. 20 eine bildliche Darstellung eines Umsetzungs¬ schritts bei dem konventionellen Verfahren mit "inverted Page Tables".
Anhand von Fig. 1 wird nachfolgend der Ablauf eines Um¬ setzungsschritts des Verfahrens in der Version mit ein¬ fachen guarded Page Tables erläutert.
Die zentrale Idee der guarded Page Tables ist die Er¬ gänzung jedes Page Table Eintrags um einen Bitstring g mit variabler Länge, der als Guard bezeichnet wird. Zu¬ erst wird bei jedem Umsetzschritt wie bei der konventio¬ nellen Methode durch den höchstwertigen Teil u der vir¬ tuellen Adresse v ein Page Table Eintrag einer Page Table mit der Anfangsadresse p ausgewählt und die Aktion x gegen das Accessattribut a geprüft. Der angewählte Ein¬ trag enthält aber nicht nur Accessattribut und Zeiger (Anfangsadresse) für die nächste Page Table, sondern auch eine weitere Bitfolge, den sogenannten Guard g. Anhand der aktuellen Länge von g wird die restliche virtuelle Adresse in einen höherwertigen Teil w (gleichlang wie g) und niederwertigen Teil v' aufgespalten. Dann wird ge¬ prüft, ob g = w gilt. Bei Ungleichheit wird die Umsetzung mit Page Fault abgebrochen, bei Gleichheit wird sie mit x, p' und v' in der nächsten Stufe fortgesetzt bzw. p' + v' wird von der letzten Stufe als Realadresse geliefert.
Man beachte, daß die Länge der Guards von Eintrag zu Eintrag differieren kann. Ihre aktuelle Länge ist also als Längenfeld oder auf andere Weise geeignet codiert im Page Table Eintrag enthalten. Bei Guards der Länge 0 (G = 0) arbeitet das Verfahren genau wie das konventionelle. Aber immer, wenn konventionell Page Tables mit genau einem belegten Eintrag benötigt würden, kann hier statt¬ dessen ein Guard eingesetzt werden. Ein Guard kann sogar eine Folge solcher Page Tables ersetzen, die nur je einen gültigen Eintrag enthalten. Damit werden sowohl Speicher als auch Umsetzschritte gespart, d.h. Guards wirken als Abkürzung.
Als Beispiel sei in Fig. 2 eine 20-bit Adressumsetzung gezeigt, die drei binäre Page Tables (je zwei Einträge) verwendet. Weiterhin beinhaltet jeder Page Table Eintrag (im mit p bezeichneten Teil) nicht nur den Pointer auf die nächststufige Page Table oder Datenseite, sondern zusätzlich eine Größenangabe s für dieses Objekt. Bei Page Tables bezeichnet s die Zahl der Einträge; zulässig sind alle Zweierpotenzen 1, 2, 4, 8 ... Aus der aktuellen Page Table Größe ergibt sich dann jeweils die Länge von u. Man kann zeigen, daß aufgrund der obigen flexiblen Baumstruktur mit Hilfe der Guards Pate Table Bäume so konstruiert werden können, daß höchsten zwei Page Table Einträge pro Datenseite benötigt werden, und zwar unab¬ hängig von Adressraumgröße und Seitengröße.
Zusammen mit den variabel großen Datenseiten sollten da¬ mit fast immer mehr als 50 % Nutzdaten erreichbar sein. Bei 8 Bytes pro Page Table Eintrag lassen sich Guards bis 30-bit Länge verwenden. Dann sind bei 32-bit Adressen maximal 16 Bytes Verwaltungsinformation pro Seite nötig. Bei 64-bit Adressen können in manchen Fällen längere Guards nötig werden, die dann durch einen zusätzlichen Eintrag ä 8 Bytes realisiert werden. Im worst case (nie mehr als eine Seite pro 231 Bytes und nur 16-Byte-Seiten) sind dann 40 % der Daten Nutzdaten.
Wie man ebenfalls zeigen kann, können weiterhin die Adressumsetzungsbäume so konstruiert werden, daß höchsten n/2 Stufen für einen n-bit Adressumsetzung nötig sind, wobei der oben aufgeführte Speicherbedarf nicht über¬ schritten wird. Bei 64-bit Adressen sind somit maximal 30 Stufen, bei 32-bit Adressen 14 Stufen nötig, um 16-Byte- Seiten zu erreichen.
Einen Umsetzschritt für das Verfahren mit k-assoziativen guarded Page Tables zeigt Fig. 3. Bei k-assoziativen guarded Page Tables wird in jedem Schritt nicht ein Page Table Eintrag ausgewählt, sondern gleich k Stück. Für höchstmögliche Geschwindigkeit braucht man also k paral¬ lele Werke und parallele Datenpfade für k Page Table Einträge. Die Page Table besteht jetzt nicht mehr aus s einfachen Einträgen, sondern aus s/k Clustern, die aus je k einfachen Einträgen bestehen, u ist entsprechend kürzer und wählt einen Cluster aus. Ist bei einer Page Table k > s, wird k für diesen Umsetzschritt gekür t, d.h. nur s- assoziativ gearbeitet. Bei k = 4 ergibt sicn die in Fig. 3 dargestellte Situation. Hier werden die vier angewähl¬ ten Einträge parallel gelesen und (parallel) ausgewertet. Man beachte, daß sich die Guards gi normalerweise hin¬ sichtlich ihrer Längen unterschieden, d.h. für die ver¬ schiedenen Vergleiche wird der um u gekürzte Bitstring in verschiedene Paare wif vA' aufgeteilt. Falls kein Treffer auftritt (alle gi = w , wird die Umsetzung mit Page Fault abgebrochen. Bei genau einem Treffer g__ = i wird das Accessattribut at gegen die Aktion x geprüft, und im Gültigkeitsfall werden x, pA und vA' an die nächste Stufe weitergereicht bzw. als Realadresse geliefert. Bei mehre¬ ren Treffern ist das Resultat nicht definiert. Wie man zeigen kann, erlauben 8-assoziative guarded Page Tables n-bit Adressumsetzung in maximal n/4 Schritten bei höch¬ sten zwei (einfachen) Einträgen pro Datenseite. Bei 64- bit Adressen sind somit maximal 15 Stufen, bei 32-bit Adressen 7 Stufen nötig, um 16-Byte-Seiten zu erreichen.
Fig. 4 zeigt ein Beispiel für einen Umsetzschritt bei dem Verfahren mit k/j-assoziativen guarded Page Tables. k/j- assoziative guarded Page Tables haben dieselbe Semantik wie k-assoziative. Sie benötigen aber nur k/j-fache Parallelität zur Realisierung. Für höchstmögliche Ge¬ schwindigkeit braucht man also nur k/j parallele Werke und parallele Datenpfade für k/j Einträge. (Dabei sollte k durch j ohne Rest teilbar sein. Außerdem sollten beides Zweierpotenzen sein.) Das k Einträge umfassende Cluster wird in j (gleichgroße und zusammenhängende) Teilcluster (Teilbereiche) aufgeteilt. Ist bei einer Page Table k > s, wird k für diesen Umsetzschritt auf s gekürzt. Ist s ≤ k/j, wird s-assoziativ gearbeitet, sonst s/j ' -assozia¬ tiv, wobei j' so gewählt wird, daß die Länge der Teil¬ cluster unverändert bleibt, d.h. k/j = a/j ' . Das bereitet keine Probleme, wenn s, k und j Zweierpotenzen sind. Um die Semantik der k-Assoziativität zu erhalten, wird die Umsetzoperation dann sequentiell (k/j-parallel) auf ver¬ schiedenen Teilclustern durchgeführt, bis entweder ein Treffer entsteht oder alle j Teilcluster abgearbeitet sind. Wird kein Treffer gefunden, wird die Adressum¬ setzung mit Page Fault abgebrochen, bei einem Treffer wird wie in anhand von Fig. 3 beschrieben verfahren. Diese Methode ist offensichtlich nur effizient, wenn mögliche Treffer häufig schon beim ersten Versuch gefun- den werden. Um einen Hinweis zu erhalten, werden nach dem Entfernen von u die höchstwertigen log2 (k) Bits der verbleibenden virtuellen Adresse als Hinweis h genommen (diese werden aber weiterhin zur Bildung von Wi verwen¬ det) . Bei einfachen k/j-assoziativen guarded Page Tables wird mit dem durch h/j adressierten Teilcluster begonnen. Die weitere Reihenfolge kann dann durch Inkrementieren von h/j modulo j bestimmt werden. Andere Reihenfolgen sind genauso möglich, z.B. von 0 bis j - 1 bei Auslassung von h/j. Sie spielen für die Effizienz keine Rolle.
Bei k/j-assoziativen guarded Page Tables mit Hinweis ist jedes p (sowohl in Page Table Einträgen als auch im Root oder in TLB's) um ein Feld H mit k Hinweiselementen er¬ gänzt (dieses ist mit k log2 (j) Bits relativ klein). Dann wird in jedem Schritt mit dem durch p.H[h] = h' adressierten Teilcluster begonnen. Wird ein Treffer nicht in dem durch h' adressierten Teilcluster erzielt, sondern in einem anderen der Nummer h", wird das Hinweiselement neu geladen: p.H[h] := h" . Somit justieren sich Hinweise automatisch.
Man kann zeigen, daß 8/2-assoziative guarded Page Tables mit Hinweisen n-bit Adressumsetzung in maximal n/4 Schritten bei höchsten 2 2/7 Einträgen pro Datenseite erlauben. Sie benötigen dazu im wesentlichen dieselbe Zeit wie 8-assoziative, benötigen aber nur 4 statt 8 parallele Werke und entsprechend schmalere Datenpfade.
Um ausreichend schnelle Adressumsetzung zu erzielen, müssen auch guarded Page Table Translatoren durch TLB's unterstützt werden. Spezielle Probleme sind hierbei die unterschiedliche Seitengrößen, größere Working Sets (wegen der kleineren Granularität mehr Seiten) und tie¬ fere Bäume bei riesigen Adressräumen (Tiefe 15 bei 60-bit Adressumsetzung), d.h. höhere Kosten bei TLB-miss. Zur Lösung wird ein mehrstufiger TLB eingesetzt, wie er in Fig. 6 dargestellt ist.
TLB0 ist ein mehr oder minder konventioneller TLB auf Seitenbasis oder ein auch virtuell adressierbarer Cache; ein Treffer ergibt direkt die entsprechende Realadresse. TLBX operiert.auf größeren Regionen (z.B. 16 MB), so daß bei einem 'near miss' (TLB0-miss und TLB1-Treffer) ein Quereinstieg in den Page Table Baum möglich wird und nur ein kleiner Teil des Baumes passiert zu werden braucht. Dieses Verfahren läßt sich bei Bedarf auf natürliche Weise um weitere TLBx-Stufen erweitern.
Wesentliches Problem des in Fig. 6 dargestellten TLB0 sind die unterschiedlich großen Seiten. Bekannte Lösung für einvoll-assoziativer TLB (wie z.B-. beim MIPS R4000) , was einen hohen Schaltungsaufwand zur Folge hat, oder ein virtuell adressierter Cache, der zwar schneller als ein real adressierter Cache ist, jedoch Schwierigkeiten bei Synonymen und Konsistenzprobleme bei Multiprozessoren verursacht.
Eine weitere Lösung ist ein virtuell und real adressier¬ barer Cache, der die Vorteile eines virtuell adressierten (TLB für kleine, viele und unterschiedlich große Seiten) und eines real adressierten Caches (Synonyme möglich, ge¬ eignet für Multiprozessorsysteme) vereint. Dies zeigt Fig. 7. Hier enthält das Feld ä jeweils das End-Access- attribut, was durch Kombination der Accessattribute der einzelnen Stufen bei der Adressumsetzung entsteht.
Wie für den TLB0 sind für den TLBX und (und für höhere Stufen) mehrere Lösungen möglich. Eine ist in Fig. 8 gezeigt. So kann z.B. ein spezieller Cache (direct mapped oder n-fach assoziativ) für die einzelnen Regionen ver¬ wendet werden. Er wird mit der Region (z.B. v - 224) adressiert und liefert bei einem Treffer den nächstmög¬ lichen Einstieg in den Page Table Baum. Das sind die Adresse des entsprechenden Page Table Eintrags und seine Tiefe, d.i. die Anzahl führender Bits der virtuellen Adresse, die bis zu diesem Eintrag schon dekodiert sind (man beachte, daß der Eintrag nicht unbedingt auf der "Regionstiefe" sein muß, sondern aufgrund der Guards auch höher angesiedelt sein kann) und deshalb beim Querein¬ stieg in den Adressumsetzbaum von der virtuellen Adresse v die führenden Bits entfernt werden müssen, ä enthält hier die Accessattribute, die durch Kombination der Page Table Accessattribute bei der Adressumsetzung bis zur Region entstanden sind. Bei TLBi-hit und erlaubter Aktion (x <_ ä) wird gemäß des erfindungsgemäßen Verfahrens die Adressumsetzung schrittweise durchgeführt. Dabei wird mit v' als virtueller Adresse und p' als Adresse einer Page Table mit nur einem Eintrag begonnen (da TLBX nicht die Page Table sondern schon den entsprechenden Page Table Eintrag liefert) . Bei TLB^miss wird eine vollständige Adressumsetzung nach dem erfindungsgemäßen Verfahren durchgeführt. Der dabei gefundene bestmögliche Einstieg in die Region wird dann in den TLBi-Cache aufgenommen.
Eine weitere Alternative für den TLBX gemäß Fig. 6 ist im oberen Teil von Fig. 9 gezeigt. Bei Verwendung eines aus¬ reichend großen TLB0 respektive eines auch virtuell adressierbaren Datencaches kann auf einen speziellen Cache für TLBX verzichtet werden. Stattdessen kann eine zwei- (oder mehr-) stufige Hierarchie von Adressumsetz- bäumen benutzt werden. Linearisiert sieht der Adressraum dann z.B. wie im unteren Teil von Fig. 9 gezeigt aus.
Für jede Region wird ein eigener Baum verwendet. Die Wurzeln dieser Bäume sind über einen speziellen Bereich im virtuellen Adressraum ('region roots' ) erreichbar. Bei einem TLB0-miss wird nun versucht, den entsprechenden Regionalbaum über seine virtuelle Adresse im Bereich 'region roots' anzusprechen. Gelingt das vermittels TLB0- hit bei der entsprechenden virtuellen region-root-Adres¬ se, liegt ein TLBi-hit vor. Dann braucht nur der (nicht sehr tiefe) Regionalbaum parsiert zu werden. Andernfalls wird beginnend bei 'root' eine vollständige Adressum- setzung der virtuellen region-root-Adresse durchgeführt und danach der Regionalbaum parsiert. Diese Methode benötigt weniger Hardware, kann aber im Extremfall (nur eine Seite pro Region) pro erreichbarer Seite einen zusätzlichen Page Table Eintrag erfordern. Ist die klein¬ ste Seite größer als ein Page Table Eintrag, kann der zusätzliche Speicherbedarf aufgrund Fragmentierung des 'region root' Bereiches entsprechend steigen.
Im folgenden soll auf eine weitere Besonderheit einge¬ gangen werden, die insbesondere bei feingranularem Mapping bei großen Adressräumen, die spärlich besetzt sind.
Feingranulares Mapping ermöglicht Zugriffskontrolle auf der Ebene von logischen Speicherobjekten (Programmvariab¬ len) . Damit kann es sowohl im Bereich der klassischen imperativen Programmiersprachen, als auch in objektorien¬ tierten und deklarativen Sprachen sinnvoll eingesetzt werden, insbesondere bei verteilten oder massiv-paral¬ lelen Systemen. Typische Anwendungen sind:
1. Aliasing
Abbildung eines virtuellen Speicherobjekts auf ein anderes virtuelles Speicherobjekt. Das kann bei¬ spielsweise zur Objektsynthese eingesetzt werden, aber auch zur Konstruktion alternativer Sichten oder einfach zur Parameterübergabe. 2. Call On Reference
Aufruf einer benutzerdefinierten Prozedur bei Zu¬ griff. Damit kann spezielle Zugriffssemantik an Speicherbereiche gekoppelt werden, beispielsweise 'Verzögerung beim Lesezugriff' (Wert der Variablen ist noch nicht berechnet), 'Signal beim Schreibzu¬ griff', 'Remote Object Invocation' , 'Stellvertre¬ terzugriff' oder einfach 'Zugriffsprotokoll'.
Die Kopplung beider Methoden erlaubt effiziente Reali¬ sierung verteilter Speicher, da auf potentiell entfernte Objekte mit den Methoden der Local Object Invocation zugegriffen werden kann. Die Speicherzugriffe werden dann im aktuell lokalen Fall direkt durchgeführt, im aktuell entfernten algorithmisch. Die Unterscheidung geschieht durch Hardware. Funktional läßt sich das alles durch das Betriebssystem (μ-Kern) in Software realisieren. Da aber bei den erwähnten Methoden sehr häufige Änderungen des Mappings zu erwarten sind, ist aus Effizienzgründen eine direkte Änderungsmöglichkeit des Mappings durch das (User Leve- Programm ohne Einschaltung des Betriebssystems wünschenswert. Diese Möglichkeit darf nicht gegen das Sicherheitsparadigma des Betriebssystems verstoßen.
User-Level-Mapping ist, wie oben erwähnt, besonders interessant, wenn die MMU feingranulare Adressräume zuläßt. Das im folgenden zu beschreibende Verfahren läßt sich aber genauso in andere insbesondere fein- oder grobgranular abbildende MMUs einbauen. Diese MMUs sollten vorzugsweise darauf basieren, eine virtuelle Adresse anhand eines Page Table Baums in eine Realadresse umzu¬ setzen. Dies ist aber nicht zwingend erforderlich. Page Table Einträge bestehen konventionell aus einem Access- attribut a, das die gültigen Aktionen auf dem Speicher¬ bereich bestimmt, und einem Zeiger τ, der bei der nor- malen Adressumsetzung die Realadresse p der nächststufi¬ gen Page Table Stufe oder der Datenseite ist. Jetzt hat jeder Page Table Eintrag außerdem einen Typ T, der unter anderem die Interpretation des Zeigers τ bestimmt. Die konventionellen Einträge haben den Typ T = translate. Für User Level Mapping werden neue Typen und Spezialinstruk- tionen zur sicheren Änderung des Mappings eingeführt. Beim Typ alias wird der Zeiger it als virtuelle Alias- adresse v interpretiert. Trifft die Adressumsetzung auf irgendeiner Stufe auf einen alias-Eintrag, dessen Access- attribut a die Zugriffsaktion x erlaubt, wird v zu der noch nicht dekodierten Restadresse v' addiert oder die neue Adresse anderweitig aus v und V gebildet. Diese Situation ist in Fig. 10 für einen Umsetzschritt gezeigt.
Mit dem Ergebnis, einer virtuellen Adresse voller Länge (z.B. v* + v') beginnt die Adressumsetzung erneut. Somit wird der gesamte virtuelle Bereich, der durch den Alias- Eintrag abgedeckt wird, virtuell auf einen anderen vir¬ tuellen Bereich abgebildet (siehe hierzu die schemati¬ sierte Darstellung einer Baumstruktur gemäß Fig. 11) . Dieses Verfahren ist von dem konventionellen realen Aliasing, bei dem mehrere Realzeiger auf einer Page Table oder Datenseite zusammenlaufen, zu unterscheiden. Das konventionelle reale Aliasing ist in Fig. 12 schematisch dargestellt. Virtuelles Aliasing ist im Gegensatz zu realem Aliasing von Realspeicherzuordnungen unabhängig. Damit ermöglicht es Veränderungen des Mappings durch User Level Software, und zwar unabhängig von aktueller Real- speicherbelegung und Paging, ohne die Schutzgrenzen des eigenen oder fremder Adressräume unterlaufen zu können, und ohne die durch das Betriebssystem vorgegebenen Accessattribute auf Seiten oder größeren Adressraumteilen aufweichen zu können. Beim Typ τ = call on reference wird der Zeiger TΓ als virtuelle Adresse v einer Prozedur interpretiert. Trifft die Adressumsetzung auf einen call on reference-Eintrag, dessen Accessattribut a die Zugriffsaktion x erlaubt, wird die zugreifende Operation abgebrochen und stattdes¬ sen die angegebene Prozedur aufgerufen. Sie erhält den aktuellen Instruction Counter (ic) und die verursachende virtuelle Adresse vorig als Eingangsparameter. Wie bei einem Page Fault kann die auslösende Instruktion neu gestartet werden. Fig. 13 zeigt einen Umsetzschritt mit dem Typ T = call on reference.
call on reference-Mapping ordnet Adressraumbereichen Algorithmen zu. Diese können die verursachende Instruk¬ tion beispielsweise überspringen, emulieren oder ähnlich wie einen Page Fault behandeln: den fraglichen Speicher¬ bereich per alias neu abbilden und die Instruktion neu starten, Skipping und Emulation von einzelnen Instruktio¬ nen kann unter Umständen durch Spezialinstruktionen des Prozessors beschleunigt werden (siehe weiter unten unter den ergänzenden Instruktionen "getmap", "getlength" und "execute") .
Bei Prozessoren mit strikter Load/Store-Architektur kann die Emulation beschleunigt werden, indem die assoziierte Prozedur nicht nur ic und vorig als Parameter erhält, sondern zusätzlich - beim Schreibzugriff - die Kennung 'Schreibzugriff', die Operandenlänge (Byte, Wort, ...) und den Operandenwert, - beim Lesezugriff - die Kennung 'Lesezugriff', die Operandenlänge (Byte, Wort, ...) und die Nummer (Adresse) des Zielregisters. Bei Prozessoren mit komplexeren Instruktionen können stattdessen als zusätzliche Parameter die Operation (Mov, Add, Ine, ... ) , die Operandenlänge (Byte, Wort, ...), die Register/ Speicheradresse der Quelle und die Register/Speicher¬ adresse des Ziels übergeben werden. Der Instruktionssatz des Prozessors wird um die nicht- privilegierte Instruktion 'map' erweitert. Damit kann User Level Software direkt alias- und call on reference- Einträge verändern. Ein Page Table Eintrag wird eindeutig durch den virtuellen Adressbereich bezeichnet (dies gilt nicht umgekehrt, da aufgrund von Realsharing ein Eintrag für mehrere virtuelle Adressraumbereiche zuständig sein kann) , den er in der primären Adressumsetzung genau überdeckt. Unter primärer Adressumsetzung wird hier der Übersetzungsvorgang verstanden, der die originale vir¬ tuelle Adresse umsetzt, bis entweder ein Page Fault diagnostiziert wird, ein alias-, call on reference- oder ein auf eine Datenseite verweisender Eintrag gefunden wird. Dementsprechend wird der adressierte Eintrag durch virtuelle Basisadresse b und Größe s des zugehörigen Adressraumbereichs spezifiziert. Dann lädt die Instruk¬ tion
Figure imgf000026_0001
den adressierten Page Table Eintrag mit r und TT, vor¬ ausgesetzt T ist alias oder call on reference (virtuell- real Abbildungen können somit nicht definiert oder verän¬ dert werden) und der Zieleintrag existiert (Einträge können somit nicht heimlich erzeugt werden) und ist vom aktuellen Modus (user/kernel) aus zugreifbar (das Be¬ triebssystem kann sich somit schützen) und hat bereits den Typ alias oder call on reference. Überlagern eines translate-Eintrags im Benutzerteil des Adressraumes durch alias oder call on reference ist zwar nicht sicherheits- kritisch, würde aber zu toten Teilbäumen führen, ohne daß das Betriebssystem das bemerkt. Andernfalls führt map zu Page Fault. Damit können von Unser Level Software ent¬ sprechende Einträge modifizieren, d.h. zwischen alias und call on reference wechseln und die Alias- bzw. assoziier¬ te Prozeduradresse ändern. Mit dieser Instruktion können aber weder neue Einträge erzeugt, noch vorhandene vir¬ tuell-real Abbildungen modifiziert, noch vorhandene Accessattribute aufgeweicht werden.
Das Einrichten und Löschen entsprechender Einträge samt notwendiger Modifikation des Page Table Baums sollte durch System Calls im Betriebssystemkern realisiert werden. Alias- und call on reference-Einträge können vom Betriebssystem als langlebige Objekte realisiert werden, da verdrängte Einträge sowohl bei normalem Zugriff auf den Adressbereich als auch bei map Zugriff auf den Ein¬ trag zu Page Fault führen. Weitere Prozessorinstruktionen sind nicht notwendig, könnten aber für bestimmte Prozes¬ soren und Anwendungen unter Umständen interessant sein:
get ap ((b,s), (τ,a,7r)
liest einen existierenden Page Table Eintrag, der vom aktuellen Modus aus zugreifbar und vom Typ alias oder call on reference sein muß. Skipping und Emulation durch eine mit dem Adressbereich assoziierte Prozedur kann unter Umständen durch Instruktionen effizienter werden, die die Länge einer anderen Instruktion liefern oder diese mit einer modifizierten Speicheradresse ausführen können:
getlength (dest, ptr)
liefert die Länge der Instruktion, die an der virtuellen Adresse 'ptr' steht, in 'dest' .
execute (ptr, v)
führt die an der virtuellen Adresse 'ptr' stehende In¬ struktion aus, wobei allerdings anstelle der eigentlich in der Instruktion verwandten Speicheradresse die vir- tuelle Adresse v verwendet wird. Bei Mehradressmaschinen sind unter Umständen komplexere Formen der Instruktion notwendig. Beide Instruktionen lohnen sich nicht bei Prozessorarchitekturen, die nur wenige und einfache Befehlsformate und Adressierungsmodi haben. Prinzipiell reichen die Eintragstypen alias und call on reference (neben translate) aus. Unter Umständen können auch Kombi¬ nationen interessant sein:
T = call on write / alias on read T = call on read / alias on write.
Hierfür müssen allerdings die Page Table Einträge ver¬ größert werden, so daß sie v und v aufnehmen können, oder aber v ist für alle Einträge fest. Die map-Instruktion arbeitet dann natürlich auch auf diesen beiden Typen.
Zum Ankoppeln bestimmter Hardware-Aktionen an Adressbe¬ reiche, z.B. Anstoßen komplexer Busprotokolle zum Zugriff auf entfernten Speicher, können weitere (Spezial-)Typen für T eingesetzt werden.
Bei Multiprozessor-Maschinen mit Shared Memory soll manchmal ein Adressbereich gesperrt werden, so daß Zu¬ griffe darauf durch andere Prozessoren automatisch bis zur Freigabe verzögert werden. Natürlich muß der Zugriff wenigstens einem Prozessor gestattet sein. Das kann man unter anderem durch virtuelles oder reales Aliasing er¬ reichen. Locking kann man durch Ankoppeln einer leeren Routine an den Adressbereich bewirken, d.h. man verwendet einen call on reference Page Table Eintrag und läßt die¬ sen direkt auf eine ret-Instruktion zeigen. Unlockung wird dann durch Änderung des Mappings auf alias erreicht. Bei manchen Architekturen mag sich dafür ein spezieller neuer Typ T = locked lohnen, der unter Umständen etwas effizienter implementiert werden kann, da er lock/unlock ohne Uminterpretationen in Cache und TLB erlaubt. Diese Situation ist in Fig. 14 wiedergegeben. Trifft die Adressumsetzung auf einen solchen Eintrag, wird sie komplett neu gestartet. Erst wenn ein anderer Prozessor den Eintrag wieder auf translate setzt oder den Page Table Baum so modifiziert, daß der Eintrag nicht mehr involviert ist, wird die Verzögerung beendet. Locked- Einträge unterscheiden sich nur im Typ von translate- Einträgen. Wechsel zwischen beiden erfordern deshalb nur, die Typen der entsprechenden Cache- und TLB Einträge (bei größeren Objekten ist ein TLB-Flush wahrscheinlich effi¬ zienter) konsistent zu ändern, aber keine Änderung der virtuell → real-Abbildung. Zum Wechsel zwischen locked und translate dienen zwei weitere Instruktionen:
lock (b,s) unlock (b,s).
Lock setzt den adressierten Page Table Eintrag auf locked und unlock wieder auf translate, vorausgesetzt der Ziel- eintrag existiert und ist vom aktuellen Modus (user/ kernel) aus zugreifbar und hat bereits den Typ translate oder locked. In allen anderen Fällen wird Page Fault ausgelöst.
Zur Codierung der obigen Instruktionen und/oder flexibel langer Bitstrings und -folgen (also auch Guards) stehen z.B. folgende Möglichkeiten zur Verfügung.
Paare (b,s) von n-bit-breiter Basisadresse b und Größen¬ angabe s = 21 können als n-bit-Wert
b + 4 für s ≥ 2 codiert werden, wenn die Basisadresse immer s- ausgerichtet ist, d.h. b mod s = 0. Die Bitrepräsentation sieht dann folgendermaßen aus:
bb, .bblOO 00
Das Verfahren kann genauso zur Codierung variabler langer Bitstrings bis zur Maximallänge n-1 benutzt werden, bei¬ spielsweise für die Guards der guarded Page Tables. Liegt ein Bitstring b der Länge |b|| vor, wird er als n-bit-Zahl
2n-IM + 2n""b""*-
dargestellt. Die dekodierende Hardware nimmt in beiden Fällen das niederwertigste auftretende 1-bit als Trenn¬ zeichen zum Bitstring (oder der Basisadresse) b. Natür¬ lich können die Rollen von 0- und 1-Bits vertauscht und unabhängig davon die höchstwertigen Bits genommen werden:
bb, .bbOll 11
00, OOlbb bb
Nachfolgend werden anhand der Fign. 15 bis 17 noch kurz mögliche Hardware-Realisierungen eines nach der Erfindung arbeitenden Translators einer MMU beschrieben.
Gemäß Fig. 15 sind TLB0 und TLBX als eigenständige Hard¬ ware vorhanden. Anstelle des Cache (siehe rechter Teil von Fig. 15) könnte natürlich auch direkt ein normaler Speicher angeschlossen werden. Wenn ein virtuell adres- sierbarer Cache eingesetzt wird, kann dieser die Funktio¬ nalität des TLB0 übernehmen, wie dies in Fig. 16 gezeigt ist. Noch einfacher wird das Blockschaltbild, wenn der TLBi vom Translator, wie weiter oben im Zusammenhang mit der Fig. 9 beschrieben, vermittels Cache + TLB0 reali¬ siert wird. Dann ergibt sich das Blockschaltbild gemäß Fig. 17.

Claims

ANSPRÜCHE
Verfahren zum Abbilden eines ersten Bitstrings mit einer ersten Länge auf einen zweiten Bitstring mit einer zweiten Länge, insbesondere zum Umsetzen einer virtuellen Speicheradresse eines virtuellen Speichers in eine Realadresse eines Realspeichers, bei dem a) ein erster Speicherbereich mit einer ersten An¬ fangsadresse (p) und einer ersten Länge vorge¬ geben wird, b) geprüft wird, ob die Länge des ersten Speicher¬ bereichs kleiner oder gleich 2 potenziert mit der Länge des ersten Bitstrings (v) ist und, wenn dies der Fall ist, die Summe aus der ersten Anfangsadresse (p) des ersten Speicherbereichs und dem ersten Bitstring (v) den zweiten Bit¬ string ergibt (Datenseite erreicht) , und, wenn die obige Prüfung negativ ist, der erste Speicherbereich als eine erste Tabelle genommen wird und c) aus dem ersten Bitstring (v) Bits (u) an be¬ stimmten Stellen ausgewählt werden, wobei die nicht-ausgewählten verbleibenden Bits einen Restbitstring (w,v') bilden, d) die ausgewählten Bits (u) des ersten Bit¬ strings (v) einen Eintrag der ersten Tabelle bestimmen, e) dieser Eintrag der ersten Tabelle ausgelesen wird, f) aus dem ausgelesenen Tabelleneintrag die An¬ fangsadresse (p') sowie Länge eines weiteren Speicherbereichs und eine eine Anzahl von Bits umfassende Bitfolge (g) abgeleitet wer¬ den, g) aus dem Restbitstring (w,v') eine Anzahl von Bits ausgewählt wird, die gleich der Anzahl der Bits der aus dem Tabelleneintrag der ersten Tabelle abgeleiteten Bitfolge (g) ist, h) geprüft wird, ob die ausgewählten Bits des Restbitstrings (w,v') als Folge betrachtet gleich der aus dem Tabelleneintrag der ersten Tabelle abgeleiteten Bitfolge (g) ist, i) eine Fehlermeldung dergestalt, daß die Abbil¬ dung für den ersten Bitstring (v) nicht defi¬ niert ist, erzeugt wird, wenn die obige Prü¬ fung negativ ist, k) die Bitfolge (g) aus dem Restbitstring (w, V ) extrahiert wird, wenn die obige Prüfung positiv ist, und
1) das Verfahren ab Schritt b) mit dem nicht- extrahierten verbleibenden Teil (V ) des Restbitstrings (w,v') als erstem Bitstring (v) sowie der Anfangsadresse (p' ) und Länge des weiteren Speicherbereichs als Anfangs- adresse (p) und Länge des ersten Speicherbe¬ reichs fortgesetzt wird.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß die bei Schritt c) ausgewählten Bits die An¬ fangsbits (u) des ersten Bitstrings (v) sind.
3. Verfahren nach Anspruch 1 oder 2, dadurch gekenn¬ zeichnet, daß bei Schritt f) geprüft wird, ob der Restbitstring (w,v') aus den nicht-ausgewählten Bits des ersten Bitstrings (v) als Anfang (w) die aus dem Tabelleneintrag der ersten Tabelle abgelei¬ tete Bitfolge (g) aufweist, und daß bei Schritt k) der mit der Bitfolge identische Anfang (w) des Restbitstrings (w,v') abgetrennt wird, wenn die Prüfung des Schritts h) positiv ist.
4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, daß vor Schritt g) der Restbit¬ string (w,V) gemäß einer ersten Permutationsregel permutiert wird und daß nach Schritt k) und vor Schritt 1) der verbleibende Teil des permutierten Restbitstrings (w,v') gemäß einer zweiten Permuta¬ tionsregel permutiert wird, bevor mit Schritt b) fortgefahren wird.
5. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, daß bei Schritt d) die ausgewählten Bits des ersten Bitstrings einen Tabellenbereich (Cluster) einer ersten Tabelle bestimmen, bei Schritt e) die Einträge des derart adres¬ sierten Bereichs der ersten Tabelle ausgelesen werden, bei Schritt f) aus den ausgelesenen Einträgen des anfangsadressierten Bereichs der ersten Tabelle die Anfangsadressen (pi' ) sowie Längen mehrerer möglicherweise unterschiedlicher, wei¬ terer Speicherbereiche und mehrerer Bitfolgen (gi) mit möglicherweise unterschiedlichen Bit- längen abgeleitet werden, wobei einer Bitfolge (gi) jeweils eine Anf ngsadresse (p ) und Länge eines weiteren Speicherbereichs zugeordnet sind, Schritte g) und h) für alle ausgelesenen Bitfol¬ gen (gi) insbesondere parallel oder sequentiell durchgeführt werden, eine Fehlermeldung dergestalt, daß die Abbildung für den ersten Bitstring (v) nicht definiert ist, erzeugt wird, wenn alle Prüfungen in Schritt h) negativ sind, und andernfalls diejenige Bitfolge (gA) oder eine derjenigen Bitfolgen (gi) aus dem Restbitstring (w,v') extrahiert wird, für die die Prüfung in Schritt h) positiv ist, sowie die zugeordnete Anfangsadresse und Länge als Anfangsadresse (p±) und Länge des weiteren Speicherbereichs genommen wird.
Verfahren nach Anspruch 5, dadurch gekennzeichnet, daß der Bereich (Cluster) der ersten Tabelle in mehrere Teilbereiche (Teilcluster) unterteilt ist, von denen jeder mindestens einen Eintrag bestehend aus einer Anfangsadresse, einer Länge und einer weiteren Bitfolge aufweist, daß eine Hinweisadresse (h) vorgegeben wird und, daß aus dem durch die ausgewählten Bits des ersten Bitstrings anfangsadressierten Bereich der ersten Tabelle zuerst die Einträge des durch die Hinweisadresse (h) anfangsadressierten Teil¬ bereichs ausgelesen werden.
Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, daß der erste Bitstring (v) sukzessive minde¬ stens einer Abbildungseinrichtung (TLB zuge¬ führt wird, in der Abbildungen des ersten Bit¬ strings (v) auf Anfangsadressen (p) sowie Längen von Speicherbereichen und Kürzungswerte ge¬ speichert sind, und daß in dem Fall, daß eine Abbildung des ersten Bitstrings (v) in der mindestens einen Abbil¬ dungseinheit (TLBi) nicht gespeichert ist, mit Schritt a) , angewendet auf den abzubildenden ersten Bitstring (v) , begonnen wird, während andernfalls das Verfahren mit demjenigen Speicherbereich als erster Tabelle, der durch die sich aus der mindestens einen Abbildungsein¬ heit (TLB ergebenden Anfangsadresse und Länge spezifiziert ist, und mit dem um dem Kürzungs- wert verkürzten ersten Bitstring als neuem ersten Bitstring bei Schritt b) begonnen wird, wobei die Verkürzung insbesondere aus einem Ab¬ scheiden der führenden Bits besteht.
8. Verfahren insbesondere nach einem der Ansprüche 1 bis 7, bei dem der erste Bitstring in den zweiten Bitstring gemäß einem Umsetzverfahren umgesetzt wird, das die folgenden Schritte umfaßt: eine Tabelle mit mindestens einem Tabellen¬ eintrag wird vorgegeben, aus einem Eingangsbitstring werden Bits an bestimmten Stellen ausgewählt, wobei die nicht-ausgewählten verbleibenden Bits einen Restbitstring bilden, die ausgewählten Bits des Eingangsbitstrings bestimmen einen Eintrag der ersten Tabelle, dieser Eintrag der ersten Tabelle wird aus¬ gelesen, in dem Fall, daß der ausgelesene Tabellenein¬ trag vom Typ ALIAS ist, folgende Teilschritte durchgeführt werden: aus dem Tabelleneintrag wird ein Alias- Bitstring extrahiert, der Alias-Bitstring und der Restbitstring werden zu einem Ausgangsbitstring kombi¬ niert, das gesamte Umsetzverfahren wird mit dem Ausgangsbitstring als neuem ersten Bit¬ string von Anfang an begonnen.
9. Verfahren insbesondere nach einem der Ansprüche 1 bis 7, bei dem der erste Bitstring in den zweiten Bitstring gemäß einem Umsetzverfahren umgesetzt wird, das die folgenden Schritte umfaßt: eine Tabelle mit mindestens einem Tabellen¬ eintrag wird vorgegeben, aus einem Eingangsbitstring werden Bits an bestimmten Stellen ausgewählt, wobei die nicht-ausgewählten verbleibenden Bits einen Restbitstring bilden, die ausgewählten Bits des Eingangsbitstrings bestimmen einen Eintrag der ersten Tabelle, dieser Eintrag der ersten Tabelle wird aus¬ gelesen, in dem Fall, daß der Tabelleneintrag vom Typ SIGNAL ist, folgende Teilschritte durchge¬ führt werden: aus dem Tabelleneintrag wird ein Hilfsbit¬ string extrahiert, das gsamte Umsetzverfahren wird abge¬ brochen und eine Meldung wird erzeugt, die mindestens den Hilfsbitstring enthält.
10. Verfahren nach Anspruch 9, dadurch gekennzeichnet, daß aufgrund der Meldung eine Prozedur an einer durch den Hilfsbitstring spezifizierten Adresse aufgerufen wird.
11. Verfahren insbesondere nach einem der Ansprüche 1 bis 7, bei dem der erste Bitstring in den zweiten Bitstring gemäß einem Umsetzverfahren umgesetzt wird, das die folgenden Schritte umfaßt: eine Tabelle mit mindestens einem Tabellen¬ eintrag wird vorgegeben, aus einem Eingangsbitstring werden Bits an bestimmten Stellen ausgewählt, wobei die nicht-ausgewählten verbleibenden Bits einen Restbitstring bilden, die ausgewählten Bits des Eingangsbitstrings bestimmen einen Eintrag der ersten Tabelle, dieser Eintrag der ersten Tabelle wird aus¬ gelesen, und in dem Fall, daß der Tabelleneintrag vom Typ LOCKED ist, das gesamte Umsetzverfahren von Anfang an neu begonnen wird.
PCT/EP1994/001453 1993-05-10 1994-05-06 Verfahren zum umsetzen einer virtuellen speicheradresse mit einer ersten länge in eine realadresse mit einer zweiten länge WO1994027222A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US08/549,731 US5790979A (en) 1993-05-10 1994-05-06 Translation method in which page-table progression is dynamically determined by guard-bit sequences

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
DE4315567 1993-05-10
DEP4315567.7 1993-05-10
DE4319842 1993-05-28
DEP4319842.2 1993-05-28
DE4405845A DE4405845C2 (de) 1993-05-10 1994-02-23 Verfahren zum Umsetzen einer virtuellen Speicheradresse eines virtuellen Speichers in eine Realadresse eines Realspeichers
DEP4405845.4 1994-02-23

Publications (1)

Publication Number Publication Date
WO1994027222A1 true WO1994027222A1 (de) 1994-11-24

Family

ID=27205072

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP1994/001453 WO1994027222A1 (de) 1993-05-10 1994-05-06 Verfahren zum umsetzen einer virtuellen speicheradresse mit einer ersten länge in eine realadresse mit einer zweiten länge

Country Status (2)

Country Link
US (1) US5790979A (de)
WO (1) WO1994027222A1 (de)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0813713A1 (de) * 1995-03-03 1997-12-29 Hal Computer Systems, Inc. Adressenübersetzungsbuffer in einem rechnersystem
EP0834131A1 (de) * 1995-05-26 1998-04-08 Emulex Corporation Verbundene caches zur kontextuellen datensuche
WO2002099653A1 (de) * 2001-06-05 2002-12-12 Infineon Technologies Ag Rechnersystem mit virtueller adressierung und verfahren zum ermitteln einer physikalischen adresse aus einer virtuellen adresse
US6826594B1 (en) 2000-07-15 2004-11-30 Commission Junction Method and system for remote content management of a designated portion of a web page

Families Citing this family (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4079506B2 (ja) * 1997-08-08 2008-04-23 株式会社東芝 不揮発性半導体メモリシステムの制御方法
GB9912129D0 (en) * 1999-05-26 1999-07-28 3Com Corp Communication device with forwarding database having having a trie search facility
US6577769B1 (en) 1999-09-18 2003-06-10 Wildtangent, Inc. Data compression through adaptive data size reduction
DE10127198A1 (de) * 2001-06-05 2002-12-19 Infineon Technologies Ag Vorrichtung und Verfahren zum Ermitteln einer physikalischen Adresse aus einer virtuellen Adresse unter Verwendung einer hierarchischen Abbildungsvorschrift mit komprimierten Knoten
US7243208B2 (en) * 2003-08-13 2007-07-10 Renesas Technology Corp. Data processor and IP module for data processor
JP4520790B2 (ja) * 2004-07-30 2010-08-11 富士通株式会社 情報処理装置およびソフトウェアプリフェッチ制御方法
US7627734B2 (en) * 2006-01-13 2009-12-01 Broadcom Corporation Virtual on-chip memory
US8880901B2 (en) * 2006-05-25 2014-11-04 Red Hat, Inc. Secure address handling in a processor
US8560806B2 (en) * 2007-12-31 2013-10-15 Intel Corporation Using a multiple stage memory address translation structure to manage protected micro-contexts
US8549254B2 (en) * 2007-12-31 2013-10-01 Intel Corporation Using a translation lookaside buffer in a multiple stage memory address translation structure to manage protected microcontexts
US8316211B2 (en) * 2008-06-30 2012-11-20 Intel Corporation Generating multiple address space identifiers per virtual machine to switch between protected micro-contexts
US9092359B2 (en) 2012-06-14 2015-07-28 International Business Machines Corporation Identification and consolidation of page table entries
US9753860B2 (en) 2012-06-14 2017-09-05 International Business Machines Corporation Page table entry consolidation
US9811472B2 (en) * 2012-06-14 2017-11-07 International Business Machines Corporation Radix table translation of memory
US20140164376A1 (en) * 2012-12-06 2014-06-12 Microsoft Corporation Hierarchical string clustering on diagnostic logs
US20180203807A1 (en) 2017-01-13 2018-07-19 Arm Limited Partitioning tlb or cache allocation
US10394454B2 (en) 2017-01-13 2019-08-27 Arm Limited Partitioning of memory system resources or performance monitoring
US10664306B2 (en) 2017-01-13 2020-05-26 Arm Limited Memory partitioning
US10649678B2 (en) 2017-01-13 2020-05-12 Arm Limited Partitioning of memory system resources or performance monitoring
US10268379B2 (en) 2017-01-13 2019-04-23 Arm Limited Partitioning of memory system resources or performance monitoring
US10664400B2 (en) * 2017-07-11 2020-05-26 Arm Limited Address translation cache partitioning
GB2582362B (en) * 2019-03-21 2021-08-04 Advanced Risc Mach Ltd Page table structure
US11256625B2 (en) 2019-09-10 2022-02-22 Arm Limited Partition identifiers for page table walk memory transactions

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US3614746A (en) * 1968-10-31 1971-10-19 Philips Corp Memory addressing device using arbitrary directed graph structure
US4763250A (en) * 1985-04-01 1988-08-09 Motorola, Inc. Paged memory management unit having variable number of translation table levels

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4654777A (en) * 1982-05-25 1987-03-31 Tokyo Shibaura Denki Kabushiki Kaisha Segmented one and two level paging address translation system
US4758946A (en) * 1986-04-09 1988-07-19 Elxsi Page mapping system

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US3614746A (en) * 1968-10-31 1971-10-19 Philips Corp Memory addressing device using arbitrary directed graph structure
US4763250A (en) * 1985-04-01 1988-08-09 Motorola, Inc. Paged memory management unit having variable number of translation table levels

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
KRIZ: "Variable block paging for virtual memory", IBM TECHNICAL DISCLOSURE BULLETIN, vol. 27, no. 4B, September 1984 (1984-09-01), NEW YORK US, pages 2296 - 2298 *
RASHID ET AL.: "Machine-independent virtual memory management for paged uniprocessor and multiprocessor architectures", IEEE TRANSACTIONS ON COMPUTERS, vol. 37, no. 8, August 1988 (1988-08-01), NEW YORK US, pages 896 - 907 *

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0813713A1 (de) * 1995-03-03 1997-12-29 Hal Computer Systems, Inc. Adressenübersetzungsbuffer in einem rechnersystem
EP0813713A4 (de) * 1995-03-03 1998-08-19 Hal Computer Systems Inc Adressenübersetzungsbuffer in einem rechnersystem
US5893931A (en) * 1995-03-03 1999-04-13 Fujitsu Limited Lookaside buffer for address translation in a computer system
EP0834131A1 (de) * 1995-05-26 1998-04-08 Emulex Corporation Verbundene caches zur kontextuellen datensuche
EP0834131A4 (de) * 1995-05-26 2001-10-31 Emulex Corp Verbundene caches zur kontextuellen datensuche
US6826594B1 (en) 2000-07-15 2004-11-30 Commission Junction Method and system for remote content management of a designated portion of a web page
WO2002099653A1 (de) * 2001-06-05 2002-12-12 Infineon Technologies Ag Rechnersystem mit virtueller adressierung und verfahren zum ermitteln einer physikalischen adresse aus einer virtuellen adresse

Also Published As

Publication number Publication date
US5790979A (en) 1998-08-04

Similar Documents

Publication Publication Date Title
WO1994027222A1 (de) Verfahren zum umsetzen einer virtuellen speicheradresse mit einer ersten länge in eine realadresse mit einer zweiten länge
DE69637294T2 (de) Mikro-tlb mit parallelem zugriff zum beschleunigen der adressübersetzung
DE2459006C2 (de) Einrichtung zum Bilden einer absoluten Adresse in einer Datenverarbeitunsanlage
DE4410060B4 (de) Übersetzungsvorrichtung zum Umsetzen einer virtuellen Speicheradresse in eine physikalische Speicheradresse
DE3833933C2 (de) Informationsverarbeitungseinrichtung mit einer Adressenerweiterungsfunktion
DE602004011018T2 (de) Ungültigkeitserklärung eines speichers und löschen von puffereinträgen
DE112017001027B4 (de) Seitenfehlerbehebung
DE69721590T2 (de) Ein bereichsbasiertes seiten-table-walk-bit verwendendes verfahren sowie vorrichtung
DE112005003859B4 (de) Verwalten von Prozessorressourcen während Architekturereignissen
DE2226382C3 (de) Datenverarbeitungsanlage mit mehreren Prozessoren und diesen zugeordneten Pufferspeichern
DE60003273T2 (de) Verfahren und Vorrichtung zur Erzeugung einer Eingabeadresse
DE69629800T2 (de) Adressenübersetzungsbuffer in einem rechnersystem
DE2131066C3 (de) Anordnung zum Adressieren eines Tabellenspeichers
DE10127198A1 (de) Vorrichtung und Verfahren zum Ermitteln einer physikalischen Adresse aus einer virtuellen Adresse unter Verwendung einer hierarchischen Abbildungsvorschrift mit komprimierten Knoten
DE3151745C2 (de)
DE102020127705A1 (de) Techniken für einen effizienten fabric-attached-speicher
DE10002120A1 (de) Logikstruktur eines Adressumsetzpuffers
DE102014014076A1 (de) Reduzierte Adressenkonvertierung mit mehreren Seitengrößen
DE69634315T2 (de) Verfahren und Gerät zur Verwendung eines Ladebefehls der keinen Fehler verursacht
DE112018002032T5 (de) Gemeinsames nutzen von virtuellen und realen übersetzungen in einem virtuellen cache
DE112018002028T5 (de) Umsetzungsunterstützung für einen virtuellen cache
DE112018003032T5 (de) Cachestruktur, die ein logisches verzeichnis verwendet
DE19934515A1 (de) Verfahren und Einrichtung zum Durchführen von Cache-Segment-Flush- und Cache-Segment-Invalidier-Operationen
DE4234695C2 (de) Computer-Speichersystem und Verfahren zur Aufrechterhaltung der Cache-Kohärenz zwischen einem Daten-Cache und einem Segmentdeskriptor-Cache
DE112010004562T5 (de) Zuweisung wirksam referenzierbarer global eindeutiger Kennungen in einer Mehrkernumgebung

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): CN JP RU US

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH DE DK ES FR GB GR IE IT LU MC NL PT SE

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 08549731

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: CA

122 Ep: pct application non-entry in european phase