How does a processor generate an address?

Hi all, This might seem like a dumb question, but I was reading up on VM(books and online), and everywhere it mentions that 'the processor generates a virtual address'. I just don't understand what this means. If you make your program start at a particular address(using a linker command file etc), then where does the virtual address comes from? Any help would be much appreciated. Thank you in advance, Mary

Reply to
Mary
Loading thread data ...

We have all been newbies at some time so this is not a dumb but a basic question.

On some systems the processor has access to what is called a virtual memory. This is done for different purposes, to give access to a larger address space than the actual physical adress space and to prevent a process from accessing the memory space of an other process.

The memory address presented on the address bus by the processor is converted to a physical address by a piece of hardware called a translater. Basically, the address presented by the processor and called a virtual address is used to select a physical chunk of memory called a page and to access a particular address is this page.

The page can reside in the physical memory, i.e. ram, or can be absent from the main memory and present on a disk.

This gives a process access to a larger memory than what is actually present in ram, but a page not present in ram must be fetched from the disk when accessed.

HTH

Reply to
Lanarcam

Many processors have what is generally called an MMU ("Memory Management Unit") in the path between the CPU and the address bus. One of the functions of the MMU is to translate between logical (or virtual) and physical addresses. The translation details (how much memory, which addresses, etc.) is generally controlled by a set of register written by the CPU.

In a multitasking operating system, for example, you may load several programs at once into memory at different physical addresses, but with all the programs linked as if they were all loaded starting at address

  1. The operating system will configure the MMU in such a way that when a program is running, addresses in the virtual range [0 ->

program-size] will be translated into the physical address range [load-address-of-program -> load-address-of-program + program-size]

The MMU may have to be reconfigured before another program is given control so that the new program will also run as if it was loaded at address 0, and/or it may be set in such a way that there is no translation at all (virtual=physical) when the operating system itself is running.

This is an oversimplification, of course, programs do not need to be contiguous, they may overlap, share code (at the same or different logical addresses,) the MMU may also implement protection policies, deal with memory page faults, (virtual address mapped to memory that is not there,) and you do not need an MMU to have a multitasking system, but the description above covers the most general and simple cases.

Roberto Waltman

[ Please reply to the group, ] [ return address is invalid. ]
Reply to
Roberto Waltman

First of all, thank you very much for your reply. Your explantion about the illusion of a larger memory was very helpful. I definitely haven't got my fundamentals right.

You mentioned "the memory address presented on the address bus by the processor". Where does that memory address come from?

Also is the following assumption correct? There is VM and Physical memory. And as fas as I understand, these are located at different addresses, and are independent of eachother. A program only runs from Physical memory.

Say for example, you have Physical memory starting at address

0x8000_0000 (512MB of it), ending at 0x9FFF_FFFF. Then there is VM starting at 0xA000_0000 ending at 0xBFFF_FFFF. If I have a program and I make it start at 0x8000_0000, I still don't see how the processor generates any virtual address.

Mary

Reply to
Mary

The virtual address is really virtual it does not map to a real address space, at least not directly.

The virtual adress space can be considered as being made of pages of say 4Ko. From the processor perspective it is contiguous, but in reality each page of the virtual memory is translated into a physical page and the physical pages are not necessarily contiguous nor residing in main memory at a given time.

The virtual address space of a process can go from 0 up to

4 Go, but the physical address is generally less than that. Adresses are translated when needed upon access from the processor.

The processor presents on its memory bus the virtual address and the MMU as described in another post translates this address into a physical address that is presented on the bus used to physically access the memory device.

Reply to
Lanarcam

Say for example we have 3 programs. A drawback here is that physical memory is not enough to execute all 3. YOu mentioned in a multitasking OS, we can load several pgms at once at diff P.A.'s. Based on your explanation, this is the picture I get.

_________________ ^ | |

Reply to
Mary

Programs can be written to load at any (virtual) address and start at any address. Executables usually have a header at the start of the file that specifies LOAD address, RUN address, etc.

Yes.

Here's another example. Here's a physical memory diagram showing three loaded processes, A, B and C: . . | |

+--------+ 90000 | PROG A | +--------+ 80000 | PROG B | +--------+ 70000 | PROG A | +--------+ 60000 | PROG B | +--------+ 50000 | |
  • PROG C + 40000 | |
+--------+ 30000 | PROG A | +--------+ 20000 | PROG C | +--------+ 10000 | | . .

Notice that the programs are scattered throughout physical memory.

Now imagine PROG A is loaded into virtual address 40000. This is what PROG A sees (virtual addresses):

. . | |

+--------+ 70000 | |
  • + 60000 | PROG A |
  • + 50000 | |
+--------+ 40000 | | . .

i.e. it sees a contiguous memory map. This is achieved using the maps (or page tables) in the MMU.

PROG A MMU Table Virtual -> Physical

40000 80000 50000 20000 60000 60000

See how there's no correlation to the order of pages in the virtual address space and the order in the physical address space. Physical pages are used in any order, with the MMU tables configured as appropriate.

When the CPU decides to stop running PROG A and start running PROG B, it sets up a new virtual -> physical map:

PROG B MMU Table Virtual -> Physical

40000 50000 50000 70000

In this case PROG B, just like PROG A, is loaded at virtual address

40000.

This is, of course, heavily simplified.

Good luck.

Paul.

Reply to
Paul Marciano

Paul, this really helped. All the posts are slowly coming together! I cannot thank everyone(Lanarcom and Roberto included) enough.

Reply to
Mary

Mary wrote On 09/27/05 12:56,:

Virtual memory is like a card game. The operating system has cards (pages), which on the back say "physical page 6", and on the front say "virtual page 10". The processor can lay the cards out in rows and collumns to make a large surface for the program to run on, or it can get even more tricky and only place cards where the program needs them.

Each time the program needs a page of virtual memory, say at address $10000000, the OS gets a card or page from its stack of physical pages. Lets say the next page of physical is $12340000. Then it sets that page to be virtual $1000000, and places the page in the "working set" of the program, and thus it now has its virtual memory.

How does the program request this memory ? It accesses it, by reading, writing, or even executing instructions from it.

Now thats virtual addressing. Virtual memory is slightly more than that. The operating system can use this ability to do very interesting things. It can start out with no cards on the table for the program, then let the program determine what cards it wants. The program only gets pages if it specifically asks for it. This is called "demand paging".

Now, the OS is watching the program fill the table with cards, it can then say "gee, the program asked for card X, but hasn't used it for quite some time". It can take the card off the table, knowing that it can simply put it right back if the program asks for it. If the card has data the program created, it can move the card off to a hard disk so that it can get the data back. If the card contains, say, part of the program's instructions, and the program was not allowed to write on it (modify its own code), it can just throw the card away, knowing that it can just get that card back from the program file on disk.

What is important to understand is that the program is not aware of any of this. If it hits a page that is not there, it is stopped cold until the page is placed there by the OS. Its as if your company got really cheap with furniture, and fitted you with a device that made you zone out whenever you tried to sit in your office chair and ring a bell. When it happens, someone runs down the hall, takes a chair that is not currently in use, and places it under you, and lets you go. You are not aware of any of it, you think you have a chair of your own, unless you notice the clock on your wall seems to jump ahead on occasion.

You're thinking of VM as a thing that does not change. VM is your programs *view* of physical memory that the OS arranges for you. If you ask (your program asks) for memory at $80000000, then the OS arranges for you to have it there, by taking real physical memory and placing it there for you.

Reply to
Scott Moore

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.