一些个人的思考:收索引擎与保护模式下的物理地址生成
2010-03-23 21:26
260 查看
最近在学汇编和操作系统,感觉操作系统底层对存储这一快设计的特别有意思,特别是保护方式下物理地址的生成,觉得和搜索引擎有些相似的地方。
就存储而言,在保护模式下,段寄存器内不再是保存段的首地址,而是指出从描述符表中选择相应段描述符的方式,通俗的说就是保存一个索引,这个索引指向的是描述符,描述有关段的信息,例如段界限,段基地址,段的大小,段的类型……。而段寄存器中有16位用了13位来表示描述符索引,那么就有2^13个,也就是8192个描述符,描述符又分成全局与局部,那就有8192*2个描述符。每个描述符有记录着一个段的信息,如果就当前仅是分段的形式,因为段界限是20位,那么其所指向的段的最大偏移量应该是2^20就是1MB,那么总共可以达到2^13*2*2^20貌似达到了TB级 而一个内存最大不超过4G,从4G可以扩张到TB级,可见这样设计带来了那么多的好处。。。
而巧合的是,网上的信息是很多的,搜索引擎也是通过建立索引,通过倒排方式,才能使能在短时间内从海量的信息库中提取出用户需要的信息。。。
看来索引这东西挺好的,能指向一个远远大于这个索引大小的大量的信息,然后通过索引找到完整的信息,从而提高了效率。
这只是今天上完汇编课后,自己写的,也许有些错误,希望有高手看到的话不要介意,如果可以的话,也希望读者能纠正文中的错误。
就存储而言,在保护模式下,段寄存器内不再是保存段的首地址,而是指出从描述符表中选择相应段描述符的方式,通俗的说就是保存一个索引,这个索引指向的是描述符,描述有关段的信息,例如段界限,段基地址,段的大小,段的类型……。而段寄存器中有16位用了13位来表示描述符索引,那么就有2^13个,也就是8192个描述符,描述符又分成全局与局部,那就有8192*2个描述符。每个描述符有记录着一个段的信息,如果就当前仅是分段的形式,因为段界限是20位,那么其所指向的段的最大偏移量应该是2^20就是1MB,那么总共可以达到2^13*2*2^20貌似达到了TB级 而一个内存最大不超过4G,从4G可以扩张到TB级,可见这样设计带来了那么多的好处。。。
而巧合的是,网上的信息是很多的,搜索引擎也是通过建立索引,通过倒排方式,才能使能在短时间内从海量的信息库中提取出用户需要的信息。。。
看来索引这东西挺好的,能指向一个远远大于这个索引大小的大量的信息,然后通过索引找到完整的信息,从而提高了效率。
这只是今天上完汇编课后,自己写的,也许有些错误,希望有高手看到的话不要介意,如果可以的话,也希望读者能纠正文中的错误。
相关文章推荐
- 关于windows保护模式的一些个人见解
- 保护模式之大观--查找物理地址
- 保护模式之大观--查找物理地址
- 80X86的物理地址形成(实模式+保护模式)——段式寻址
- x86 cpu 32位,保护模式下,EIP寄存器存放的是线性地址还是物理地址
- 80X86的物理地址形成(实模式+保护模式)——段式寻址
- 80x86的保护虚地址模式
- php中soap 的使用实例和一些个人看法!亲测,无需手写WSDL文件,提供自动生成WSDL文件类
- 虚拟地址转译成物理地址 双机模式手动查找
- 设计模式之Builder (创建者模式)的一些个人理解(转)
- 保护模式、实地址模式及V8086模式下的指令格式(下)
- 关于企业应用SAP成本管理模式与方法的一些思考
- Ophone平台2D游戏引擎实现——物理引擎(一)(二)个人整理
- 用页面模板引擎生成站点的一些观点
- 设计模式,面向对象的一些思考
- 80x86的保护虚地址模式
- 一些个人的思考
- 关于Windows和Linux设计哲学的一些个人思考
- 缓存key生成策略的一些思考
- MVP模式重用性的一些思考