Corrections and Clarifications: To check for special values of floating point variables, you can use macros/functions from . Here are a few examples: Use isinf(x) to test for an infinite value. Use isnan(x) to test for "not a number". Use isfinite(x) to test for a "regular number" (not infinite or NaN). A long double on X86_64 is not a true quad precision variable as I stated. Instead it is an 80 bit format (called "double extended" precision) that is between a 64 bit double and a 128 bit quad. FPU general purpose register data is normally loaded from, and stored to, memory. It is not transferred to and from CPU general purpose registers as I stated. This can be seen in the assembly code in video 2.
Thank you. Studying FPUs is an advanced topic, but I think it is interesting. Understanding the theory and practice is very important for applications that use a lot of floating point, especially for real-time applications.
To clarify, the single precision FPU will not provide any performance boost if we are using doubles in our code? So I can choose a MCU without a FPU if I know I am performing double precision operations? (Or a M7 with a double precision FPU)
From my testing with the STM32 MCUs and the gcc compiler, I saw no performance improvement when having a simple precision FPU and doing double precision operations. I should have included results for this case in my video, but I didn't think of it. Keep in mind, I am just a "guy on the internet" but this is what I saw. I have read that is is *possible* for software implementations of double precision operations to somehow make use of a single precision FPU for a small boost. However, as I said above, I saw no evidence of that in my testing. Perhaps with other CPUs/FPUs or compilers this is true. My advice is to consider if some parts of your application could be done in single precision, such that a single precision FPU would be useful. If the cost difference to get a single precision FPU is small, it might be good to get one "just in case." Of course, it performance is important, and the cost of an MCU with a double precision FPU is not too much, then that is the ideal solution.
Interesting ... I would (naively) have guessed that ( X == X) would always be true because the compiler would _"optimize"_ it that way, rather than actually doing a comparison each time. But, then again, I don't know exactly how _gcc_ actually works.
I think that with other types, like int, what you say is true. But gcc, and any C compiler, must have deep knowledge of floating point values since they are defined in the C language. So gcc must know about special values like infinity and NaN that can affect operations like equality. I suspect (but haven't looked into it) that the FPU is also aware of these special values.
Corrections and Clarifications:
To check for special values of floating point variables, you can use macros/functions from . Here are a few examples:
Use isinf(x) to test for an infinite value.
Use isnan(x) to test for "not a number".
Use isfinite(x) to test for a "regular number" (not infinite or NaN).
A long double on X86_64 is not a true quad precision variable as I stated. Instead it is an 80 bit format (called "double extended" precision) that is between a 64 bit double and a 128 bit quad.
FPU general purpose register data is normally loaded from, and stored to, memory. It is not transferred to and from CPU general purpose registers as I stated. This can be seen in the assembly code in video 2.
Thanks a lot for making this tutorial. Very crisp and precise explanation!!
Thank you. Studying FPUs is an advanced topic, but I think it is interesting. Understanding the theory and practice is very important for applications that use a lot of floating point, especially for real-time applications.
To clarify, the single precision FPU will not provide any performance boost if we are using doubles in our code? So I can choose a MCU without a FPU if I know I am performing double precision operations? (Or a M7 with a double precision FPU)
From my testing with the STM32 MCUs and the gcc compiler, I saw no performance improvement when having a simple precision FPU and doing double precision operations. I should have included results for this case in my video, but I didn't think of it. Keep in mind, I am just a "guy on the internet" but this is what I saw.
I have read that is is *possible* for software implementations of double precision operations to somehow make use of a single precision FPU for a small boost. However, as I said above, I saw no evidence of that in my testing. Perhaps with other CPUs/FPUs or compilers this is true.
My advice is to consider if some parts of your application could be done in single precision, such that a single precision FPU would be useful. If the cost difference to get a single precision FPU is small, it might be good to get one "just in case." Of course, it performance is important, and the cost of an MCU with a double precision FPU is not too much, then that is the ideal solution.
Interesting ... I would (naively) have guessed that ( X == X) would always be true because the compiler would _"optimize"_ it that way, rather than actually doing a comparison each time. But, then again, I don't know exactly how _gcc_ actually works.
I think that with other types, like int, what you say is true. But gcc, and any C compiler, must have deep knowledge of floating point values since they are defined in the C language. So gcc must know about special values like infinity and NaN that can affect operations like equality. I suspect (but haven't looked into it) that the FPU is also aware of these special values.