180 likes | 270 Views
Memory Management and Protection Part 2: The hardware view. dr.ir. A.C. Verschueren Eindhoven University of Technology Section of Digital Information Systems. Address translation. Not needed for linear memory organisation
E N D
Memory Management and ProtectionPart2: The hardware view dr.ir. A.C. VerschuerenEindhoven University of TechnologySection of Digital Information Systems
Address translation • Not needed for linear memory organisation • Processor generated (logical) address real memory (physical) address • May be handy to attach access rights to addresses • Needed for multiple linear address spaces andsegmented memories • Complex for multiple linear address spacesthe actual address must be checked
logical address physical access address rights Table based direct address translation • This table grows very large:Translating 1 million addresses with 4 access rights bits requires a 3 MegaByte table!
logical address '>=' '<' compare compare access physical offset rights Address bounds checking (1) physical address
Address bounds checking (2) • Parallel comparators are VERY expensive • Use a lot of power and chip area • Number of address ranges would be limited • Physical address ranges must have same sizes as the logical address ranges • Memory which is organised into large (undividable) blocks is hard to manage • Same problem in a purely segmented memory
logical address <n> <p> 'page table' logical page offset physical page access <m> <p> rights physical address Paging (1) • <p> bits of the address are not translated: 2p words in a page have the same access rights
Paging (2) • Paging is cheaper than full address translation • Translating 1 million addresses with 1024 word pages requires a page table with only 1024 entries • With 10 bits physical page numbers and 4 access rights bits, the page table takes less than 2048 bytes! • Translating 32 bit addresses with 4096 word pages requires a page table with 1 million entries! • Not all of these pages will be in use at the same time...
Firstlevelpagetable logical address 1st leveltableindex <x> <y> <p> Secondlevelpagetable page offset 2nd level table index Physicalpage 2nd leveltable present <m> <p> physical address access rights Multi-level paging
Multi-level paging example • 4 byte words, 32 bit addresses (2 bits select byte), 1024 word / 4096 byte pages (<p> = 10+2 bits) • Second level table: 1024 entries (<y> = 10 bits) • Entry contains 20 bit physical page number (<m> = 20), leaves 12 bits for access rights if each entry takes one word • Each second level page table fits in one page • First level page table: 1024 entries (<x> = 10 bits) • Entry contains 20 bits physical page number of 2nd level table plus the 'table present bit' - fits easily in one word • First level page table fits in one page
Multi-level paging (continued) • This address translation method is very cheap • The example second level table handles 4 MegaByte • If code, data and stack fit in 8 MegaByte, we need 3 pages (12 KiloBytes) for translation • Multi-level paging is not limited to 2 levels! • Motorola 68020 can go up to FIVE levels of tables • Each table entry (not just the last) can specify access rights, can also give length limit for next table Searching through 5 tables for each memory access is a bit slow
logical address <n> <p> page offset tag '=' compare 'hit!' <m> <p> access rights physical address Speedup: translation lookaside buffer • This 'Content Addressable Memory' lookaside buffer can reach 98% hits with ‘only’ 32 entries
logical address <y> <x> <p> 'tag' 'hit!' physical page access rights <m> <p> physical address A 'set associative' lookaside buffer Cheap, simple RAM
But different translation tags Same line in table The problem with set associative buffers • A ‘tag clash’ makes the lookaside buffer worthless • Two or more different pages used in short loop • With same <y> bits but different <z> (tag) bits 4 bit<z> 4 bit<y> 8 bit<x> ‘WaitHere’ at address 35E6h 35E6 ‘DataPort’ at address 5537h 5537 WaitHere: JNB DataPort.1,WaitHere TWO misses per loop !
logical address Tagtable1 Tagtable2 Pagetable1 Pagetable2 <y> <x> <p> a.r.1 a.r.2 'tag' physicalpage mux mux <m> <p> accessrights physical address hit logic set selection 'hit!' N-way set associative lookaside buffers • Reduce (but do not solve) tag clashes Same hit-rate as‘Content Addressable’
Lookaside buffer replacement strategy • With filled buffer, new translations replace old • With 1-way set associative: <y> bits fix choice! • Best choice: remove one which will not be used • Difficult, but ‘Least Recently Used’ may be the same • LRU requires administration: small choice sets only • Used for N-way set associative lookaside buffers • Another strategy: remove one at random • Works well with large choice sets (CAM buffers!) • Small probability of removing the wrong entry
logical address segment offset Segmentbases Segmentlimits '<'/'>' accessrights error! 'stack' physical address Segmented memory address translation • Segment table is in main memory !
Segmented translation speedup • Processor uses only a few segments at once • Place currently used segment info in on-chip registers • Software decides which segments are loadedno replacement strategy needed in hardware! • Example: Intel 80386 uses 6 current segments • Code, stack and ‘default data’ • Up to 3 ‘extra data’ segments referenced explicitly
'0' 0 1 1 addressspace mux windowselectionregister 'N' windows 1 N - 2 N - 1 '-1' N - 1 N - 1 The old-fashioned way: ‘windowing’ • Selection register is normally an output port • Window selection is part of memory management • Should be managed by operating system! ‘Expanded Memory’