Talk:Memory management unit

message: 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 2N.
- 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<SMALL>*</SMALL> 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)
thread_title:  Untitled section 

message: What are FS and GS? --Abdull 07:13, 28 March 2007 (UTC)
replies: text: They are segment registers. -- intgr 07:28, 28 March 2007 (UTC)
thread_title:  FS and GS 

message: 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)
replies: text: 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)
thread_title:  Memory Management Unit vs. Memory Controller 

message: 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)
replies: text: 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)
replies: text: 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)

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

text: 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)
replies: text: 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)
replies: text: "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)
replies: text: 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)
thread_title:  Reorder the different examples of MMUs in chronological order? 

message: 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)
replies: text: 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)
replies: text:  Then the CP/M would also be worth mentioning...  It also used no MMU. :) — Dsimic (talk) 23:21, 15 January 2014 (UTC)
replies: text:  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)
replies: text:  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)
thread_title:  uClinux without MMU 

message: 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.
Cheers.—InternetArchiveBot (Report bug) 09:12, 8 June 2017 (UTC)
thread_title:  External links modified 

message: "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."
Author: Hartvig Ekner (MIPS Denmark)
--Guy Macon (talk) 16:23, 3 September 2018 (UTC)
thread_title:  MIPS32 physical address space 

message: 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)
thread_title:  Unisys MCP Systems (Burroughs B5000) flagged for clarification 

message: 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)
thread_title:  ''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.''