Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

进程切换请教

17 views
Skip to first unread message

Tiger|yeah

unread,
Jun 22, 2010, 3:08:55 AM6/22/10
to
linux 0.11中

#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

落叶

unread,
Jun 22, 2010, 4:19:59 AM6/22/10
to
ljmp和%0 告诉汇编器这是一个绝对间接32位远跳转,cpu会取48bit内存内容来查看是门还是tss还是其他。
tr只是load tss选择子,ljmp tss才会切换现场。
【 在 Joyong2006 (Tiger|yeah) 的大作中提到: 】
: linux 0.11中

: #define switch_to(n) {\
: struct {long a,b;} __tmp; \
: ...................

--

[m [36m※ 来源:·水木社区 http://newsmth.net·[FROM: 61.148.56.*] [m

Tiger|yeah

unread,
Jun 22, 2010, 9:28:37 PM6/22/10
to
谢谢!


【 在 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

����

unread,
Jun 24, 2010, 8:29:20 AM6/24/10
to
锟斤拷确锟斤拷锟斤拷锟斤拷锟斤拷锟角帮拷CPU锟节核猴拷锟节达拷锟斤拷?元锟街匡拷锟斤拷
CPU每锟轿访存,锟节达拷锟斤拷?元锟斤拷锟斤拷锟斤拷锟街纷拷锟斤拷锟皆斤拷锟斤拷
锟介,锟节达拷时锟节达拷锟斤拷?元锟斤拷锟斤拷知锟斤拷锟斤拷锟斤拷通锟斤拷址锟斤拷锟斤拷锟斤拷
锟斤拷锟斤拷锟剿★拷
锟斤拷些锟斤拷锟斤拷锟斤拷80x86锟斤拷锟斤拷模式锟斤拷锟斤拷锟斤拷应锟矫讹拷锟斤拷说锟斤拷锟斤拷

锟斤拷 锟斤拷 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

落叶

unread,
Jun 25, 2010, 12:40:15 AM6/25/10
to
看似一条宏指令,其实内部由很多微码序列构成,不是硬连逻辑直接处理,流水线上跑的是这些微码。cs ds的加载也由微码序列构成,这些微码有load,store,check,jmp,arith,io等等,就像个risc指令集

【 在 Joyong2006 (Tiger|yeah) 的大作中提到: 】
: 谢谢!
: -- 这里的话,cpu有相应的硬件逻辑进行处理? cs ds 等段寄存器,也是cpu根据gdt ldt,经过计算,相应赋值过去的吗?从推论上来说,好像是这样,不知道对不对,没找到资料证实。

--

[m [36m※ 来源:·水木社区 http://newsmth.net·[FROM: 61.148.56.*] [m

Tiger|yeah

unread,
Jun 25, 2010, 12:52:05 AM6/25/10
to
谢谢!
【 在 wangwoshida (落叶) 的大作中提到: 】
: 看似一条宏指令,其实内部由很多微码序列构成,不是硬连逻辑直接处理,流水线上跑的是这些微码。cs ds的加载也由微码序列构成,这些微码有load,store,check,jmp,arith,io等等,就像个risc指令集

--

[m [37m※ 来源:·水木社区 http://newsmth.net·[FROM: 124.42.13.*] [m

Tiger|yeah

unread,
Jun 25, 2010, 12:52:26 AM6/25/10
to
谢谢,我查下手册
【 在 Bonaparte (苍天) 的大作中提到: 】
: 正确的做法,是把CPU内核和内存管理单元分开。
: CPU每次访存,内存管理单元都负责地址转换和越界检
: 查,在此时内存管理单元就能知道是普通地址还是描
: ...................

可爱的龙猫

unread,
Jun 25, 2010, 7:35:18 AM6/25/10
to
CS和DS也许会对应完全同样的一个寄存器也说不定。

【 在 wangwoshida (落叶) 的大作中提到: 】
: 看似一条宏指令,其实内部由很多微码序列构成,不是硬连逻辑直接处理,流水线上跑的是这些微码。cs ds的加载也由微码序列构成,这些微码有load,store,check,jmp,arith,io等等,就像个risc指令集


--

[m [1;35m※ 来源:·水木社区 newsmth.net·[FROM: 119.105.192.*] [m

苍天

unread,
Jun 25, 2010, 8:33:38 AM6/25/10
to
Intel的CISC指令通过分解为RISC微码来执行,这是人尽皆
知的事情。
RISC处理器也是通过内存管理单元的硬件逻辑来实现任务切
换所需的地址隔离的相关操作。我还未见过有哪款处理器用元指
令来完成虚实地址转换,页表类型判断,地址越界判断的。
CPU内核都是设计得尽量简单,尽量模块化,只实现流水地执
行指令的功能。


【 在 wangwoshida (落叶) 的大作中提到: 】
: 看似一条宏指令,其实内部由很多微码序列构成,不是硬连逻辑直接处理,流水线上跑的是这些微码。cs ds的加载也由微码序列构成,这些微码有load,store,check,jmp,arith,io等等,就像个risc指令集

--

[m [36m※ 来源:·水木社区 http://newsmth.net·[FROM: 113.89.121.*] [m

苍天

unread,
Jun 25, 2010, 8:38:48 AM6/25/10
to
地址重映射,这是内存的事。X86的程序段寄存器和
数据段寄存器,不可能重映射的。
难道现在更新换代,还真的可以?

【 在 xiaoju (可爱的龙猫) 的大作中提到: 】
: CS和DS也许会对应完全同样的一个寄存器也说不定。

可爱的龙猫

unread,
Jun 25, 2010, 10:21:50 AM6/25/10
to
流水线分支预测不就是这么实现的吗?

【 在 Bonaparte (苍天) 的大作中提到: 】
: 地址重映射,这是内存的事。X86的程序段寄存器和
: 数据段寄存器,不可能重映射的。
: 难道现在更新换代,还真的可以?
: ...................

--

[m [1;37m※ 来源:·水木社区 newsmth.net·[FROM: 119.105.192.*] [m

苍天

unread,
Jun 25, 2010, 10:35:15 PM6/25/10
to
流水线分支预测,保存的是分支指令的预测与命中
历史。这用到了Icache,跟寄存器的重定向没有关系。

【 在 xiaoju (可爱的龙猫) 的大作中提到: 】
: 流水线分支预测不就是这么实现的吗?

--

[m [37m※ 来源:·水木社区 http://newsmth.net·[FROM: 113.89.121.*] [m

可爱的龙猫

unread,
Jun 25, 2010, 10:55:22 PM6/25/10
to
http://article.wxiu.com/yjwx/cpu/200907/09-5901.html

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

苍天

unread,
Jun 26, 2010, 1:49:00 AM6/26/10
to
谢谢分享
【 在 xiaoju (可爱的龙猫) 的大作中提到: 】
: http://article.wxiu.com/yjwx/cpu/200907/09-5901.html

: 4.寄存器重命名技术
: 寄存器重命名,是CPU在解码过程中对寄存器进行重命名,解码器把“其它”的寄存器名字变为“通用”的寄存器名字,本质上是通过一个表格把x86寄存器重新映射到其它寄存器,这样可以让实际使用到的寄存器远大于8个。这样做的好处除了便于前面指令发生意外或分支预测出错时取消外,还避免了由于两条指令写同一个寄存器时的等待。
: ...................

--

[m [31m※ 来源:·水木社区 http://newsmth.net·[FROM: 113.89.121.*] [m

Tiger|yeah

unread,
Jun 27, 2010, 12:39:57 PM6/27/10
to
谢谢

【 在 xiaoju (可爱的龙猫) 的大作中提到: 】
: http://article.wxiu.com/yjwx/cpu/200907/09-5901.html
: 4.寄存器重命名技术
: 寄存器重命名,是CPU在解码过程中对寄存器进行重命名,解码器把“其它”的寄存器名字变为“通用”的寄存器名字,本质上是通过一个表格把x86寄存器重新映射到其它寄存器,这样可以让实际使用到的寄存器远大于8个。这样做的好处除了便于前面指令发生意外或分支预测出错时取消外,还避免了由于两条指令写同一个寄存器时的等待。
: ...................

--

[m [32m※ 来源:·水木社区 http://newsmth.net·[FROM: 221.223.102.*] [m

0 new messages