上一节讲述了在没有MMU的CPU(如80251、MIPS M控制器系列、ARM cortex m系列)上实现虚拟内存管理的集成硬件设计方法。新设计的内存管理管理单元要实现虚拟内存管理还须要操作系统、代码分块(Bank)的支持。详见SoC嵌入式软件架构设计之二：没有MMU的CPU实现虚拟内存管理的设计方法。这里要阐述Bank设计的一些原则。

    Bank设计是为了实现不同一时候刻执行的Bank（代码块）执行在同一块内存上，所以在执行之前操作系统须要将已存在内存的代码/数据进行缓存处理，并载入将要执行的Bank到该内存上。为了实现这个目的，须要明白下面要点：

     1.为了提高效率。我们觉得代码是不会自改动的，即代码是仅仅读的，则在Bank切换的时候能够直接将已经存在内存的Bank代码丢弃。

我们仅仅须要将当前已经存在内存的Bank代码的Bank号入栈就可以。新载入的代码能够直接覆盖该块内存。

不同的Bank有不同的虚拟地址，为什么能够放到相同的物理内存？事实上是新设计的内存管理单元的电路决定的。參考前一节的文章（SoC嵌入式软件架构设计之二：没有MMU的CPU实现虚拟内存管理的设计方法）介绍，关键是同一个Bank组的不同虚拟地址信号相应的物理输出信号是一样的。

     2.程序调用后返回到一个Bank的某一行时相同须要载入该Bank代码，这时操作系统会将之前的Bank号出栈，并依据Bank号将相应的代码载入到该块内存。从1和2来看，调用Bank代码和返回一个Bank设计到Bank号的入栈和出栈，假设设计的Bank代码中的函数的虚拟执行地址带有明白的Bank号信息，那函数的调用和返回就是一个入栈和出栈过程。这样操作系统能够降低出入栈的工作，代码执行也更顺畅。

     3.Bank代码中的变量数据处理：

     1）全局变量。

假设全局变量定义在公共区域。那Bank代码切换过程中不需对其进行处理。

假设全局变量定义在Bank内存区域，则Bank切换时须要对这部分全局变量进行缓存处理。即在Bank号入栈之后，将Bank中的数据存到堆中。在Bank返回时除了从外存储设备载入相应的代码时，还要将其相应的数据从堆中恢复到Bank内存。为了加快数据的恢复。往往默认一个Bank数据空间的最大值。这样就不须要记录每一个Bank的数据空间的大小。

     2）静态变量。跟全局变量一样。

     3）常量段。其是仅仅读，跟代码一块处理。

     4）局部变量。局部变量是在栈中分配空间的，所以不须要进行缓存。

     5）buffer。假如该Buffer仅仅是某个Bank调用，而该Bank除了代码还有剩余空间大于buffer大小，那将buffer设置在代码段之后，并定义一个指针局部变量，程序中直接指向该buffer的首地址。

     假设我们将Bank内的全局变量所有转为局部变量，那操作系统就不须要对数据进行缓存管理，就不须要堆空间。可是局部变量相应的栈空间就加大了。一个Bank可能有多个函数。而多个函数是可能会用到相同的全局变量的。但这样的情况须要的全局变量往往不大，能够考虑都转为局部变量。

假设不须要进行数据缓存。那系统管理将会很easy。

     4.中断处理不能进行Bank切换。Bank切换须要进行读写外存储设备，会造成非常大的延时，所以在中断里面不应该产生Bank切换。

     5.操作系统、驱动、应用各层次频繁调用的代码应设置为常驻代码，假设发生切换会损失效率。

假设频繁调用的代码非常固定，如操作系统的调度管理等代码能够固化到ROM中，以降低成本。

     6.Bank内存分块大小要适中。在保持切换性能的基础上选择较小的内存块。

Bank块设置过小，就会导致Bank切换频繁，损失效率，Bank设置过大会造成内存浪费。

     7.Bank内存的起始地址应该对齐扇区（512字节）。这样读外存储设备可以达到最好的性能。

请关注SoC嵌入式软件架构设计（控制器SoC固件架构）系列博文：

SoC嵌入式软件架构设计之中的一个：系统内存需求评估 

SoC嵌入式软件架构设计之二：没有MMU的CPU实现虚拟内存管理的设计方法

SoC嵌入式软件架构设计之三：代码分块(Bank)设计原则

SoC嵌入式软件架构设计之四：内存空间规划分配

SoC嵌入式软件架构设计之五：可运行程序的重构

嵌入式：节省内存的软件设计技巧