1
\$\begingroup\$

Physical address is hardware address of physical memory and virtual address is the one the processor will be seeing, it has it has a tag and offset. I understand this. Can any one describe it with an example, like how the MMU does this operation (what it adds to the physical address) and what's memory mapping? And what is physically addressed physically tagged, virtually addressed virtually tagged?

\$\endgroup\$
  • 2
    \$\begingroup\$ See "page table" and "translation lookaside buffer". \$\endgroup\$ – pjc50 Nov 30 '12 at 12:54
  • \$\begingroup\$ This is really a computer architecture question, not an EE question. Isn't there a different SE site for that? \$\endgroup\$ – Dave Tweed Nov 30 '12 at 22:12
  • \$\begingroup\$ @DaveTweed ...since when is computer architecture not related to EE? #offended #ECE \$\endgroup\$ – vicatcu Dec 1 '12 at 0:10
1
\$\begingroup\$

Address translation is handled through a translation lookaside buffer (TLB), which is just a cache of translation information (and some metadata like permissions, cacheability, etc.). The TLB works by substituting the physical page number (the address bits above those used to index within a page) for the provided virtual page number (i.e., the virtual page is mapped to the physical page). (Since virtual pages are aligned with physical pages at page granularity, the bits indexing within a page match for virtual and physical addresses of a given page.)

Typically, to reduce delay in retrieving data, the cache is indexed with the virtual address in parallel with the TLB lookup; this would be a virtually addressed cache, but if only index bits within a page are used then it is also a physically addressed cache (because those bits of the virtual address match the bits of the physical address). (A cache might be physically addressed at least partially in parallel with TLB access by predicting the extra non-virtual bits or by feeding in the extra bits after partially indexing the cache, but the tradeoffs seem to favor virtually addressed caches.)

(Using non-physical address bits in indexing the cache can introduce complexities since another mapping of the page might not use the same virtual indexing bits.)

Currently, physical tagging is preferred where a cache hit is determined by comparing the tag at the appropriate index with the requested physical address. Coherence with other devices accessing memory (I/O devices or processors), which provide physical addresses to the system, is easier with physical tags (avoiding the need for a physical address to virtual address translation mechanism, though physical tags could be provided in addition to virtual tags by duplicating the tag storage or by using of an inclusive L2 cache).

As an example, with an 8KiB, two-way set associative cache with 16 byte blocks using 4KiB pages in a 32-bit address space, there would be 256 sets (groups of cache blocks sharing the same index)--requiring 8 bits to index. A load of the 32-bit word at 0x00ab_1134 would index the sets with 8 bits (0x13), read the two tags for that set, and read the words at offset 0x4 in both data blocks for the set. (Reading both blocks reduces delay.) While indexing the cache, the page number, the top 20 bits of the address (0x00ab_1) is presented to the TLB (usually with an address space ID appended); assuming the information for that page is available in the TLB (a TLB hit), the translation is sent to be compared with both tags resulting in either a match against one of the tags (in which case the data corresponding to that tag is selected) or no match (in which case there is a cache miss). (The TLB will also check to see if the process has read permission for that page.)

With a virtually tagged cache, the TLB can be taken out of the critical path (potentially reducing cache access delay with a larger TLB) since it is only needed for permission checks not for tag comparison. (Permission information could even be included with the cache tags.) Typically a system has a larger virtual address space than physical (cacheable) address space, so virtual address tags would require more storage space; this storage demand is increased by the addition of address space IDs to avoid having to flush the cache when a different process is loaded (a Single Address Space OS would not need such a flush).

The wikipedia article for "CPU cache" might be helpful.

\$\endgroup\$
3
\$\begingroup\$

It is difficult to tell what you are asking, and this isn't the place for a book on virtual memory. It seems you are asking how the address translation from virtual to physical addresses works. I'll try to explain it briefly.

There are many ways this can be done, with some tradeoffs between what is handled automatically by the hardware and at what level things get too complex so that the software has to get envolved. Basically, for a block of virtual addresses that already has its data in real memory (paged in), there is a hardware translation mechanism. The low address bits map directly, so only the upper bits need to be translated. For example, if pages are 1 k in size, then the low 10 bits of any virtual and the corresponding physical address are the same. The upper bits identify the page, but there can still be many of them. For example, on a 32 bit address machine with 1 k sized pages, there are 22 page-address bits, or 4 M pages.

You could make a table with 4 M entries, but this needs to be in special fast memory since it gets used every address reference. That would be very expensive, so usually a much smaller list of recently used pages is kept in a special high speed memory. That memory needs to be associative (content addressed). Put another way, every page reference all entries in this high speed memory are checked in parallel to see which one, if any, contains the mapping info for that particular page. The one that does supplies the upper bits of the real address, which is then combined with the low bits to form the address where that word currently resides in real memory. This special high speed associative memory is often called the translation lookaside buffer, or TLB.

If none of the TLB entries match the page address, then things get more complicated. I'm not going to go into all that because there is much written about it out there. If you want to know more, ask specific questions.

\$\endgroup\$
1
\$\begingroup\$

Most processors' instruction sets have a concept of either a unified address space where each location is addressed by a single "number" (as opposed to a bit pattern, meaning that 0x1000 would be considered 'closer' to 0x0FFF than to 0x0000 even though it differs from the former by 13 bits, and from the latter by only one bit), or a small number of such spaces (perhaps one for I/O and one for memory, etc.). While some systems have every different number mapped permanently to a distinct memory circuit, in most cases it will be possible for a given memory location to be accessed via a variety of numbers. In such cases, the documentation for a system will often assign each memory circuit a single "permanent" number which is referred to as its "hardware address". This isn't generally done for individual memory circuits, of course, but rather groups of them.

Especially in older systems, the most common reason for memory to be accessible at multiple addresses wasn't due to any complicated circuitry, but rather the lack of it. A system uses 16 bit numbers to represent memory addresses (64K worth of address space), and has nothing on the memory bus are an 8K ROM chip and an 2K RAM chip, would typically use the upper bit of the address to select between the ROM and RAM chip, and use the bottom 13 or 11 bits to select an address within the chip, and simply ignore the rest of the address bits. Accessing memory address 0x1234 (0001 0010 0011 0100) would cause the system to select the ROM chip (since the high bit is clear), and send the bottom 13 bits of the address to the chip, accessing location 0x1234 (1 0010 0011 0100) of it. Reading memory location 0x5234 (0101 0010 0011 0100) would likewise cause the system to select the ROM chip and send the bottom 13 bits of the address to the chip (again, 1 0010 0011 0100). Thus, 0x5234 and 0x1234 would both map to the same address (which would typically be designated as hardware address 0x1234).

In the system described above, the mapping between logical addresses (the numbers seen by the processor) and physical addresses (which identify memory circuits) was fixed. In newer systems, various means exist by which the mappings can be changed. One common pattern (still used in some microcontrollers, though not in desktop processors) is to have circuitry which would detect one or more discrete ranges of address space and feed the contents of certain control registers onto parts of the address bus when they are activated. This approach makes it possible to have a processor access memory which is much larger than its normal address space. For example, a processor with a 16-bit address (64K address space) could be wired to a megabyte of RAM in such a way that an address of the form 11xx xxxx xxxx xxxx) will map to hardware address 1111 11xx xxxx xxxx xxxx, while an address of the form 10xx xxxx xxxx xxxx will map to hardware address rrrr rrxx xxxx xxxx, where rr rrrr represents the contents of a special 6-bit register). To facilitate moving data between different parts of memory, many such systems will have two or ranges of addresses whose hardware address can be configured independently. For example, the aforementioned system could also include hardware so that an access to 01xx xxxx xxxx xxxx will operate on hardware address ssss ssxx xxxx xxxx xxxx, where ss ssss is a six-bit register which may be written independently from rr rrrr.

Many desktop machines take the above concept a step further. Rather than merely providing a small number of address ranges which can be used to access many different pieces of memory, they allow each 4K range of address space to be independently mapped to any 4K of physical memory space. Such abilities are very powerful, but are much more complicated than is worthwhile to discuss here.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.