f_PICtoIEEE in ieeefloat.c question

[Oesterling]

Hi guys. I'm embarrassed to ask this but I need a sanity check regarding ieeefloat.c. I must be looking at this wrong. I’m using version 5.027 of the PCD compiler. Can you tell me why f_PICtoIEEE has an unsigned int32 as the parameter and returns a float32? Shouldn't I be passing in the float32 and returning the int32? Thank you!

[newguy]

It's just a bug. That said, it will still work.

The CCS compiler doesn't care what you put in a particular address in RAM, nor does it really care what you type it as. A CCS "pic float" is 32 bits, so even though the declaration is for an int32, the function will still work (should still work) because a float and an int32 are the same size.

[Oesterling]

Thanks for the reply newguy. I'm glad it's a bug and I'm not totally crazy but I still get the following result:

myFloat: 0.00

With my code:

[Ttelmah]

It's not a bug.

It's relying on C's automatic ability to pass variables as they 'are'.

You call it with a float32.

The code though receives these four bytes _and treats them internally to the routine_ as an int32. This allows binary operations like rotations, bit access etc., to be done on the four bytes, which could not be done on a 'float'. The key is that this type of operation cast behaves differently to a conventional 'cast'. If the routine cast the value inside the routine to 'int32', it'd be decoded, so if called with 98.6, and was then cast to an int32, the int32, would receive '98'. The four byte value is transferred into an int32 in a union inside the routine, and they don't want this operation to be 'cast', so they use this method of passing.

[Ttelmah]

The reason your code doesn't work, is again to to do with casting.

Passing a _constant_ to the function, the compiler looks at the type of what is being passed, and casts this automatically at compile time. Result it passes an int32 containing '98', which in byte terms is 0x00000060, not the bytes representing '98.6', which are 0x33334585.

I prefer to avoid any problems with this, by using a union
You need to pass 98.6 as a a sequence of bytes. So:

[Oesterling]

Ah the power of the union statement.

You're awesome. Thanks Ttelmah!

- Chris

[Oesterling]

I really think I have the code correct now but I am getting 0's! grrrr!

OUTPUT RESULTS: source.fver:98.59
source.iver:42C53333
ieeeValue.fver:0.00
ieeeValue.iver:00000000
myFloat.fver:0.00
myFloat.iver:00000000

CODE:

typedef union {
int32 iver;
float32 fver;
} convert;
convert source;
convert ieeeValue;
convert myFloat;

source.fver=98.6;
fprintf( rs232_stream, "source.fver: %f\n\r", source.fver );
fprintf( rs232_stream, "source.iver: %8LX\n\r", source.iver );

ieeeValue.iver = f_PICtoIEEE( source.fver );
fprintf( rs232_stream, "ieeeValue.fver: %f\n\r", ieeeValue.fver );
fprintf( rs232_stream, "ieeeValue.iver: %8LX\n\r", ieeeValue.iver );

myFloat.fver = f_IEEEtoPIC( ieeeValue.iver );
fprintf( rs232_stream, "myFloat.fver: %f\n\r", myFloat.fver );
fprintf( rs232_stream, "myFloat.iver: %8LX\n\r", myFloat.iver );

[Ttelmah]

I did check that it correctly gives the right value in memory, as posted, with 5.026, and 5.028 (nearest I have to 5.027...).
I've just tested your code as posted, with 5.026 (on a 18F4620), and get:

[Oesterling]

Oh snap. Yes I am using a 24F chip and no I was not aware that for PCD IEEE is the standard format for floats. In my defense I saw the PCD conversion functions in ieeefloat.c and assumed I needed to use them. That would explain why more people have not asked about the PCD functions parameter / comment inconsistences in ieeefloat.c. Not many people use the PCD functions.

Thank you so much Ttelmah!

[Ttelmah]

The format is historical.

Back before the IEEE format was standardised, Microchip wrote a maths library for 32bit float on the PIC, optimised specifically to the hardware. So the placement of bits was designed to best suit the PIC. This library was made public domain, and CCS incorporated it as the core of their maths libraries. Later IEEE came along, and with later chips new functions meant that there was no gain in using the MicroChip float32 format, so when CCS rewrote the maths libraries for the later chips, they switched to IEEE format.

If you look at the top of ieefloat.c, you will see:

[Oesterling]

Yeah I got it. Well I certainly appreciate your wisdom. Many thanks.