关于32位os按“段寻址机制”最高64TB的“传说”

最新推荐文章于 2022-11-12 23:41:26 发布

skyair624

最新推荐文章于 2022-11-12 23:41:26 发布

阅读量1k

点赞数

文章标签： os

本文链接：https://blog.csdn.net/skyair624/article/details/5882861

版权

文章探讨了32位操作系统通过段管理机制理论上可达64TB虚拟地址空间的说法，分析了这一结论的计算依据，包括offset和base address的组合，以及寻址总线限制。同时指出，实际的32位CPU由于DPL和选择符占用部分位，导致可用地址空间并非64TB。作者认为这个说法存在误解，并引用相关链接进一步阐述原因。

摘要由CSDN通过智能技术生成

网上不少的资料上说32OS通过“段管理机制”最大的virtual address space可以达到64TB，这种结论我感觉完全是按照“实模式”的方式
   计算的来的。。。好先说下这是怎么计算来的：
                offset：32bits（4GB，注意这里是根据指针所占字节的大小而确定的，或者说按照EAX/EBX/ESP/EBP等等而“决定”的，（如果这里不太理解，想一下:mov [eax], 1234H;是的！寄存器间接寻址，如果超过32位INTEL这种指令可就失效了，万万不可！））
                base address：16bits（这里在“保护模式”下本来是用作“描述符索引”的，但是按照“实模式”理解，就可以做“base address”了）
                根据上面的解释（有一点需要注意！）：386前的CPU寻址总线是20条，所以只把base address的16bits整体左移4位，正好作为高20位（满足20位寻址，其实如果寻址总线可以达到32位的话，完全可以左移16位作为高16位，然后offset address作为低16位，满足32位寻址模式）
                继续根据上面的解释：base address中共16bits但是不是所有16个bit都用于做base address的，其中有3bits用于特殊用途：期中2bits用于表示DPL，1bit用于表示对GDT/LDT的选择
                                    因此，13+32 =45bits࿰