Steve,
Thanks for the suggestion. I had already tried this and it produced very
interesting results. I didn't want to bring it up before since it might
confuse the issue. With those #defines in there the compiler produces:
err = FlpFToA(theComp.fd, szTemp);
1006A36A: 486EFFD2 pea -46(a6)
1006A36E: 2F2EFFF4 move.l -12(a6),-(sp)
1006A372: 2F2EFFF0 move.l -16(a6),-(sp)
1006A376: 4EBAE2CE jsr *-7472 ; 0x10068646
Which should work, right? Nope. The JSR goes off into a library routine,
which runs for about 10 lines and then done this:
10068680: 4EB9000002AC jsr 0x000002ac ; 0x000002ac
Oops! 02ac is just garbage memory and the whole thing tanks right there.
This sounds like a problem with the library, but since Metrowerks doesn't
include the source I can't track it down (not much of an assembly
programmer).
Until now, having another build for Pilot users has been trivial and keeps
my early customers (some of whom still have Pilots) happy.
Thanks for the help!
Rick Wagner
> -----Original Message-----
> From: Steve Lemke [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, March 23, 1999 10:54 PM
> To: [EMAIL PROTECTED]
> Cc: Richard Wagner
> Subject: Re: CWR5- Floating Point Library & FlpFToA() - Argghh!
>
>
> Not sure how this would've worked in the past, and not now, but I was
> able to make it do the right thing by including the following at the
> top of my source file:
>
> #define PILOT_PRECOMPILED_HEADERS_OFF 1
> #define _DONT_USE_FP_TRAPS_ 1
>
> Do this before: #include <Pilot.h>
>
> Give it a shot and see if it gives you the results you want... It
> seemed to work for me.
>
> Other than that, it may be possible to fix the Metrowerks compiler
> and/or the header files to make it work "right", but since this is
> only useful in supporting Palm OS floating point on 1.0 devices, and
> since 1.0 devices now number less than one or two percent of the
> whole installed base, I'm not sure it's worth the effort to fix it
> (or for you to support it with a separate build of your app). Move
> on to 2.0 as a required base version for your app and you won't have
> to even worry about this anymore. [Still, if you insist, the above
> should get it working again for you.]
> --Steve
>
>
> > Codewarrior R5 absolutely refuses to correctly handle the
> FlpFToA() in the
> > metrowerks Floating Point Library! After banging my head
> against the wall I
> > quick put together a little app which demonstrates the
> problem. The problem
> > is easy to see, look at the output from the debugger:
> >
> > err = FlpFToA(theComp.fd, szTemp);
> > 100699CE: 486EFFD2 pea -46(a6)
> > 100699D2: 2F2EFFF4 move.l -12(a6),-(sp)
> > 100699D6: 2F2EFFF0 move.l -16(a6),-(sp)
> > 100699DA: 7401 moveq #1,d2
> > 100699DC: 4E4F trap #15
> > 100699DE: A305 _FlpDispatch
> >
> > Why is it generating a TRAP??? I have the floating point
> set to "Library"
> > in the IDE and most importantly REGULAR MATH WORKS FINE!
> Yep, that's right,
> > I can do multiplication, divides, et al and it correctly
> uses the library
> > but it never links in the damn FlpFToA() function. I
> checked the .MAP file
> > and for some reason FlpFToA() isn't included.
> >
> > Looking at the NewFloatMgr.h file, I tried defining the
> _DONT_USE_FP_TRAPS_
> > to 1
> > and while it caused it to be linked, it also caused a line
> 1111 error in
> > Poser.
> >
> > The part of this that really pisses me off is that it all
> worked perfectly
> > under R4.
>
