Remove floating point support on an ARM project
We are using CrossStudio with an LPC2468 on a large project and would like to be able to build it without any floating point.
Is there a way to get the compiler to error out on any floating point use, or instruct the linker to not add any of the floating point libs?
-
Hi, CrossWorks won't compile in any floating point routines unless you actually use them. If it's just a couple of you writing this software then just ensure you aren't using any floats or doubles. If you want to make sure you aren't using any routines, just search for declarations of "float" or "double" and smack the hand of the developer that added those :-)
-
Yes, I wish it were that easy.
This is a large project with lots of existing code and there is a lot of debugging code that uses floats and doubles in printf type stuff, which is supposed to be compiled out on a release build. However looking at the .map file of the release build tells me that some floating point code is getting built. I would like an (easy) way of finding the places where floating point stuff slips into the release configuration. (a bonus if I can get a warning/error to stop devs putting any back in.)
I am thinking I am either going to have to move the floating point libs to somewhere the linker can't find them, manually inspect a large amount of code or modify/remove a bunch of debug code.
-
Hmm... the only good way to go about doing that is to never use them at all. Once you're used to scaling values up and down floats become considerably less necessary. Typedefs are vital to that, we have around 70-80... distance_mm_t, time_ms_t, time_us_t, time_ns_t, resistance_mOhm, long_time_ns_t (64bit) etc. I know that doesn't help right now but it might help at some point.
The trouble with compiling out code in release mode is that now it doesn't operate the same way as when the developer was working on it. You'd know that of course... but that's something we take a massive amount of effort to avoid. We compile out almost nothing (8 unique projects spread over 28 cortex M3 processors in a single device). It's doable... but probably very difficult in your case since you have so much legacy code.
I've been hunting and hunting... I'm really surprised GCC ARM doesn't have an option to throw warnings in this scenario - you'd think it would be a common request for an embedded C compiler!
Hmm... You could "#define float" in a system/common.h type file which would then cause anything that uses floats to throw errors
Assuming you have some kind of "release" mode build option, you could set the floating point lib (in the CW project) to one that doesn't exist? That would probably throw warnings no matter what though...
You can definitely select that printf will not support floating point (in the CW printf/scanf project options). Maybe that would at least throw warnings when printf/scanf is called with a float/double.
I found mention of a compiler option "--fpumode=none", no luck there...
Okay, this seems to work!!! In your project options under "Code Generation Options", set "ARM FP ABI Type" to "None" (previously "Soft"), and "ARM FPU Type" to "None"
When I use floats, that last method throws all kinds of compiler errors. When set back to "Soft", no problems...
Please let us know how you get on!
-
Thanks for that!
Setting "ARM FP ABI Type" to "None" gives linker errors when trying to link the libs using floating point, so it won't help me identify the current problems but I should be able to put it in when they are all fixed to prevent any future problems being added.
After playing with this for a bit I think that the problem is not just limited to "float" "double" declarations, but is also caused by floating point constants which are harder to find. (I guess when they are used in complicated expressions the compiler is not optimising them into fixed point constants/operations :( )
Please sign in to leave a comment.
Comments
4 comments