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

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

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

在修复任何错误或引入新代码的同时，程序员是否应该找到哪些所有任务都会受到他/她代码变化的影响，以及是否使用此选项产生了该任务？这非常乏味。我错过了什么吗？

2010-02-12 aks

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，否则断言（）。

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

来源

2010-02-12 09:51:45 Clifford

从以往的经验，我可以给你一个简单的答案：始终产卵与VX_FP_TASK任务。特别是如果你的代码可以用于不同的架构。

根据编译器（gnu，diab），您使用的编译标志和架构，浮点寄存器不仅可用于浮点运算。在大多数体系结构中，FP寄存器比常规寄存器大，因此它们成为优化代码的最佳选择。例如，在PPC603处理器中，如果使用C++而不是普通的C，FP寄存器将用于优化，如果您没有在该任务上启用VX_FP_TASK，则可能会损坏另一个任务的FP寄存器，尽管它没有进行任何计算！

正确执行比性能更重要，大多数情况下，性能提升并不能证明由于未启用而导致的风险。

如果你想确保所有的任务都启用了标志，考虑增加一个钩子，总是能够创建任务时的标志与taskCreateHookAdd（）

来源

2010-02-15 21:43:01 Marcelo

我不知道使用FP寄存器进行非FP操作的优化有时可能会被额外的上下文切换开销超过 - 编译器不会意识到这一点。听起来像是一个值得关闭的优化，如果应用程序摔碎任务很多。这就是说，我同意;总是避免过早的优化，并以默认的VX_FP_TASK开始，即使您实施了我所建议的'防御'技术。 – Clifford 2010-02-16 09:32:15

嗨马塞洛，谢谢你的回复。我不理解最后一句话 - “如果你想确保所有任务都启用了标志，考虑添加一个总是在任务创建期间使用taskCreateHookAdd（）启用标志的钩子”。你的意思是，如果设计者在创建任务时没有包含VX_FP_TASK选项，这个钩子会在编译代码的时候放入它？请您详细说明并详细解释。在此先感谢。 – aks 2010-02-17 15:43:30

始终使用VX_FP_TASK！没有它的成本，并试图追踪不确定的错误导致难以置信的昂贵。

来源

2012-01-21 00:22:49

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

回答

相关问题