在vxworks中,是否应该使用VX_FP_TASK选项生成每个任务？

Question

在vxworks中,是否应该使用VX_FP_TASK选项生成每个任务？

如果您的任务使用任何浮点运算,则需要VX_FP_TASK选项.但是,如何预测未来 - 我的意思是,如何知道他/她是否会使用浮动？

在修复任何错误或引入新代码的同时,程序员是否应该找到所有任务将受到他/她的代码特征影响,以及该任务是否使用此选项生成？这非常乏味.我错过了什么吗？

Answer 1

VX_FP_TASK强制任务上下文切换包括FP寄存器.这增加了上下文切换时间.如果在您的应用程序时间内,即使有这个开销也可以满足最后期限和性能目标,那么我建议这样做几乎没有问题.没有VX_FP_TASK可能被视为仅在必要时谨慎应用的优化.因此,如果默认情况是使用VX_FP_TASK,那么在可能需要优化性能的少数情况下,您可能需要做的检查较少; 因为通常不需要优化来实现所需的结果.如果上下文切换性能开销会导致您的项目成败,那么在任何情况下都可能是微不足道的.

另一方面,虽然在嵌入式系统中FPU变得越来越普遍,但由于传统上缺乏硬件FP支持,因此嵌入式系统设计人员通常使用FP作为例外而不是规则.因此,一种解决方案是拥有一个内部设计规则,即在没有正式理由和签字的情况下不得使用浮点:即浮点的使用必须在设计中,而不是程序员的决定.检查通常是扫描源的简单情况float,double和math.h.(因为在代码中没有出现这些中的任何一个可能很难使用浮点数).例如,您可以添加一个预构建静态分析检查,以查找这些并标记警告.

在许多应用程序中,可以进行设计,以便FP数学运算自然局限于特定任务.但是,如果有人选择使用现有的用于其中一项任务的功能,而另一项任务不是FP安全的,则会出现问题.这可能很难发现; 解决方案是让函数使用浮点,并且可以在其他任务中使用,以包含使用taskOptionsGet()测试任务选项的调试ASSERT.

所以扫描使用的组合float,double和math.h,并添加ASSERT检查,以使用这些可能会保护你的代码维护引入错误的功能.

[已添加2010Feb14]

复杂的宏一般都是坏事,我建议以下内容可能有用(如上所述):

#if NDEBUG
    #define ASSERT_FP_SAFE() ((void) 0)
#else
    #define ASSERT_FP_SAFE() do{ int opt; \
                                 STATUS st = taskGetOptions( taskIdSelf(), &opt ); \
                                 assert( st == OK && (opt & VX_FP_TASK) != 0 ) ; \
                               }while(0) ;
#endif

此宏应插入任何使用float或double的函数中,或者包含您可能使用的任何其他FP依赖库(可以通过文本搜索实现).当从非FP任务调用此类函数时,断言将失败.

注意,从taskGetOptions()返回的检查将捕获在中断上下文中使用浮点.虽然如果断言发生在中断中,您可能无法获得任何输出.调用logMsg()可能更安全; 你可以使用它,如果st!= OK和assert()否则.

不幸的是,它是一个运行时断言,因此代码必须运行才能进行检查.如果可以通过静态分析检测到它会更好,但我想不出一个简单的方法.但是,如果您也使用代码覆盖率分析,那么这可能就足够了.即使您选择完成所有任务VX_FP_TASK,这也可能是一个好习惯; 这样,如果有人忘记做其中一个,你有机会抓住它.