LEARN MORE...

Home
Documents
July 2021
31
Address txt content Designing a Virtual Memory Manager This project

Address txt content Designing a Virtual Memory Manager This project

Content type

User Generated

Uploaded By

Nouvanixefvatu

Pages

Showing Page:

1/3

address.txt content Designing a Virtual Memory Manager

This project consists of writing a program that translates

logical to physical addresses for a virtual address space of

size 2 65,536 bytes. Your program will read from a file

containing logical addresses and, using a TLB as well as a

page table, will translate each logical address to its

corresponding physical address and output the value of the

byte stored at the translated physical address. The goal

behind this project is to simulate the steps involved in

translating logical to physical addresses Specifics Your

program will read a file containing several 32-bit integer

numbers that represent logical addresses. However, you

need only be concerned with 16-bit addresses, so you

must mask the rightmost 16 bits of each logical address.

Hence, the addresses are structured as shown in Figure

9.33 Other specifics include the following: 28 entries in the

page table Page size of 25 bytes 16 entries in the TLB

Frame size of 2 bytes 256 frames Physical memory of

65,536 bytes (256 frames x 256-byte frame size)

Additionally, your program need only be concerned with

reading logical addresses and translating them to their

corresponding physical addresses. You do not need to

support writing to the logical address space. Address

Translation Your program will translate logical to physical

addresses using a TLB and page table as outlined in

Section 8.5. First, the page number is extracted from the

logical address, and the TLB is consulted. In the case of a

TLB-hit, the frame number is obtained from the TLB. In the

case of a TLB-miss, the page table must be consulted. In

the latter case, either the frame number is obtained 16 15

87 Figure 9.33 Address structure.

Showing Page:

2/3

Solution

Preceding sections talked about how to avoid memory

fragmentation by breaking process memory requirements

down into smaller bites ( pages ), and storing the pages

non-contiguously in memory. However the entire process

still had to be stored in memory somewhere. In practice,

most real processes do not need all their pages, or at least

not all at once, for several reasons: Error handling code is

not needed unless that specific error occurs, some of

which are quite rare. Arrays are often over-sized for worst-

case scenarios, and only a small fraction of the arrays are

actually used in practice. Certain features of certain

programs are rarely used, such as the routine to balance

the federal budget. :-) The ability to load only the portions

of processes that were actually needed ( and only when

they were needed ) has several benefits: Programs could

be written for a much larger address space ( virtual

memory space ) than physically exists on the computer.

Because each process is only using a fraction of their total

address space, there is more memory left for other

programs, improving CPU utilization and system

Showing Page:

3/3

Unformatted Attachment Preview

address.txt content Designing a Virtual Memory Manager This project consists of writing a program that translates logical to physical addresses for a virtual address space of size 2 65,536 bytes. Your program will read from a file containing logical addresses and, using a TLB as well as a page table, will translate each logical address to its corresponding physical address and output the value of the byte stored at the translated physical address. The goal behind this project is to simulate the steps involv ed in translating logical to physical addresses Specifics Your program will read a file containing several 32 -bit integer numbers that represent logical addresses. However, you need only be concerned with 16 -bit addresses, so you must mask the rightmost 16 bits of each logical address. Hence, the addresses are structured as shown in Figure 9.33 Other specifics include the following: ...
Purchase document to see full attachment