陷入处理程序的入口都为“trap”(这里是指一个汇编程序,而非PDP11指令);
中断则不同。他们有不同的入口,如:
525 .=60^. 当前地址设置为60 octal
526 klin; br4 /(中断矢量地址为60,电传打字机输入的中断处理程序)
527 klou; br4 /(中断矢量地址为64,电传打字机输出的中断处理程序)
但是,如果接着往下看,你会发现所有的中断处理程序都指向了同一个入口“call”:
0557: .globl _klrint
0558: klin: jsr r0,call; _klrint
0559:
0560: .globl _klxint
0561: klou: jsr r0,call; _klxint
更进一步的,你会发现,陷入程序的入口“trap”在执行了少许操作之后,就会跳到“call”,
也就是说陷入和中断的处理程序入口最终合二为一。
如果“前状态”为user态,则“call”在785行跳到真正的处理程序:
0785: jsr pc,*(r0)+
否则,则会在0799行进行这样的操作:
0799 jsr pc,*(r0)+
对陷入来说,这个处理程序必然是trap函数(2693,c语言函数)——0762的jsr指令将_trap送入了r0:
0762: jsr r0,call1; _trap
而中断则为不同的中断处理程序,如电传打字机输入:
0558: klin: jsr r0,call; _klrint 打字机输入的中断处理程序:klrint
对于“前状态”为user态的进程来说,从中断和陷入处理程序返回后,还会执行一项非常重要的操作,即
会检查runrun标志,如此时有更高优先级的进程,则调用swtch()切换进程。因此,中断(陷入)处理程序
为“前状态为user态”的进程提供了一个进程切换的时机。
为何对“前状态”为核心态的程序不提供进程切换的机会呢?前面其实已经说明了原因,
还记得那个原则末——减少内核态的进程切换,以减少内核数据结构冲突的可能。
最后,通过“rtt”指令恢复pc和PS,即回到中断(陷入)前的情形。
莱昂的10.4小节对trap和call程序有很细致的描述,但可能仍有部分读者对Return部分有疑问。其实,最好的方法
是拿出纸笔,画一画前后的栈图——你一定会一目了然。这里,我给出一种调用情况的栈图,以供参考:
【情况说明】:User态进程中断,进入call例程 ---- 返回call例程----直接retrun回user态(runrun == 0)
栈图还能帮助我们理解Trap入口处那个诡异的操作(0756: mov PS,-4(sp))。
假设中断发生,中断矢量指向Trap,且nofault为0。
可见,自此Trap和Call拥有了相同的栈结构,并开始复用后面的代码。
需要特别注意的是:
New PS 的low 5 bit,在trap例程中才有意义,可以用来区分中断原因。
512 Trap; br7+0; /bus error
513 Trap; br7+1; /illegal instruction
514 Trap; br7+2; /bpt trace trap
515 Trap; br7+3;
….
显然,不同的中断使用不同的PS,而br7+n中的n即构成new PS的low 5 bit——即中断原因。
博客地址:http://blog.csdn.net/cszhao1980
博客专栏地址:http://blog.csdn.net/column/details/lions-unix.html