UCOSIII中OS_OPT_TASK_SAVE_FP不会就是个摆设吧？

云琴箫龙

UCOSIII内核版本是论坛里面最新的V3.07.03，硬件平台是STM32F4。
创建任务时有个选项OS_OPT_TASK_SAVE_FP /* Save the contents of any floating-point registers  */字面上理解应该就是任务进行上下文切换时是否将浮点寄存器的内容保存到任务堆栈中，
于是饶有兴致的追踪这个选项的去向，发现在创建任务时赋值给了任务控制块的p_tcb->Opt，然而在上下文切换中并没有发现它的踪迹，不是得靠它来判断是否将浮点寄存器压栈吗？

再往下看，os_cpu_c.c中在任务切换的HOOK函数中有调用了浮点寄存器的压栈和出栈函数，如下：
#if (OS_CPU_ARM_FP_EN > 0u)
    OS_CPU_FP_Reg_Push(OSTCBCurPtr->StkPtr);                    /* Push the FP registers of the current task.           */
#endif

。。。。。。。
#if (OS_CPU_ARM_FP_EN > 0u)
    OS_CPU_FP_Reg_Pop(OSTCBHighRdyPtr->StkPtr);                 /* Pop the FP registers of the highest ready task.      */
#endif

是的，没看错，系统是根据OS_CPU_ARM_FP_EN 来决定是否将浮点寄存器压栈和出栈的，难不成OS_OPT_TASK_SAVE_FP 就是个摆设？
好吧，简单验证了一下：
首先让OS_CPU_ARM_FP_EN=1 ，然后新建一个任务，里面只有一行浮点算法和一行系统延时，仿真发现创建任务时无论有没有OS_OPT_TASK_SAVE_FP选项，任务控制块中的StakUsed和StakFree始终不变。
其次让OS_CPU_ARM_FP_EN=0，发现任务控制块的StakUsed一下子就少了20(只有16个浮点寄存器已使用数量却为啥少了20还有待探究)，同样也跟OS_OPT_TASK_SAVE_FP无关。
至此，能不能得出OS_OPT_TASK_SAVE_FP就是一个摆设的结论？

云琴箫龙

之前只知道中断中调用浮点运算会造成任务中的浮点运算出错，这次顺道也探究了一下，发现原来CPU_CRITICAL_ENTER()函数里面并没有进行将浮点寄存器压入任务堆栈的操作，之前的疑惑应该就是这个原因了。

eric2013

是的，新版的3.07又改了这个东西。

云琴箫龙

eric2013 发表于 2019-10-11 10:23
是的，新版的3.07又改了这个东西。

不知道UCOSIII咋想的，可能那种方式还有啥问题吧，暂时知道有这回事儿，看看以后新的版本这块儿怎么处理的。

eric2013

云琴箫龙 发表于 2019-10-11 16:17
不知道UCOSIII咋想的，可能那种方式还有啥问题吧，暂时知道有这回事儿，看看以后新的版本这块儿怎么处理 ...

那种方式有没问题，挺好用，我们V6一直在用。

云琴箫龙

这是之前版本的关于浮点的处理
#if (OS_CPU_ARM_FP_EN == DEF_ENABLED)
    if ((OSTCBCurPtr->Opt & OS_OPT_TASK_SAVE_FP) != (OS_OPT)0) {
        OS_CPU_FP_Reg_Push(OSTCBCurPtr->StkPtr);
    }

    if ((OSTCBHighRdyPtr->Opt & OS_OPT_TASK_SAVE_FP) != (OS_OPT)0) {
        OS_CPU_FP_Reg_Pop(OSTCBHighRdyPtr->StkPtr);
    }
#endif

eric2013

云琴箫龙 发表于 2019-10-11 16:28
这是之前版本的关于浮点的处理
#if (OS_CPU_ARM_FP_EN == DEF_ENABLED)
    if ((OSTCBCurPtr->Opt & OS_ ...

是的，3.03是一个版本，3.05也是一个版本，进入3.07后又改了