In vxworks, should each task appear with the VX_FP_TASK option?

Question

In vxworks, should each task appear with the VX_FP_TASK parameter?

The VX_FP_TASK option is required if your task uses any floating point operations. But how to predict the future - I mean, how can I know if it will use a float or not?

When fixing a mistake or introducing a new code, should the programmer find which tasks will be performed by his / her code chain, and if this task will be generated by this option or not? This is very tiring. Did I miss something?

Answer 1

VX_FP_TASK forces the task context switch to enable FP registers. This increases the context switching time. If your application’s time, deadlines and performance targets can be met even with this overhead, then there’s a small problem that I propose to do. Without VX_FP_TASK, we can consider optimization, which will be applied with caution only if necessary. Therefore, if the default case is VX_FP_TASK, you are likely to have fewer checks in the few cases where you might need to optimize performance; since optimization is often required to optimize the desired results. If the context switch performance overhead that it imposes creates or breaks your project, it can be negligible in any case.

On the other hand, although FPUs are becoming more common in embedded systems, embedded developers also often have to use FP as an exception rather than the rule due to the traditional lack of support for FP hardware. Therefore, one of the solutions is to have your own design rule that the floating point should not be used without formal justification and statement: that is, the use of the floating point should be in the design, and not in the decision of the programmer. Validation is usually a simple case of source scanning for float , double and math.h (since it is probably difficult to use floating points without any of them found in the code). For example, you can add a static analysis check to a preliminary assembly that searches for these flags and warns about it.

In many applications, it is possible to design so that the mathematical operations of FP are naturally limited to specific tasks. However, a problem arises when someone chooses to use an existing function that is intended to be used in one of these tasks, in another, which is not a secure FP. It can be difficult to detect; the solution for this is to have functions that use floating point and which can be used in other tasks to enable debug ASSERT, which checks the parameters of the task using taskOptionsGet ().

Thus, combining a scan to use float , double and math.h and adding an ASSERT check to the functions that use them is likely to protect you from introducing errors in code maintenance.

[added 2010Feb14]

How complex macros are generally bad, I suggest using the following (as mentioned above):

 #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 

This macro should be inserted into any function that uses float or double, or that includes either any other FP-dependent library that you can use (which you can achieve by text search). This statement will fail if such a function is called from a task other than FP.

Note that checking the return from the GetOptions () task will catch the use of floating point in interrupt contexts. Although, if an assertion occurs in an interrupt, you cannot get any conclusion. Perhaps calling logMsg () might be more secure; you can use this if st! = OK and assert () otherwise.

Unfortunately, this is a run-time statement, so the code must run for verification. It would be better if this could be detected through static analysis, but I cannot come up with a simple method. If, however, you also use code coverage analysis, then that might be enough. This can be a good habit, even if you decide to do all the tasks VX_FP_TASK; if someone forgets to do one or the other, you have a chance to catch him.

Answer 2

From experience, I can give you a simple answer: Always create a task using VX_FP_TASK. Especially if your code can be used for different architectures.

Depending on the compiler (gnu, diab), the compilation flags and archives you use, floating point registers can be used not only for floating point operations. In most architectures, FP registers are larger than regular registers, so they turn into ideal candidates for code optimization.

For example, in PPC603 processors, if you use C ++ instead of plain C, the FP registers will be used for optimization, and if you do not have VX_FP_TASK enabled for this task, it can damage the FP registers of another task, even if it does not do any calculations!

Correct execution is more important than performance, and in most cases a performance gain does not justify the risk associated with its invalidity.

If you want all tasks to turn on the flag, consider adding a hook that always turns on the flag when creating a task using taskCreateHookAdd ()

Answer 3

ALWAYS use VX_FP_TASK! The cost of his absence and an attempt to track down erroneous errors that lead to incredible costs.