mirror of
https://github.com/RIOT-OS/RIOT.git
synced 2024-12-29 04:50:03 +01:00
f62b662b08
- Perform the same computation over and over again. If the results differ, context switches have an impact on the calculation (e.g. when the FPU internally uses more bits than a float, but that bits are not saved / restored on context switch) - Give the three threads the names "t1", "t2", and "t3" and print them on console, instead of the process ID. This makes interpretation of the output easier, as the process IDs depend e.g. on whether a given platforms requires an idle thread or not. - Do not use the thread ID in the calculation, but the number at the end of the thread name. This will result in the number printed only depending on the precision of the (software) FPU and the printf() implementation, and not on which threads are created in which order (including the idle thread) - Add a script to support running `make test` Update tests/thread_float/tests/01-run.py Co-authored-by: Alexandre Abadie <alexandre.abadie@inria.fr> |
||
---|---|---|
.. | ||
tests | ||
main.c | ||
Makefile | ||
Makefile.ci | ||
README.md |
Testing for Absence of Interactions between Floating Point Calculations and Context Switches
This tests launches three threads, t1, t2 and t3 that will perform a long and costly series of floating point calculations with different input data, while a software timer triggers context switches. The threads t1 and t3 will print the results. All threads will do this in an endless loop.
This allows for testing the following:
- When using the pseudo module
printf_float
, floating point numbers can be correctly printed THREAD_STACKSIZE_MAIN
is large enough to print floats without stack overflows.- Context switches while the (soft) FPU is busy does not result in precision loss.
- This could happen if the FPU state is not properly saved / restored on context switch. This
could be needed if the FPU internally uses a higher resolution that
float
/double
(e.g. the x86 FPU uses 80 bits internally, instead of 64 bits for double)
- This could happen if the FPU state is not properly saved / restored on context switch. This
could be needed if the FPU internally uses a higher resolution that