I'm writing an address translator for my operating system class. I know i'm reading in the virtual address correctly, and that the page number i get is correct (i access the right data) but when i try to figure out what the physical address is I get the wrong physical address.
specs:
2^8 entries in the page table
Page size = 2^8 bytes
Frame size = 2^8 bytes
256 frames
Physical memory = 65,536 bytes (256 frames × 256-byte frame size)
Here's a correct output:
Virtual address: 12107 Physical address: 2635 Value: -46
Here's what i'm getting:
Virtual address: 12107 Physical address: 12107 Value: -46
from my understanding the physical address is equal to (pageNumber * pageSize + pageOffset) everything i have read has said this.
When i get the page number from 12107, i get 47 (left most 8 bits)
When i get the offset from 12107, i get 75 (right most 8 bits)
(47 * 256 + 75) gets me 12107.
to get the correct output (physical address) the page number needs to be 10
(10 * 256 + 75) gets the correct output 2635.
I have poured over my book and have spent the last few days trying to find out where the heck i've gone wrong but i can't seem to figure it out.
I figured out what was happening, I had a misunderstanding in my implementation of page tables. I had a page table but no frame table it would be pointing to, the page table was actually completely bypassing that step, so in effect my physical and logical address were the same.
Once i implemented a frame table, and a proper method for populating the frame table i began generating the physical address correctly.
Related
Following is a page table -
enter image description here
Assume that a page is of size 16000 bytes. How do I calculate the physical address for say the logical address 1000.
Here is what I have worked out yet.
Logical memory = 8 pages
Logical memory size = 8 x 16000 bytes
Physical memory = 8 frames
physical memory size = 8 x 16000 bytes
Now given a logical address of 1000 it will map to the first page which is in frame 3
so considering frame0, frame1, frame2 all of 16000 x 3 bytes.
1000 will be at location 16000 x 3 + 1000
so the physical address will be = 49000 byte
Is this a correct approach?
Is this a correct approach?
Yes. To clarify:
Given a logical address; split it into pieces like:
offset_in_page = logical_address % page_size;
page_table_index = logical_address / page_size;
Then get the physical address of the page from the page table:
physical_address_of_page = page_table[page_table_index].physical_address = page_table[page_table_index].frame * page_size;
Then add the offset within the page to get the final physical address:
physical_address = physical_address_of_page + offset_in_page;
Notes:
a CPU (or MMU) would do various checks using other information in the page table entry (e.g. check if the page is present, check if you're writing to a "read-only" page, etc). When doing the conversion manually you'd have to do these checks too (e.g. when converting a logical address into a physical address the correct answer can be "there is no physical address because the page isn't present").
modulo and division (and multiplication) are expensive. In real hardware the page size will always be a power of 2 so that the modulo and division can be replaced with masks and shifts. The page size will never be 16000 bytes (but may be 16384 bytes or 0x4000 bytes or "2 to the power of 14" bytes, so that the CPU can do offset_in_page = logical_address & 0x3FFF; and page_table_index = logical_address >> 14;). For similar reasons, page table entries are typically constructed by using OR to merge the physical address of a page with other flags (present/not preset, writable/read-only, ...) and AND will be used to extract the physical address from a page table entry (like physical_address_of_page = page_table[page_table_index] & 0xFFFFC000;) and there won't be any "frame number" involved in any calculations.
for real systems (and realistic theoretical examples) it's much easier to use hexadecimal for addresses (to make it easier to do the masks and shifts in your head = e.g. 0x1234567 & 0x03FFFF = 0x0034567 is easy). For this reason (and similar reasons, like determining location in caches, physical address routing and decoding in buses, etc) logical and physical addresses should never be use decimal.
for real systems, there's almost always multiple levels of page tables. In this case approach is mostly the same - you split the logical address into more pieces (e.g. maybe offset_in_page and page_table_index and page_directory_index) and do more table lookups (e.g. maybe page_table = page_directory[page_directory_index].physical_address; then physical_address_of_page = page_table[page_table_index].physical_address;).
Considering multilevel paging, If we have a physical address of 32 bits, say 24 bits are allocated for frame number. Whenever a Virtual address is generated, it goes to Page Table and the PTE is 24 bits(ignore control bits) gives frame no. But these 24 bits cannot actually find an address .
So my question is, Are these 24 bits right padded with zeros to reach the base address of that frame ?
Given a virtual memory system which utilises a 32-bit virtual address.
A page table that takes 1 MiB of memory per process.
Each PTE(page table entry requires 4 bytes.
The system has a total of 256 Megabytes of memory available.
I understand that a Page table is essentially a list of entries(PTE) that provide a mapping of the virtual addresses to a physical address.
I need to calculate the size of each virtual page. But I have no clue how.
So far all I've got is 2^20(page-table size)/2^2(PTE size)=2^18 this gives me the total amount of entries I can have in a page table. I'm not even sure if this is useful to find the size of each virtual page.
Could anyone point me in the right direction? Perhaps I'm misunderstanding in how these metrics relate to the size of a virtual page.
Edit: I've found out the size of the page is determined by the following.
A virtual address consists of bits for a page pointer and an offset.
The last bits of the virtual address are called the offset which is the location difference between the byte address you want and the start of the page. You require enough bits in the offset to be able to get to any byte in the page.For a 4K page you require (4K == (4 * 1024) == 4096 == 212 ==) 12 bits of offset.
The page pointer can be determined by the number of entries in the table. This was simply my formula from before 2^20(page-table size)/2^2(PTE size)=2^18 entries. Which means I have 18 bits being used in my virtual address for my page pointer. I can determine the offset by 2^32(virtual address size)/2^18 which gives me 2^14. Therefore my page size for my virtual address is 2^14 or 16KiB.
The problem as you describe is under-specified. You need to know the width of the page offset field within the virtual address (or, how many levels of indirection the VM system is using). For example, (as in ONE of the modes that x86 system uses), if you have two levels of indirection, then you will have 10x2 bits used for levels of indirection and remaining 12 bits for offset within the page. That gives you a page size (= frame size) of 4KB.
If you instead use one level of indirection (as ANOTHER x86 mode allowed, but is found less often), then you can have a division of 10 bits for the only level of indirection and remaining 22 bits as offset within the page. That gives a page size of 4MB.
You see above that same 32 bit virtual address can follow different levels of indirection for paging and end up with different page sizes.
Page offset size in the virtual address determines the page size.
There is no answer under those fact. You have the page table entry is 32 bits. That puts a theoretical upper bound on the page size as 2^32. However, some bits are going to used for control so the size will be smaller.
The 1MB size of of the page table and 32-bit virtual address facts are irrelevant to the page size.
I have trouble doing this small exercise:
So far I got this:
For VADDR = 0x5ddb, binary representation is 0101 1101 1101 1011, thus we know the VPN = 101 = 5.
What's the next step?
The most significant three bits constitute the virtual page number, the remaining twelve bits form the offset into the page frame.
In your concrete example the virtual page number is 5, as you correctly mentioned, and the offset is
1101 1101 1011 = 0xddb = 3547
Now proceed like this:
Use the virtual page number as an index into the page table. The 5th (starting from zero) is 0x80000006.
Check the validity bit. It's set, so the page entry is valid. If it was not the page would not be in memory and a page fault would occur.
As said in the image, the rest of the entry is the page frame number. It's the 6th page frame, so you can calculate the page frame's phyiscal address by multiplying this number with the size of a page frame, that is, 4 KiB. Hence, the physical address is
6 * 4 KiB = 24 KiB = 24576
Add the offset to the physical address of the page frame:
24576 + 3547 = 28123
And you have your address.
The virtual address 0x5ddb corresponds to the physical address 28123 = 0x6ddb on the described system.
I'm looking over some exam papers for Operating Systems and I have come across a question which I simply cannot figure out. The memory management scheme is paging
Here is the question:
An operating system that runs on a CPU with a 16 bit address pointer employs a paging memory management scheme with a page size of 1024 bytes.
a) At most how many frames can physical memory contain?
b) Indicate which bits in an address pointer are used for page and offset.
c) A process image of size 3.5K resides in memory. You are given the page table of this process in Figure 1 below. What physical address will the hexadecimal logical address 0x0FCE result in? Show your calculations.
d) How much internal fragmentation does this process produce?
Page Frame
0 4
1 8
2 9
3 6
Figure 1 Process Page Table
Can anybody help me with this ?
A 16bit address bus allows to access 2^16 = 64kB of physical memory. Since on this system you have pages of size 1024B = 2^10, your memory falls into 2^16 / 2^10 = 2^6 physical frames.
Given the previous result, with pages of 1024 = 2^10 bytes, you need 10 bits for accessing any bytes of the page. Thus, the 6 high-order bits ares used for getting the page index from the page table (basically the figure 1 in your homework), and the 10 low-order bits are used for offsetting in that page.
The logical address 0xfce resides in the fourth page because the six high-order bits are 000011b = 3 = 4th page = 0x0c00-0x0fff. Given the page table and assuming the physical memory is sequential, the fourth page maps to the sixth physical frame which start at 1024 * 6 = 0x1800 = 0001100000000000b. The six high-order bits of the page are 000110b, where we add the 10 bits of offset resulting from the previous answer: 000110b << 10 | 0x3ce = 0x1bce.
Since the frame allocation is not sequential (4, 6, 8, 9), the hole between pages 4 and 6 (i.e. 1024B), and the hole between page 6 and 8(i.e. again 1024B), result in physical memory fragmentation.
Hope this help.