Talk:Memory management unit

Untitled section

Nice article; thanks. Comments:

- You use 2^N, by which you probably mean exponent, but ^ means something different in many programming languages. To avoid possible confusion, I suggest actually saying 2^N.

- The examples seem a bit esoteric. When explaining computer terms, the 68030 and Z280 aren't exactly household names. Is it a correct assumption that CPUs everybody has heard of these days (Pentium, Athlon, G4, G5, maybe SPARC or Alpha) all have built-in MMUs? What about embedded chips?

If you feel a change is needed, feel free to make it yourself! Wikipedia is a wiki, so anyone — including you — can edit any article by clicking the edit this page tab at the top of the page. You don't even need to log in, although there are several reasons why you might want to. Wikipedia convention is to be bold and not be afraid of making mistakes. If you're not sure how editing works, have a look at How to edit a page, or try out the Sandbox to test your editing skills. New contributors are always welcome. --fvw* 09:00, 2004 Dec 20 (UTC)

- Maybe it would make sense to mention that there is also an IOMMU used for DMA access in a virtualized environment. — Preceding unsigned comment added by 85.216.86.238 (talk) 17:48, 2 December 2012 (UTC)

FS and GS

What are FS and GS? --Abdull 07:13, 28 March 2007 (UTC)

They are segment registers. -- intgr 07:28, 28 March 2007 (UTC)

Memory Management Unit vs. Memory Controller

Is a Memory Management Unit the same thing as a Memory Controller? Or on a given motherboard can both be found? I'm wondering since there are wikipedia entries for both "Memory Controller" and "Memory Management Unit." Neither entry seems to reference the other. Firefly 15:51, 22 July 2007 (UTC)

They're completely different things, which is why neither entry references each other. The MMU attempts to translate a virtual address (the addresses of instructions and instruction operands are virtual addresses) to a physical address (addresses that actually refer to main memory); that attempt either fails with a page fault (which means there is no main memory for that address - a page frame in main memory needs to be allocated and the page's data needs to be read from backing store into that page frame), fails with a permission error (meaning that there is a page in main memory but the process isn't allowed to perform that type of instruction on it, e.g. a store in a read-only page), or succeeds. If it succeeds, the physical address is handed to the cache hardware, which tells the memory controller to fetch the appropriate cache line, or, on a processor without caches, the physical address is handed directly to the memory controller. Guy Harris 18:08, 22 July 2007 (UTC)

Perhaps they should reference each other to point out that they are distinct in function and to detail how they are different. —Preceding unsigned comment added by 75.117.108.144 (talk) 05:28, 17 August 2010 (UTC)

Reorder the different examples of MMUs in chronological order?

I feel that the order of the MMU examples section is the order that they were added which does not make much sense. It implies that the Dec Alpha was the most significant MMU and the IBM 370 was the least significant. Would it make sense to reorder the different examples in chronological order? I think the order would be:
IBM System/370
VAX
Sun 1 MMU
x86
DEC Alpha
PowerPC
x86-64
Any comments? Is this the correct chronological order? Is there a more logical order? I will do this in a week unless someone objects. Robert.harker (talk) 06:26, 25 April 2008 (UTC)

Maybe it would be better to sort it from the simplest and most comprehensible -> the most complicated. This would me much more useful for a reader. --Kubanczyk (talk) 07:30, 25 April 2008 (UTC)

Definitely. The Dec Alpha is very easy to understand; it should go first. —Preceding unsigned comment added by 71.43.244.114 (talk) 02:58, 8 October 2008 (UTC)

Can you make a stab at creating this order? I feel the different sctions are of different levels of detail so I do not feel that depth of section is the same as MMU complexity. Chronological order is simple and better than the current order. If you have a better idea, I have no objection.Robert.harker (talk) 09:40, 25 April 2008 (UTC)

Done --Kubanczyk (talk) 10:13, 25 April 2008 (UTC)

Better order: start with a CPU that is really bland yet feature-complete, without a lot of strange stuff that OSes don't need. Nothing is easier than the DEC Alpha. It's just a simple traditional page table tree, nothing else. 208.118.18.233 (talk) 02:59, 27 November 2010 (UTC)

Is Alpha just a single level of tables? Most 32 bit systems use two levels of tables. IBM S/370 and XA/370 use segment and page tables, while VAX uses two levels of page tables (in different address spaces). IBM z/Architecture for 64 bits uses a five level table, with special bypass until real memory gets bigger. Gah4 (talk) 06:19, 9 June 2017 (UTC)

"Alpha" isn't any single thing; the TLB is implemented in hardware, but page table walks are implemented in PALcode, to which page table misses trap. The page table tree format depends on which PALcode is running; there's OpenVMS PALcode, there's DEC OSF/1^W^WDigital UNIX^W^WTru64 UNIX PALcode, and Windows NT PALcode. OpenVMS PALcode and Tru64 UNIX PALcode have a 3-level page table; Windows NT PALcode has a 1-level or 2-level page table. I have the impression that, at some point, they may have added Linux PALcode rather than having Linux use the Tru64 UNIX PALcode. Guy Harris (talk) 07:23, 9 June 2017 (UTC)

In that case, it seems to me that the two level tables of S/370 or VAX would be simpler to describe. Gah4 (talk) 15:33, 9 June 2017 (UTC)

ThanksRobert.harker (talk) 10:20, 25 April 2008 (UTC)

uClinux without MMU

The uClinux wikipedia entry talks about uClinux as a derivative of Linux without an MMU. Perhaps some mention/discussion/reference to this would be useful in this MMU entry? ~~ — Preceding unsigned comment added by 80.4.63.73 (talk) 14:48, 14 January 2014 (UTC)

I'm not sure why it's worth mentioning, on the page for something, OSes that don't use the item in question. Guy Harris (talk) 19:14, 14 January 2014 (UTC)

Then the CP/M would also be worth mentioning... It also used no MMU. :) — Dsimic (talk) 23:21, 15 January 2014 (UTC)

Strictly, that's wrong :-) CP/M-80 as shipped by DR didn't use an MMU, but other members of the family did: starting off with MP/M-80 and continuing to (in particular) versions of MDOS which provided a reasonable multitasking wrapper around standard DOS programs. Also there were various "clones": memory is cloudy, but I think some of these could page when running on things like the 64180 chip. MarkMLl (talk) 08:56, 5 March 2014 (UTC)

Wow, that's great to know, thank you! As a side note, it's amazing how much effort went into a basically crippled program loader called DOS. Even more, the effort is still there, a lot of people seem to be keeping alive Clipper- or dBase-based software. — Dsimic (talk | contribs) 02:21, 6 March 2014 (UTC)

B5000

Overall, a most excellent article: it's nice to see something looking at the "big picture" rather than focussing on PCs or on a single legacy architecture.

There's one detail about the discussion of the B5000 that troubles me, but I can't see an easy way of working it into the article without detracting from the overall point being made. The B5000, B5500 and B5700 had a separate set of "stream" instructions for operating on character data, while one of these was executing it stored absolute addresses which made it difficult to relocate/defragment memory and also there was very limited protection: they were exposed to even student programmers in the original Burroughs ALGOL and reportedly a mistake could wipe the entire content of system memory. On those systems, security and robustness came from the languages being used (i.e. extremely limited availability of assembler and pointers) and were further enforced by the fact that user-level languages couldn't generate code to e.g. access security information on disc. MarkMLl (talk) 08:56, 5 March 2014 (UTC)

As far as I know, the B5000 and B5500 are single task machines. I am not so sure about system memory, but in many machines of the time there was no "system memory". I suspect that the machines you are thinking about are the 6500 and follow-ons. There are some where memory protection depends on the compiler not to allow compiled programs to reference where they aren't supposed to, and that only programs produced by that compiler can be run. (No downloading apps and running them.) It was usual at the time (and still is) for Fortran not to bounds check arrays. It might be that B5000 ALGOL did do bounds checking. Gah4 (talk) 21:37, 8 March 2017 (UTC)

Oh, the first and last times that I ran programs on the B5500 were in 1967, when I was nine years old. Gah4 (talk) 21:38, 8 March 2017 (UTC)

I think the MCP was multi-tasking from Day One, so, yeah, not as much purely-hardware security as some might like with the B5000 and its successors. I presume the 48 data bits/3 tag bits structure of the B6500 and successors closes that hole.

As for array bounds checking, array accesses were probably done in "word mode" through descriptors, so bounds checking would be done by the hardware. Guy Harris (talk) 21:27, 12 July 2023 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on Memory management unit. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20070927190743/http://users.ipa.net/~dwighth/smalltalk/byte_aug81/design_principles_behind_smalltalk.html to http://users.ipa.net/~dwighth/smalltalk/byte_aug81/design_principles_behind_smalltalk.html

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

Y An editor has reviewed this edit and fixed any errors that were found.

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 09:12, 8 June 2017 (UTC)

MIPS32 physical address space

"You have to distinguish between physical and virtual memory. The MIPS32 architecture supports implementations with up to 36 bits of physical address space, however the virtual address space in kernel and user mode is [32 bits]. One note: Many MIPS32 implementations choose not to implement all 36 PA bits, but limit themselves to 32 bits. This saves a few bits in the TLB and a few address lines."[1]

Author: Hartvig Ekner (MIPS Denmark)

--Guy Macon (talk) 16:23, 3 September 2018 (UTC)

Unisys MCP Systems (Burroughs B5000) flagged for clarification

The only other aspect is performance – do MMU-based or non-MMU-based systems provide better performance? MCP systems may be implemented on top of standard hardware that does have an MMU (for example, a standard PC). Even if the system implementation uses the MMU in some way, this will not be at all visible at the MCP level.

This entire narrative strikes me as having been crafted to evade the performance implications, which probably became completely non-viable at some point in 1970s, as cycle times continued to shrink.

I was already playing around with hand-wired CPU boards in the 1970s. I'm pretty good with ancient history. However, I did not manage to follow this particular narrative in one pass. Mostly by brow furrowed due to the tenuous implications.

I might have decoded this a bit more with a second studious pass, but then I arrived at the question-mark sentence above, and I decided that this needed to be fixed far more than it needed to be comprehended by doubling down. — MaxEnt 16:13, 17 September 2020 (UTC)

Levels of page tables

It seems that the article doesn't well discuss the multiple levels of tables commonly used. It mentions segmentation and paging, but again not so well. Processors like S/370 and VAX use two levels of tables, which S/370 calls segment and page tables. VAX has different memory regions, and calls them paging of page tables. This allows for reasonable sized tables in memory, along with the TLB to speed things up. With 64 bit addressing, systems are going to 5 levels. (At least IBM z/ systems use 5.) They then simplify things, so one really doesn't need to use all the levels, until memories get much bigger. Gah4 (talk) 11:47, 23 July 2023 (UTC)

I.e.,

The virtual page number may be directly used as an index into the page table or other mapping information, or it may be further divided, with bits at a given level used as an index into a table of lower-level tables into which bits at the next level down are used as an index, with two or more levels of indexing.

needs expansion?

Yes, VAX's three variable-length regions - two with fixed start addresses (P0, S) and one with a fixed end address (P1) - add an effective extra level to the page table, and the page tables for P0 and P1 living in virtual memory in S space adds another effective extra level. Guy Harris (talk) 19:22, 23 July 2023 (UTC)

These mapped only the upper 4 bits of the 20-bit address, and there was no equivalent of a limit, which was simply the lower 16-bits of the address and thus a fixed 64 kB.

It wasn't that long ago: These mapped only the upper 4 bits of the 20-bit address, and there was no equivalent of a limit, which was simply the lower 16-bits of the address and thus a fixed 64 kB. That isn't how segment registers work on the 8086 and 8088. Gah4 (talk) 05:24, 25 July 2023 (UTC)