一，前言

每次学习os我最感兴趣的就是任务切换，不是说的逻辑判断，而是说的上下文保存入栈和出栈，但是这个tricore芯片之前就学习过csa是一个link链表，分为upper和down2个部分，link指向之前的入栈地址。所以光猜都可以知道了，但是还是去找下源码。毕竟我已经生成出来了。

二，etas os的tricore上下文切换的设计思路

以前我看rtos的stm32是有一个静态数组保存了任务的地址，调用上下文切换的时候直接回退到这个任务地址。所以我一般认为A11【RA返回地址】应该保存的都是一个函数且为task名字的地址，看了这个基于alarm的basic task生成的代码，居然2个task的RA保存的地址都是0xA0010CC8，也就是1137行的判断是否为0的语句。

image.png

有图有真相，也就是高优先级任务返回的是Os_Dispatch()函数，然后运行完一个个函数后，在回到LowerPriority的任务中。这个估计是配置的太简单导致的代码生成出来是这样的思路，感觉不优化，因为会浪费栈空间，若任务多的话，超过128就麻烦了。

image.png

三，etas os的tricore上下文切换的汇编函数

1. Os_setjmp是入栈保存，步骤是先取出pcxi，换算成地址，然后把16个u32的现场数据保存到Os_dyn_tasks结构体中。当然它保存了17个，第一个是要返回的Os_setjmp判断是否为0的语句的地址。

   
   image.png

2. Os_Longjmp是出栈恢复现场
   先获取之前备份的offset4的link值到d2，然后将当前pcxi的link值放入d15调用loop函数，对比d15和d2值是否相同，不同就调用ret16，将pcxi出栈回退。直到pcxi和之前保存的一样。然后把16的u32的现场值都copy到内核寄存器中（这里我理解ret了upper的现场，没必要再copy一次了）最后跳入Os_setjmp判断是否为0的语句，这个地址是保存的17个地址中的第一个。就完成的现场恢复。
   这里一个亮点，汇编中的e8就是64bit的代表D8和D9的组合，算是个临时copy变量的，这样的ld命令速度会比较快。

   
   image.png

四，小结

上下文切换的汇编代码都看完了就想明白了，之前stm32的切换为什么RA可以直接赋值了，而tricore会要很曲折的用loop来调用ret16，再对比link地址的原因了，因为tricore用的是链表，所以必须要有出栈这个动作。另外基于仅alarm的切换感觉效率比较低，要把中断函数全部走完。