avr-gcc floating point problems
in [Design]
|
Prev: NET tips to expand your biz
Next: IR is insane
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: David Brown on 19 Mar 2010 04:47 On 18/03/2010 18:47, linnix wrote: > 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) Normally, comp.arch.embedded is a helpful place, but some of the "answers" is this thread are ridiculous! People are leaping to conclusions like "the avr can't do floating point", "gcc can convert a floating point to an int, but not to a char", "try disabling optimisations", etc. It seems no one has asked any /relevant/ questions the would have helped you out. Have you got a minimal code snippet that illustrates the problem, and is valid and compilable C code? In this case, you would probably have something like: // Use "volatile" so the code won't be optimised away volatile unsigned char u; volatile float f; int main(void) { u = (unsigned char) f; return 0; } Working out a minimal code snippet is extremely helpful in isolating the problem, and essential for other people to give more than hand-waving help. Secondly, we need to know your command line switches. A common source of problems is incorrect switches (such as for those choosing the avr variant). We also need to know the versions of the tools. While avr-gcc has very few known issues that could result in wrong code or compile failures, I don't think any compiler claims guarantees of perfection - avr-gcc developers are entirely open about bugs, and very interested to hear if this does turn out to be a compiler bug. But in practice, it's rare that a user's problem is the result of a compiler bug rather than a misunderstanding or error in the user's code or command line. You will get excellent support for avr-gcc on the avr-gcc mailing list - people there will try to help out with your actual problem rather than telling you your code is "silly", or that you should buy a different compiler and/or microcontroller. Of course, the first thing you will be asked there is the same questions I asked above. If you don't want to join the mailing list, you can also use the gmane mailing list to newsgroup gateway - you can see it as newsgroup "gmane.comp.hardware.avr.gcc" on news.gmane.org. mvh., David
From: Habib Bouaziz-Viallet on 19 Mar 2010 05:34
David Brown a �crit : > On 18/03/2010 18:47, linnix wrote: >> 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) > > Normally, comp.arch.embedded is a helpful place, but some of the > "answers" is this thread are ridiculous! People are leaping to > conclusions like "the avr can't do floating point", "gcc can convert a > floating point to an int, but not to a char", "try disabling > optimisations", etc. > > It seems no one has asked any /relevant/ questions the would have helped > you out. > > Have you got a minimal code snippet that illustrates the problem, and is > valid and compilable C code? In this case, you would probably have > something like: > > // Use "volatile" so the code won't be optimised away > volatile unsigned char u; > volatile float f; > > int main(void) { > u = (unsigned char) f; > return 0; > } > In that case i'm quite sure gcc promote internally the (unsigned char)f to an int. Differences appears when actually using the u variable (instead of just evaluate like in your code snippet) that's IMHO the initial issue. Why not verifying this with avr-gcc -S yourfile.c and read the assembler yourfile.s ... What makes you think guys down here make ridiculous answers when obviously the initial question is not clearly exposed. Habib .... > David |