这些天需要评估一些硬件环境，和机顶盒公司的朋友接触时，突然发现自己在一个技术上的盲点：MMU(Memory ManageUnit)与多进程。

大学时，就听过MMU，但当时只是在助教那絮絮叨叨的讲解中得知这东西大概和内存有关。后来尝试自己写个类Linux(是想显示自己多牛B，后来才发现自己多水)。终于在分段和分页部分又见到MMU。大概理解了它是CPU提供的一种能力，通过它，就可以实现virtualmemory。可以以页面为单位将数据在硬盘和RAM之间交换。换句话说，它通过分段(X86)和分页将虚拟地址，线形地址，物理地址对应起来。让每个应用程序以为自己有很大内存可用。当某个应用程序真正运行时，对应页才会调入内存。所以，在virtualmemory的情况下，虚拟地址不是被直接送到内存地址总线上，而是送到存储器管理单元MMU，把虚拟地址映射为物理地址。

所以直观的认为，ARM7中很多型号，因为没有MMU,所以没有所谓virtualmemory.所以其线性地址与物理地址是一一对应的。所有程序跑在同一地址空间中。

今天和机顶盒公司的朋友交流中，突然听到因为他们某些产品不支持MMU，所以无法支持多进程。我一下无法将这两者对应起来。只好问了问Google老师。才明白过来：

MMU的功能：

1、将虚拟地址映射为物理地址

现代的多用户多进程操作系统，需要MMU, 才能达到每个用户进程都拥有自己独立的地址空间的目标。使用MMU,操作系统划分出一段地址区域, 在这块地址区域中, 每个进程看到的内容都不一定一样。例如MICROSOFTWINDOWS操作系统将地址范围4M-2G划分为用户地址空间，进程A在地址0X400000(4M)映射了可执行文件，进程B同样在地址0X400000(4M)映射了可执行文件，如果A进程读地址0X400000,读到的是A的可执行文件映射到RAM的内容，而进程B读取地址0X400000时，则读到的是B的可执行文件映射到RAM的内容。

这很好理解，因为A，B进程看到的都是虚拟地址，虚拟地址需要对应到线性地址，再映射到物理地址中。(注：线性地址好像是x86分段概念中独有的)。所以每个进程中看到的某个线性地址，经过MMU转换，最终这个地址根本不在同一个页中。所以不相同。

如果有了硬件MMU，可以为每个进程建立一个独立空间的页表项，调度时就可以方便的切换。

2.提供硬件机制的内存访问授权：

这一块就不是很清楚，记得这是在GDT，LDT中保护的啊。

CPU与MMU：

x86系统的CPU，基本全部包括MMU。 (它好像有个特有的分段机制)

ARM出品的CPU，MMU作为一个协处理器存在。根据不同的系列有不同搭配。需要查询DATASHEET才可知道是否有MMU。如果有的话，一定是编号为15的协处理器。可以提供32BIT共4G的地址空间。

ARM7 没有没有MMU， 但ARM9 将MMU包到核中去了。

uclinux,uc/os-II与MMU：

uclinux中MM部分作了很大修改，uClinux针对noMMU处理器开发，所以被迫使用一种flat方式的内存管理模式，启动新的应用程序时系统必须为应用程序分配存储空间，并立即把应用程序加载到内存。缺少了MMU的内存重映射机制，uClinux必须在可执行文件加载阶段对可执行文件reloc处理，使得程序执行时能够直接使用物理内存。

uc/os-II则根本没有进程概念，只有Task，在Task开始工作时，已经将物理内存分配给它了。

回归主题：

如果某个CPU不支持MMU，则对应OS(例如：ucLinux)则无法做到将几个程序所用页面分别从硬盘到RAM的交换。并且每个程序在启动时，就需要给它分配足RAM。

补充：

现代OS是利用MMU的特性才能达到每个用户进程都拥有自己独立的地址空间的目标。没有MMU，这些OS就无法实现这个基本功能。于是就有了uclinux这样的针对NoMMU的OS。

另外，类似UC/OS-II这样的操作系统。则将OS与Task合为一体，共用同一个地址空间。也无所谓内核空间和用户空间。所以如果你认为它也可也叫多进程，这也算可以吧。

当然，公平的说，MMU并不完全是多进程的必备条件，只是帮助OS实现多进程。