Important: Please read the Qt Code of Conduct -

What's available on a 5230 in terms of floating point math?

  • What's actually available on the processor (ARM 11???) in a 5230 in terms of floating point math? float? double? long double (right)? And assuming they're there, how slow are they? On a 400mhz processor, does floating point act as if it's on a 40mhz processor, ie, use only when truly needed. Comments please.

    thanks - greg

  • The 5230 contains an ARMv6 chip with support for ARM's VFPv2 floating point extension. I recommend reading the following application note from ARM:

    "VFP Support Code App Note":

    The compiler options listed there are specific to the RVCT compiler so you will need to find equivalent options if you plan on using GCCE. I'm not 100% sure GCCE supports this though.

  • jbarron - thanks for the post. It sounds like it implements std IEEE floating point math (though I don't think I care about the internal formats, as long as the library routines generate the correct results - or maybe I should??). So.. my question is: from Qt for Symbian it sounds like sin cos sqrt should work, if I include math.h? Or am I misreading the situation? [I'm using qtcreator and it's included c++ compiler, on Win7] Since you know of the document, you probably have floating pt experience - what's been your experience with fp math? Does Qt have it's own Qdouble, or does one just use double as one would elsewhere?

    again, many thanks - greg

  • math.h should work, yes. On Symbian, this is provided by the Open C plugin.

    Qt does not have a QDouble class nor any other decimal type class. The only public data type Qt has in this area is "qreal" which is typedef'ed to a float on ARM and a double everywhere else. The reason for this being that floats are about 40% faster compared to double on the ARM hardware we tested (with VFPv2) and up to 3 times faster if you are you using soft floats. This probably varies depending on the use case, but our test was based on doing iterations of "x = a*x + b/x".

    If you want to use the "qreal" type, then you could include "qmath.h" (which doesn't seem to be documented). It contains wrapper inline functions such as qSqrt(), qSin(), etc. On Symbian these functions will skip the Open C layer and jump right to the Symbian versions of Sqrt(), Sin(), etc. which are in Symbian's "Math" namespace. These functions also take care of the qreal conversion for you.

  • jbarron - again, thanks for the reply, and my apologies for my belated follow up. I've spent most of the week looking at the app's execution (under WinXP) to see just how many significant digits the app needs. The sad news is: it's going to really need "Real*8", ie, there are places, that's carrying 9 or 10 sig digits (it's an astonomy pgm that uses julian dates, and need times down to the couple of minute level). The good news is that it isn't really doing that much floating math. In your previous post you alluded to soft-floats (I assume by this you're alluding to a fp emulator). So.... my question is: if I compile and debug the pgm on XP or W7 with floating point values being defined as "double", and the 5230 hw doesnt support such, will calls to double fp math default to the emulator, or is this something that I have to force, ie, I'm going to have one build for W7 and another for the smartphone (with a different set of build parms)? Where do I find documentation on this? It sounds like you've been down this road before - what's the smart way to deal with such situations?

    again - many thanks - greg

  • Hi, yes by "soft floats" I was referring to a floating point library that emulates floating point operations as function calls in software instead of using the hardware co-processor.

    You can still use "double" on the 5230, but they will be slower than using floats. They will be additionally (and far more noticeably) slower if you use soft floats instead of hard floats. If the code uses double on Windows, then you should continue using double on Symbian, otherwise you could get different results. For this reason, qreal might not be suitable for you.

    Qt apps are native apps (as opposed to apps that run in a VM such as Java) so you will inevitably have different binaries for Windows and Symbian. For Windows, you probably don't need to tweak your compiler options to get the best floating point performance (I could be wrong though), but for Symbian you will have to specify in your .pro file that you want to use hardware floating points (VFP2). Like I said before I know this is supported by RVCT, but I'm not sure about GCCE which is the default compiler if you are using the Nokia Qt SDK.

Log in to reply