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

    上一节讲述了在没有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可能有多个函数，而多个函数是可能会用到同样的全局变量的。但这种情况需要的全局变量往往不大，可以考虑都转为局部变量。如果不需要进行数据缓存，那系统管理将会非常简单。

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

     5.操作系统、驱动、应用各层次频繁调用的代码应设置为常驻代码，如果发生切换会损失效率。如果频繁调用的代码很固定，如操作系统的调度管理等代码可以固化到ROM中，以减少成本。

     6.Bank内存分块大小要适中，在保持切换性能的基础上选择较小的内存块。Bank块设置过小，就会导致Bank切换频繁，损失效率，Bank设置过大会造成内存浪费。

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

 

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

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

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

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

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

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

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