avr-gcc floating point problems
in [Embedded]
|
Prev: ATI Catalyst 10.3 Preview Edition
Next: Network fabric
From: Grant Edwards on 24 Mar 2010 13:50 On 2010-03-24, Bob <SkiBoyBob(a)excite.com> wrote: > linnix wrote: >> On Mar 23, 12:35 pm, Hans-Bernhard Br?ker <HBBroe...(a)t-online.de> >> wrote: > ><snip> > >> >> It is mainly for storage. Unsigned char (8 bits) takes less space than >> float (16 bits) or double (32 bits). We don't really care how the >> compiler does it, but storage is important for a 1K SRAM chip. > > Really? No, I don't think so. > I've never run across a 16 bit float. The last time I used avr-gcc a float was 32 bits. I seriously doubt that's changed in the past year or two. > Every compiler I've worked with uses 32 bits for float (sign, 8 bit > exp, 23 bit mantissa w/ implied MSB) and 64 bits for double. Gcc on some platforms has a option to make doubles 32 bits also. > It's been a long time since I read IEEE-754 and it wouldn't surprise > me that it allowed for other formats, I've just never seen them. IIRC, it only specifies the two formats (32 bits and 64 bits). -- Grant Edwards grant.b.edwards Yow! Your CHEEKS sit like at twin NECTARINES above gmail.com a MOUTH that knows no BOUNDS --
From: Vladimir Vassilevsky on 24 Mar 2010 14:02 Bob wrote: > I've never run across a 16 bit float. Every compiler I've worked > with uses 32 bits for float (sign, 8 bit exp, 23 bit mantissa w/ implied > MSB) and 64 bits for double. SHARC DSP from Analog Devices supports 16-bit float in the hardware; it is supported by tools as well. > It's been a long time since I read IEEE-754 > and it wouldn't surprise me that it allowed for other formats, I've just > never seen them. Me uses self made 24-bit float class (16 bit mantessa + 8 bit exponent) routinely; it is very handy when you work with 8-bit or 16-bit integer machine. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com
From: Hans-Bernhard Bröker on 24 Mar 2010 16:08 Jamie wrote: > linnix wrote: >> It is mainly for storage. Unsigned char (8 bits) takes less space than >> float (16 bits) or double (32 bits). We don't really care how the >> compiler does it, but storage is important for a 1K SRAM chip. > Last time I knew, that just cast the object into what you want, but it's > not going to magically convert a FLOAT to a unsigned char.. Well, that only prove it's imperative that you get away from last time you knew, into the real time we're in, and find better things to know. You remember pretty much the opposite of the truth. > Its only going to instruct the compiler that the contents of memory the > "F" occupies is a unsigned char and simply moves the data from that > from ever it is in memory to "u" No. There's a statement involving a cast that would do that, but it's _not_ the statement we've been discussing here. > simply speaking.. > u = f; isn't the same as u = (unsigned char) f; where I come from.. Then you need to come from a different place. > u = (unsigned char) f; simply tells the compiler to treat the object > of "F" as if it was a char instead. No conversion is taking > place here. Wrong. > As far as how the floats are implemented for the binary format of > this compiler will dictate what value of data will be returned.. No, it won't. The platform's floating point format is almost always irrelevant to the resulting value of this expression. Typically the _only_ things relevant are the range of unsigned char, and the decision made by the compiler implementor (or platform ABI) about what kind of undefined behaviour to exhibit if the float's value is outside that range.
From: George Neuner on 25 Mar 2010 02:51 On Wed, 24 Mar 2010 13:02:24 -0500, Vladimir Vassilevsky <nospam(a)nowhere.com> wrote: >Bob wrote: > >> I've never run across a 16 bit float. Every compiler I've worked >> with uses 32 bits for float (sign, 8 bit exp, 23 bit mantissa w/ implied >> MSB) and 64 bits for double. > >SHARC DSP from Analog Devices supports 16-bit float in the hardware; it >is supported by tools as well. Not exactly. The SHARC fpu operates on 32 or 40 bit data. A 16-bit packed storage format is supported by the ISA using FPACK/FUNPACK instructions which are special shifter operations. The shifter can't access memory - only the register file - so you need to load before unpacking and pack before storing. In the worst case - an isolated operation on packed operands producing a packed result - the (un)packing can add 80% overhead to the FPU operation. However, because the SHARC is multiple issue and the shifter works in parallel with the FPU, the overhead of (un)packing multiple values can be amortized over longer FPU sequences. >> It's been a long time since I read IEEE-754 >> and it wouldn't surprise me that it allowed for other formats, I've just >> never seen them. FWIW: IEEE 754-2008 now defines a standard 16-bit binary float format. (see http://en.wikipedia.org/wiki/IEEE_754-2008) >Me uses self made 24-bit float class (16 bit mantessa + 8 bit exponent) > routinely; it is very handy when you work with 8-bit or 16-bit integer >machine. I recall some software FP libraries offering 16-bit floating point operations back in the days when FP coprocessors were expensive luxuries. George
From: Jamie on 25 Mar 2010 21:24
Grant Edwards wrote: > On 2010-03-24, Jamie <jamie_ka1lpa_not_valid_after_ka1lpa_(a)charter.net> wrote: > > >>Last time I knew, that just cast the object into what you want, but it's >>not going to magically convert a FLOAT to a unsigned char.. > > > That's exactly what a cast does. (Though there's nothing magical > about the conversion -- it's a well-defined operation.) > > >> Its only going to instruct the compiler that the contents of memory the >>"F" occupies is a unsigned char and simply moves the data from that >>from ever it is in memory to "u" > > > No, it isn't. It instructs the compiler to do the conversion. > > >> simply speaking.. >> u = f; isn't the same as u = (unsigned char) f; where I come from.. > > > I'm not sure where you come from. Here on Earth, when using the C > language, it's exactly the same. > > Here's an example program: > > > extern volatile unsigned char u1,u2; > extern volatile float f; > > void foo1(void) > { > u1 = f; > } > > void foo2(void) > { > u2 = (unsigned char)f; > } > > And here's the generated code using gcc for IA32. Note that the code > generated for the two cases is identical: > > .file "testit.c" > .text > .p2align 4,,15 > .globl foo1 > .type foo1, @function > foo1: > subl $8, %esp > fnstcw 6(%esp) > flds f > movzwl 6(%esp), %eax > movb $12, %ah > movw %ax, 4(%esp) > fldcw 4(%esp) > fistps 2(%esp) > fldcw 6(%esp) > movzwl 2(%esp), %eax > movb %al, u1 > addl $8, %esp > ret > .size foo1, .-foo1 > .p2align 4,,15 > .globl foo2 > .type foo2, @function > foo2: > subl $8, %esp > fnstcw 6(%esp) > flds f > movzwl 6(%esp), %eax > movb $12, %ah > movw %ax, 4(%esp) > fldcw 4(%esp) > fistps 2(%esp) > fldcw 6(%esp) > movzwl 2(%esp), %eax > movb %al, u2 > addl $8, %esp > ret > .size foo2, .-foo2 > .ident "GCC: (Gentoo 4.3.4 p1.0, pie-10.1.5) 4.3.4" > .section .note.GNU-stack,"",@progbits > > > > >> And the last time I knew, AVR's do not have native support for >>floating point math. UNless I've been out of the loop here? > > > Doesn't matter. > > >> Instead, the compiler should be loading a default RTL that contains >>low level code to give you that results.. This of course is compiler >>linked and thus, makes it look natural to you, the coder. > > > No idea what your point is. > > >> And if the C compiler is standardized like most other compilers.. >> >> u = (unsigned char) f; simply tells the compiler to treat the object >> of "F" as if it was a char instead. No conversion is taking >>place here. > > > Yes, a conversion _is_ taking place here. That's what a cast _is_: > it's an explicit conversion operation. > > >> As far as how the floats are implemented for the binary format of >>this compiler will dictate what value of data will be returned.. > > > No, it won't. It will take the integer portion of the float value and > store that value (modulo 256) into the unsigned char. > > >> I can only assume it may support the Mantissa and other elements >>of a floating point number, in which case, the above will not work as >>you may think.. >> But who am I, I don't know anything.. > > > I wouldn't say you don't know anything, but you don't seem to know > what a typecast does in a C program. > > >> stick with the "u = f;" and the compiler should be happy with that >>and call one of it's floattointeger conversion TRL functions.. But If >>you want to know how the float if constructed to represent a floating >>point number, I guess you could hack it with the cast. I think only >>the authors of the compiler would understand it's meanings.. > > > 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.. |