#define switch_to(n) {\
struct {long a,b;} __tmp; \
__asm__("cmpl %%ecx,_current\n\t" \
"je 1f\n\t" \
"movw %%dx,%1\n\t" \
"xchgl %%ecx,_current\n\t" \
"ljmp %0\n\t" \ ---------此处发生长跳转时,ljmp怎么判断是切换呢?我看网上的资料是说
CPU发现那个描述符指向了TSS,他就知道了:哦,不是原来的简单地叫我跳转到某某地方去,而是叫我去进行任务切换啊,好的......
1.cpu怎么判断是指向描述符而不是个地址?
2.当进行切换的时候ldtr tsr 是硬件直接切过来的吗?怎么切的?推荐下资料
"cmpl %%ecx,_last_task_used_math\n\t" \
"jne 1f\n\t" \
"clts\n" \
"1:" \
::"m" (*&__tmp.a),"m" (*&__tmp.b), \
"d" (_TSS(n)),"c" ((long) task[n])); \
}
谢谢!
--
[m [31m※ 来源:·水木社区 http://newsmth.net·[FROM: 124.42.13.*] [m
--
[m [36m※ 来源:·水木社区 http://newsmth.net·[FROM: 61.148.56.*] [m
【 在 wangwoshida (落叶) 的大作中提到: 】
: ljmp和%0 告诉汇编器这是一个绝对间接32位远跳转,cpu会取48bit内存内容来查看是门还是tss还是其他。
-- 这里的话,cpu有相应的硬件逻辑进行处理? cs ds 等段寄存器,也是cpu根据gdt ldt,经过计算,相应赋值过去的吗?从推论上来说,好像是这样,不知道对不对,没找到资料证实。
: tr只是load tss选择子,ljmp tss才会切换现场。
--
[m [34m※ 来源:·水木社区 http://newsmth.net·[FROM: 124.42.13.*] [m
锟斤拷 锟斤拷 Joyong2006 (Tiger|yeah) 锟侥达拷锟斤拷锟斤拷锟结到: 锟斤拷
: linux 0.11锟斤拷
: #define switch_to(n) {\
: struct {long a,b;} __tmp; \
: ...................
--
[m [35m锟斤拷 锟斤拷源:锟斤拷水木锟斤拷锟斤拷 http://newsmth.net锟斤拷[FROM: 113.89.121.*] [m
--
[m [36m※ 来源:·水木社区 http://newsmth.net·[FROM: 61.148.56.*] [m
--
[m [37m※ 来源:·水木社区 http://newsmth.net·[FROM: 124.42.13.*] [m
【 在 wangwoshida (落叶) 的大作中提到: 】
: 看似一条宏指令,其实内部由很多微码序列构成,不是硬连逻辑直接处理,流水线上跑的是这些微码。cs ds的加载也由微码序列构成,这些微码有load,store,check,jmp,arith,io等等,就像个risc指令集
--
[m [1;35m※ 来源:·水木社区 newsmth.net·[FROM: 119.105.192.*] [m
--
[m [36m※ 来源:·水木社区 http://newsmth.net·[FROM: 113.89.121.*] [m
【 在 xiaoju (可爱的龙猫) 的大作中提到: 】
: CS和DS也许会对应完全同样的一个寄存器也说不定。
【 在 Bonaparte (苍天) 的大作中提到: 】
: 地址重映射,这是内存的事。X86的程序段寄存器和
: 数据段寄存器,不可能重映射的。
: 难道现在更新换代,还真的可以?
: ...................
--
[m [1;37m※ 来源:·水木社区 newsmth.net·[FROM: 119.105.192.*] [m
【 在 xiaoju (可爱的龙猫) 的大作中提到: 】
: 流水线分支预测不就是这么实现的吗?
--
[m [37m※ 来源:·水木社区 http://newsmth.net·[FROM: 113.89.121.*] [m
4.寄存器重命名技术
寄存器重命名,是CPU在解码过程中对寄存器进行重命名,解码器把“其它”的寄存器名字变为“通用”的寄存器名字,本质上是通过一个表格把x86寄存器重新映射到其它寄存器,这样可以让实际使用到的寄存器远大于8个。这样做的好处除了便于前面指令发生意外或分支预测出错时取消外,还避免了由于两条指令写同一个寄存器时的等待。
下面我们以一个超标量CPU执行8个算术指令为例:假设它在每个时钟周期中能对2个指令解码,引出计算结果是在指令发布后3个时钟周期发生的:
(1)在第1个时钟周期,两个指令发布:它们互不关联,因此,它们将在3个时钟周期后(第4个时钟周期)引出;
(2)在第2个时钟周期,我们首次遇到了“指令依赖”,指令3需要指令2的结果,此时指令3不能开始发布;
(3)如果是按序执行,指令4、5、6就不能在指令3前发布。只有在第5个时钟周期时(指令2的结果已得到)才能发布指令3;
(4)在第6个时钟周期有个大问题:我们想把结果写到寄存器R1,但这将改变指令5的结果。因此,我们只有在R1空闲时(第10个时钟周期)才能发布指令6。
按照正常情况处理的话,尽管这个CPU每个时钟周期可以对2个指令解码,但它每个时钟周期的指令执行数只有0.53。如果每次程序所需的寄存器正被使用,我们可以把数据放到其它的寄存器中,在第6个时钟周期将寄存器R1重命名,指令6和指令8不再耽误CPU的工作。结果是我们能够将每个时钟周期的指令执行数提高50%。寄存器重命名技术可以使x86 CPU的寄存器可以突破8个的限制,达到32个甚至更多。寄存器重命名技术现在已经深深地扎根于超标量CPU中了。
【 在 Bonaparte (苍天) 的大作中提到: 】
: 流水线分支预测,保存的是分支指令的预测与命中
: 历史。这用到了Icache,跟寄存器的重定向没有关系。
--
[m [1;31m※ 来源:·水木社区 newsmth.net·[FROM: 119.105.192.*] [m
--
[m [31m※ 来源:·水木社区 http://newsmth.net·[FROM: 113.89.121.*] [m
--
[m [32m※ 来源:·水木社区 http://newsmth.net·[FROM: 221.223.102.*] [m