avr-gcc floating point problems
in [Embedded]
|
Prev: ATI Catalyst 10.3 Preview Edition
Next: Network fabric
From: linnix on 18 Mar 2010 16:38 On Mar 18, 12:32 pm, Vladimir Vassilevsky <nos...(a)nowhere.com> wrote: > linnix wrote: > > All these ops works on x86 gcc. I guess AVR is not ready for floating > > points. Any one got FP apps working for AVR? > > I do heavy floating point computations with AVR (IAR workbench > compiler), and it works nicely. BTW, the math on the AVR at 20MHz is > somewhat 3 times faster then the same math on 40MHz PIC18. > > My experience is not all compilers provide for every possible cast > between the standard types; I have seen bugs in float <-> int > conversions also. But you can always do a function for explicit conversion. > > Vladimir Vassilevsky > DSP and Mixed Signal Design Consultanthttp://www.abvolt.com Then I guess it's a avr-gcc porting problem. I'll check if arm-gcc works or not.
From: Habib Bouaziz-Viallet on 18 Mar 2010 16:43 Le Thu, 18 Mar 2010 13:29:24 -0700, linnix a écrit : > On Mar 18, 12:19 pm, Habib Bouaziz-Viallet <h.bouazizvial...(a)free.fr> > wrote: >> Le Thu, 18 Mar 2010 12:39:32 -0700, linnix a écrit : >> >> >> >> > f is result of k1 * sine x + k2 * cosine y. >> ... > > Unless my apps is very unique (USB CDC A2D), I have to conclude that AVR > is not ready for it. oh no you cannot conclude that AVR or avr-gcc or AVR and avr-gcc are not ready for doing math, no you cannot ! Habib
From: Tim Wescott on 18 Mar 2010 16:44 linnix wrote: > On Mar 18, 12:19 pm, Habib Bouaziz-Viallet <h.bouazizvial...(a)free.fr> > wrote: >> Le Thu, 18 Mar 2010 12:39:32 -0700, linnix a �crit : >> >> >> >>> f is result of k1 * sine x + k2 * cosine y. >>> How would you extract the integer part without casting? I thought >>> that's the job of the compiler. >> Sure that's the compiler job, so please cast a float to an integer >> (signed int). Remember char are not meant to be used for math. > > But the real world (as least in my case) is unsigned char (8 bits). > > Now, the strange thing is: > > i = (int) f; works > or > u = (unsigned char) i; works > > but not together > i = (int) f; > u = (unsigned char) i; > > Unless my apps is very unique (USB CDC A2D), I have to conclude that > AVR is not ready for it. > > It sounds like it's at least partially an optimizer bug. Try lowering the optimization level (and hope that whoever wrote it was paying attention). Or make a function int cast_float_to_int_boy_gcc_is_stupid(float f) { return (int) f; } in extreme cases you may need to put it in a separate file to _really_ confound an over-eager optimizer. -- Tim Wescott Control system and signal processing consulting www.wescottdesign.com
From: Ulf Samuelsson on 18 Mar 2010 19:08 linnix skrev: > In response to another thread, I am still getting these problems with > WinAVR 2010. I think the linker is hitting some AVR limits. There > are similar reports on the web as well. > ------------------------------------------------------------------------------------------------- > > unsigned char u; > float f; > > u = (unsigned char) f; > > --------------------------------------------------------------------------------------------------- > c:/wavr10/bin/../lib/gcc/avr/4.3.3/../../../../avr/lib/ > avr35\libc.a(fp_powsodd.o): In function `__fp_powsodd': > (.text.avr-libc.fplib+0x10): relocation truncated to fit: > R_AVR_13_PCREL against symbol `__mulsf3' defined in .text section in > c:/wavr10/bin/../lib/gcc/avr/4.3.3/avr35\libgcc.a(_mul_sf.o) > c:/wavr10/bin/../lib/gcc/avr/4.3.3/../../../../avr/lib/ > avr35\libc.a(fp_powsodd.o): In function `__fp_powsodd': > (.text.avr-libc.fplib+0x20): relocation truncated to fit: > R_AVR_13_PCREL against symbol `__mulsf3' defined in .text section in > c:/wavr10/bin/../lib/gcc/avr/4.3.3/avr35\libgcc.a(_mul_sf.o) Did you report the problem to the WinAVR developers? -- Best Regards Ulf Samuelsson These are my own personal opinions, which may or may not be shared by my employer Atmel Nordic AB
From: linnix on 18 Mar 2010 20:04
On Mar 18, 3:08 pm, Ulf Samuelsson <u...(a)a-t-m-e-l.com> wrote: > linnix skrev: > > > > > In response to another thread, I am still getting these problems with > > WinAVR 2010. I think the linker is hitting some AVR limits. There > > are similar reports on the web as well. > > ------------------------------------------------------------------------------------------------- > > > unsigned char u; > > float f; > > > u = (unsigned char) f; > > > --------------------------------------------------------------------------------------------------- > > c:/wavr10/bin/../lib/gcc/avr/4.3.3/../../../../avr/lib/ > > avr35\libc.a(fp_powsodd.o): In function `__fp_powsodd': > > (.text.avr-libc.fplib+0x10): relocation truncated to fit: > > R_AVR_13_PCREL against symbol `__mulsf3' defined in .text section in > > c:/wavr10/bin/../lib/gcc/avr/4.3.3/avr35\libgcc.a(_mul_sf.o) > > c:/wavr10/bin/../lib/gcc/avr/4.3.3/../../../../avr/lib/ > > avr35\libc.a(fp_powsodd.o): In function `__fp_powsodd': > > (.text.avr-libc.fplib+0x20): relocation truncated to fit: > > R_AVR_13_PCREL against symbol `__mulsf3' defined in .text section in > > c:/wavr10/bin/../lib/gcc/avr/4.3.3/avr35\libgcc.a(_mul_sf.o) > > Did you report the problem to the WinAVR developers? > > -- > Best Regards > Ulf Samuelsson > These are my own personal opinions, which may > or may not be shared by my employer Atmel Nordic AB OK, I think the problem is WinAVR not founding the math library, even with the "-lm" flag. I made a local copy of libm.a to link in explicitly for now. I will check it out for sure before reporting. |