libm and the saturn

Amon

Staff member
After trying to figure out what the hell was wrong with my math I heard from CyberWarriorX that the libm isnt porperly supported on the SH2 series. He seemed to recault a thread here about a solution. I did a quick search and couldnt find it.

Also when using the sin function from the m2 libm I get a bunch of undefined reference to `___ltdf2' and other stuff. I tried including all the libraries but I still get them. For the time being, I am thinking of just including a sin and cos lookup table, but Id rather use the library.
 
What GCC version and compiler flags are you using? Can you post a small test program that shows the problem?
 
Flags -Wall -Werror -m2 -O2 -fomit-frame-pointer -lm and using mingw gcc 3.4-GNUSH_v0501 (stuff included with saturn orbit). sin(x) or cos(x) would ALWAYS return 0 no matter what the value of x was
 
My first suggestion would be to upgrade to a more recent compiler. I can compile a program that uses sin() with GCC 4.2.3 and Newlib 1.16 without any errors. (I haven't actually run the resulting binary, mind you, but the necessary functions all seem to be there.)
 
I haven't checked which newlib version it uses, but KPIT's GNUSH is up to version 803 now iirc, so you could try updating.
 
Amon said:
Where do I find this Newlib 1.16 you speak of?


Newlib is a popular open-source C library for embedded systems. The KPIT toolchain uses newlib so if you upgrade the distribution you will upgrade it at the same time.
 
Currently I am waiting for approval in order to download the kpit stuff. I think I shall throw together a patch of some sort for other users of saturn orbit to use the newer stuff.
 
From KPIT support

Apart from linking libgcc.a and libm.a you need to link libc.a also with your project. The options should be in "-lm -lc -lgcc" order to link math library first then C library and then GCC library.

The library paths seems to be of older version of tool chain. Please esnure that the paths correspond to correct version of the tool chain being used.

So all i had to do was reorder the included libraries and it worked. Oh well everything is upgraded anyways 🙂 and it works. Only problem is that calling the sin/cos causes the so much slowdown even when using the optimised libraries.
 
Amon said:
Only problem is that calling the sin/cos causes the so much slowdown even when using the optimised libraries.
The traditional workaround for that is to generate a look-up table of the appropriate precision/scale/type at startup/transition/whatever and use that instead of calling the function and munging its result every time you want a value.
 
i just reverted my code back to use the tables I created. Though I could gererate the lookup tables at startup as you suggested. Shouldnt be much difference other than precision. My table includes values for sin between 0 and 360 degrees 16bit numbers. That beats nothing.
 
Back
Top