rel="file-list" href="file:///c:%5cdocume%7e1%5cadmini%7e1%5clocals%7e1%5ctemp%5cmsohtml1%5c03%5cclip_filelist.xml">
越是相近的東西，越是容易混淆；反倒是不同的特徵，容易描述清楚。既如此，我就從簡到難，先來講講記憶體布局的區別吧。
首先是經典的
ce 5
記憶體布局：
嗯，的確是非常經典的記憶體對映方式。任何乙個
arm程式設計師，即便沒有接觸過
wince
，也很容易理解這張圖。它簡直就是為
arm度身訂製的！ 總共
4gb的虛擬空間，最低的
1gb被分割成
32個槽
(slot)
，每個槽容納乙個程序，因此，每個程序可用的最大虛擬空間是
32mb
（當然，這個
32mb
的上限很像
nba的工資帽，只要動些腦筋，找些特例，總可以超過這個界限）。
slot 0
對應當前程序，
slot 1
中沒有程序，
ce 5
把系統預製的
dll放在這個區域。從
slot 2
開始，每個
slot
被唯一地對映到乙個程序，一般來講，按照啟動順序，依次是
filesys.exe, device.exe, gwes.exe
等等。需要注意的是，
ce 5
是很典型的微核心結構，因此，各種系統呼叫被區分成不同的服務，由各個應用程式提供。比如檔案系統的呼叫，就是由
filesys.exe
提供。雖然這些程式提供的是系統服務，但是從核心的角度來講，稱它們為應用程式是十分恰當的，因為他們的的確確執行在使用者態中。
1gb到2gb
的記憶體是共享的。
2mb以上的記憶體塊分配，記憶體對映檔案等，都在這裡發生。
2gb到3gb
的記憶體是靜態對映的。這意味著，在任何時候，這段記憶體對映都是不變的。其中較低的一半位址，
0x80000000 – 0x9fffffff
，是cacheable
；而另一半，則是
uncacheable
的。定製
ce的開發人員，需要建立乙個陣列，指明
cacheable
的位址，是如何對映到系統的物理記憶體空間的，並把這個陣列傳遞給
ce核心。核心會自動建立
uncacheable
的位址，對映方式恰好等於前者加上
0x20000000。
0xc0000000
以上的空間完全被核心**和資料結構使用。雖然微軟把核心稱為乙個程序，而且也確實把它放在程序陣列的第
0個元素，但說實話，我還是不願意把核心理解為乙個程序。在核心位址中，比較有趣的是一些非常非常高的位址，大約是
0xfffd0000
以上的位址，這裡放置了中斷向量、頁表等關鍵的結構，很值得仔細**一下。
好了，這就是
ce 5
的大致記憶體布局了。下次和
ce 6
對比一下！
S5PV210的記憶體對映
s5pv210是基於arm crotex a8架構32位cpu的微處理器。內部擁有32根位址線和32位資料線，32根位址線決定了cpu的位址空間最大為4g，這4g的記憶體空間如何分配，就是記憶體對映 s5pv210 datasheet中section 01 02章節 memory map有講。記憶體...
gem5記憶體對映原始碼
gem5 se模式中，進行物理記憶體分配的時候，實現了簡單的虛擬位址到物理位址對映機制 在src mem page table.cc中是具體的函式 在src sim process.cc中呼叫page table.cc中的map函式新增實體地址到虛擬位址的對映 process allocatemem...
Linux記憶體對映
使用記憶體對映處理大檔案很方便，在windows系統中，實現了這樣的藉口。在linux中我們也可以通過mmap函式來實現。以下內容完全參考自 如有冒犯，請諒解 mmap函式實現把乙個檔案對映到乙個記憶體區域，從而我們可以像讀寫記憶體一樣讀寫檔案，他比單純呼叫read write也要快上許多。在某些時...