avr-gcc floating point problems

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.

No. There's a statement involving a cast that would do that, but it's _not_ the statement we've been discussing here.

Then you need to come from a different place.

Wrong.

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.

Reply to
Hans-Bernhard Bröker
Loading thread data ...

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.

FWIW: IEEE 754-2008 now defines a standard 16-bit binary float format. (see

formatting link

I recall some software FP libraries offering 16-bit floating point operations back in the days when FP coprocessors were expensive luxuries.

George

Reply to
George Neuner

Yep.

I've used the gcc-avr compiler, and it will handle that just fine.

--
Grant
Reply to
Grant Edwards

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..

Reply to
Jamie

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                                    AE6EO
Friends of Jade Warrior home page:  http://www.radagast.org/jade-warrior
 Click to see the full signature
Reply to
Dave Platt

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.

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!

Reply to
David Brown

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.

Reply to
David Brown

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.