STM32F4 floating point

I notice that the build process disables the STM32F4 floating point unit's use. Is that because it only supports 32-bit floating point and is of no use for Espruino's 64-bit FP? Or is there are different story to this?

I think it's a combination... When I was starting off (3 or so years back) I couldn't get floating point working, so I just disabled it because pretty much everything in Espruino is 64 bit. It might just have been a matter of powering up the FPU, but I didn't know that then :)

It might be that enabling it does really help (code size or speed) though, in which case it would be good to turn on properly.

It looks like it really only supports 32-bit FP and it provides additional registers which have to be saved, so sounds like it's of little use.

Yes, it's a shame it can't accelerate 64 bit somehow.

I really wanted to come up with a special build of Espruino that did everything in 32 bit floats and so avoided pulling in all the double-precision code - but I think as I'm using double for quite a bit of the time stuff, it might be difficult.

Have you had any luck with uClibc? You probably noticed Espruino pulls in its own maths and string libraries, which it could probably skip - with the original GCC library from a few years back some of the routines pulled in a lot of other stuff including malloc which pulled in a ~1k of RAM, which made it almost impossible to do anything on a chip with 8k RAM. Things might have changed now - or at least uClibc might help?

I was going down the route of newlib, not uClibc, 'cause that's what WICED uses. Also, with the networking stuff we need malloc, so it's less of an issue. But I have been concentrating on esp8266 the last week and have not made any progress on the emw3165, and don't expect to for another week.

It'd be interesting to see what the newlib results are - I haven't really looked into the libraries in any depth at all - I just remember the built-in C ones weren't great when I tried them.

... the current maths lib isn't optimised for ARM Thumb at all, so we could probably get some pretty good speed+size improvements by using something that was.