avr-gcc floating point problems
in [Embedded]
|
Prev: ATI Catalyst 10.3 Preview Edition
Next: Network fabric
From: Grant Edwards on 25 Mar 2010 20:59 On 2010-03-26, Jamie <jamie_ka1lpa_not_valid_after_ka1lpa_(a)charter.net> wrote: >> A typecast doesn't to at all what you think it does. > > Well I may have had a brain scrub on that one, I'll admit to that how ever. > This will produced what I was talking about. Yep. > u2 = *(unsigned int *) &f; > > I would be very surprised if the gcc-AVR compiler could handle that.. I've used the gcc-avr compiler, and it will handle that just fine. -- Grant
From: Dave Platt on 25 Mar 2010 21:25 In article <h9Tqn.301415$OX4.301351(a)newsfe25.iad>, Jamie <jamie_ka1lpa_not_valid_after_ka1lpa_(a)charter.net> wrote: >Well I may have had a brain scrub on that one, I'll admit to that how ever. > This will produced what I was talking about. > > u2 = *(unsigned int *) &f; Yeah, that's the sort of construct that has the effect you were thinking about. It's incredibly non-portable, ill-defined, and "How lucky do you feel today?" If you do it the other way (e.g.) f2 = *(unsigned float *) &u2; thing could be even worse, due to misalignment issues. Segfaults are entirely possible on many architectures. -- Dave Platt <dplatt(a)radagast.org> AE6EO Friends of Jade Warrior home page: http://www.radagast.org/jade-warrior I do _not_ wish to receive unsolicited commercial email, and I will boycott any company which has the gall to send me such ads!
From: David Brown on 26 Mar 2010 03:14 Dave Platt wrote: > In article <h9Tqn.301415$OX4.301351(a)newsfe25.iad>, > Jamie <jamie_ka1lpa_not_valid_after_ka1lpa_(a)charter.net> wrote: > >> Well I may have had a brain scrub on that one, I'll admit to that how ever. >> This will produced what I was talking about. >> >> u2 = *(unsigned int *) &f; > > Yeah, that's the sort of construct that has the effect you were > thinking about. It's incredibly non-portable, ill-defined, and "How > lucky do you feel today?" > I am not sure if such statements are well-defined in terms of C standards, but they are well-defined in practice. You are reading the underlying memory pattern for the float. It's going to be dependent on the compiler/library combination for the format (though almost all compilers, including avr-gcc, use IEEE format), the endianness, and possibly alignment issues of the particular cpu. But it is certainly valid and consistent to use pointer casts like this. If you've ever used memcpy to copy a struct containing floats, you've effectively done this already. And you'll see code like that in the library implementation of software floating point routines - that's how the floating point data is broken up and interpreted to carry out the calculations in integer operations. > If you do it the other way (e.g.) > > f2 = *(unsigned float *) &u2; > > thing could be even worse, due to misalignment issues. Segfaults are > entirely possible on many architectures. > I haven't seen an "unsigned float" before - guess that's a typo. But yes, you always have to look out for alignment issues when mixing pointers to objects of different sizes. Of course, on an 8-bit avr, everything is aligned!
From: David Brown on 26 Mar 2010 03:58
On 26/03/2010 02:24, Jamie wrote: > Grant Edwards wrote: > >> On 2010-03-24, Jamie >> <jamie_ka1lpa_not_valid_after_ka1lpa_(a)charter.net> wrote: <snip> >> A typecast doesn't to at all what you think it does. >> > Well I may have had a brain scrub on that one, I'll admit to that how ever. > This will produced what I was talking about. > > u2 = *(unsigned int *) &f; > > I would be very surprised if the gcc-AVR compiler could handle that.. > What are you expecting when you say "handle that"? If you are expecting the standard C behaviour - that u2 will get part of the underlying memory pattern of the float - then avr-gcc will handle it perfectly well, just like any other C compiler. But if you are equally wrong about this sort of cast as you were with non-pointer casts, and think the compiler should do a floating-point to integer conversion, then you will be disappointed - that's not how C works, and therefore not how avr-gcc works. |