On Tue, May 14, 2002 at 01:05:44AM +0200, [EMAIL PROTECTED] wrote:
> the following code called from within a hack compiled with prc-tools 2.pre1
> gives me 110 (correct) from the applications screen but 368 (wrong) from the
> memopad? with some applications this works but with others it doesn't.
>
> why is that so?
For the usual reason :-).
> {
> Int16 iq=100;
> StrIToA(outputstringarray,(Int32)((float)iq*1.1));
> WinDrawInvertedChars(outputstringarray, 5, 120, 70);
> }
If you use m68k-palmos-size to look at the linked executable from which
you extract the .text section to form the code of your hack, you'll see
that it has a .data section of non-zero size. If you produce a linker
map file when you link your hack, you'll see that this global data is a
struct called _fpCCR that is pulled in from libgcc.a(_floatex.o).
This is the emulated floating point's floating point status register,
containing the rounding mode to be used and so on. It has to be stored
somewhere, and libgcc.a currently stores it as global data.
Of course, your hack doesn't have globals, so its working from the
Launcher was just a coincidence and it won't work in general.
You could link your hack with -lnfm which will cause the NewFloatMgr to
be used instead of the libgcc emulated fp. The NewFloatMgr stores its
fp status register somewhere else -- being part of the OS, it has
Special Powers allowing it to do so. This will save a few K of code
space in your hack too. But don't do this on a Palm OS 1.0 device :-).
Or you could recode so as to avoid floating point operations. For
example, here you could probably do about as well with
StrIToA (outputstringarray, iq + iq / 10);
John
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/support/forums/
