對(duì)于x86_64來(lái)說(shuō)，邏輯地址由16位選擇子和64位偏移量組成(而32位時(shí)，邏輯地址由16位段選擇符和32位偏移量組成)，段寄存器僅僅存放選擇子。CPU的分段單元(SU)執(zhí)行以下操作：
[1] 先檢查選擇子的TI字段，以決定描述子對(duì)應(yīng)的描述子保存在哪一個(gè)描述符表中。TI字段指明描述子是在GDT中（在這種情況下，分段單元從gdtr寄存器中得到GDT的線性基地址）還是在激活的LDT中（在這種情況下，分段單元從ldtr寄存器中得到LDT的線性基地址）。
[2] 從選擇子的13位index字段計(jì)算描述子的地址，index字段的值乘以8（一個(gè)描述子的大小，其實(shí)就是屏蔽掉末尾那三位指示特權(quán)級(jí)的CPL和指示TI的字段），這個(gè)結(jié)果與gdtr或ldtr寄存器中的內(nèi)容相加。
[3] 將對(duì)應(yīng)的段描述子從內(nèi)存拷貝到CPU的影子Cache中，這樣，只有在選擇子改變的情況下才會(huì)修改影子Cache中的內(nèi)容。
[4] 把虛擬地址的偏移量與隱Cache中描述符Base字段的值相加就得到了線性地址。
雖然邏輯地址擴(kuò)展到了64位，但是，現(xiàn)有的設(shè)計(jì)并沒(méi)有完全用到這64位的空間（2^64=16EB），因?yàn)槭褂玫饺绱舜蟮目臻g，勢(shì)必造成很大的 系統(tǒng)開(kāi)銷(xiāo)。AMD64在設(shè)計(jì)的時(shí)候就決定在x86_64的第一階段，只用這64位中的低48位來(lái)做頁(yè)式地址轉(zhuǎn)換，高16位（48-64位）將填充第47位相同的內(nèi)容（這種方式類(lèi)似于符號(hào)擴(kuò)展）。 如果邏輯地址不符合此規(guī)定，系統(tǒng)將產(chǎn)生異常。符合此規(guī)定的地址稱為canonical form，地址的范圍分為兩段：0 到 00007FFF-FFFFFFFF，以及FFFF8 000-0000 0000到FFFFFFFF-FFFFFFFF，總共為256TB。 這種虛擬地址的分層結(jié)構(gòu)，也為操作系統(tǒng)的設(shè)計(jì)帶來(lái)了一定便利：可以取地址的上半段保留做為操作系統(tǒng)的邏輯地址空間，而低地址部分做為裝載應(yīng)用程序的空間， 而canonical form不允許的地址空間則做為操作系統(tǒng)的標(biāo)志、以及特權(quán)級(jí)的標(biāo)識(shí)等。當(dāng)然，這樣的設(shè)計(jì)在未來(lái)地址進(jìn)一步擴(kuò)展的時(shí)候?qū)⒊蔀橐粋€(gè)新的問(wèn)題。
可以想象，用到48位的x86-64虛擬地址的分配機(jī)制為：
- 0－11（12）位：頁(yè)內(nèi)偏移；
- 12－20（9）位：由PML4來(lái)映射；
- 21－29（9）位：高一級(jí)頁(yè)目錄來(lái)映射（如果PS＝1，則該頁(yè)表項(xiàng)指向一個(gè)2MB的頁(yè)）；
- 30－38（9）位：再高一級(jí)的頁(yè)目錄來(lái)映射（如果PS=2，則該頁(yè)表項(xiàng)指向一個(gè)1GB的頁(yè)）；
- 39－47（9）位：頁(yè)目錄指針表來(lái)映射。
其虛擬地址空間布局如下：
0000000000000000 - 00007fffffffffff (=47 bits) user space, different per mm hole caused by [48:63] sign extension ffff800000000000 - ffff80ffffffffff (=40 bits) guard hole ffff880000000000 - ffffc7ffffffffff (=64 TB) direct mapping of all phys. memory ffffc80000000000 - ffffc8ffffffffff (=40 bits) hole ffffc90000000000 - ffffe8ffffffffff (=45 bits) vmalloc/ioremap space ffffe90000000000 - ffffe9ffffffffff (=40 bits) hole ffffea0000000000 - ffffeaffffffffff (=40 bits) virtual memory map (1TB) ... unused hole ... ffffffff80000000 - ffffffffa0000000 (=512 MB) kernel text mapping, from phys 0 ffffffffa0000000 - fffffffffff00000 (=1536 MB) module mapping space
x86-64的長(zhǎng)模式下，對(duì)16位以及32位代碼進(jìn)行了兼容，即使CPU上跑的是64位的操作系統(tǒng)，歷史遺留的16位以及32位代碼將都能夠在該操作系統(tǒng)上運(yùn)行。 由于x86-64兼容IA32的指令，所以，這些代碼在這種情況下運(yùn)行，基本上沒(méi)有性能損耗。
在傳統(tǒng)模式（Legacy mode）下，x86-64的CPU的工作模式跟傳統(tǒng)的IA32沒(méi)有什么兩樣。
分類(lèi): 內(nèi)存管理
延伸閱讀
- Python-Flask：利用flask_sqlalchemy實(shí)現(xiàn)分頁(yè)效果 2017-07-25
- TCP連接中time_wait在開(kāi)發(fā)中的影響-搜人以魚(yú)不如授之以漁 2017-07-21
- MyBatis-sql映射文件 2017-07-21
- Python內(nèi)存管理機(jī)制 2017-07-21
- hibernate之映射文件VS映射注解 2017-07-20
- STL—內(nèi)存的配置與釋放 2017-07-18
- Spark的誤解-不僅spark是內(nèi)存計(jì)算，hadoop也是內(nèi)存計(jì)算 2017-07-18
- Android系統(tǒng)--輸入系統(tǒng)（十五）實(shí)戰(zhàn)_使用GlobalKey一鍵啟動(dòng)程序 2017-07-16
- 內(nèi)存對(duì)齊小解 2017-07-16
- 內(nèi)存對(duì)齊小解 2017-07-16
TCP連接中time_wait在開(kāi)發(fā)中的影響-搜人以魚(yú)不如授之以漁