上一節講述了在沒有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嵌入式軟件架構設計之二：沒有MMU的CPU實現虛擬內存管理的設計方法