IEEE to Microchip 32-bit Float Conversion; vice-versa: How?

[RKnapp]

Friends,

I'm needing to convert IEEE floats (generated in a Pentium) to four bytes of the format the 18F uses so I can move them across 232, recreate them in the PIC18F8720 and use them.

I also have the reverse problem: PIC18 floats converted into IEEE bytes, so I can port them back up the line.

I have to confess -- I'm fine with C but know no assembly. Could anyone post a few CCS-C routines (I used to use unions -- between Pentiums -- to break up the bytes) which can accomplish this kind of splitting up into bytes, and recomposition? It's not the 232 that's a problem for me, it's the byte-splitting & reformation (conversion) on each side.

I would really appreciate this. Thanks,

Robert

[PCM programmer]

[plehman]

In case you don't know, the only real difference between IEEE-754 and the Microchip floating point numbers is where the sign bit resides. Here is some code I wrote to do the conversion, though it assumes a union like the one shown below:

[RKnapp]

It helps a LOT! Thank you!

I really appreciate both yours and PCM's response. I am no newbie to embedded control, but am definitely a newbie to these little chips. I am in awe of people who know so much in this arena.

So I really appreciate your help!

Robert

[RKnapp]

Friends,

This is an old topic, I admit, but I had to "re-solve" this problem when working with the MPLAB's compiler and some of you *might* be interested in my solution. If you're not, I am well aware that this is the CCS forum, but I have been helped many times by kind people on this forum and would like to offer my little bit of insight -- so please don't be offended. You might want to avoid calling shift_left/shift_right for some reason. If my solution is incorrect, please let me know.

Situation: a) MPLAB's compiler doesn't have the convenient shift_left() / shift_right() functions of CCS. b) MPLAB's compiler lacks a "one-bit type" so my solution has to use lots of masks and brute force.

I don't offer complete routines, but instead the listing of my Borland C++ "test" program which contains the converters. Note, Microchip's AN575 describes the Microchip floating point format; wikipedia describes the floating point format IEEE-754-1985; the CCS help file describes the CCS floating point format -- however, the numbering of the bytes caused me some confusion because the diagram appears to show the number as being big-endian when in fact (as the test program shows) it isn't. Byte numbering is as we usually think of them:

(high addr->) [ Byte 3 | Byte 2 | Byte 1 | Byte 0 ] (
<- low address in the union)

Now, plehman's generously-offered CCS solution appears to operate on the "wrong" bytes to me, but it works, I think, because the shift_left / shift_right routines use the same convention as in the CCS help file, but I am happy to be contradicted on this if I have misunderstood what is happening. Anyway, I hope the code below helps someone.

Robert

[RKnapp]

Friends,

Pls disregard my last answer. It's wrong.

I'm programming a dsPIC under MPLAB C30 (forced to do so because the CCS dsPIC compiler was too late in coming out) and if you look at page 174 of the pdf entitled C30_Users_Guide_51284e.pdf you'll see that C.2.Note1 talks about the use of "Microchip" formatted floats under MPLAB C18.

Fine. But the next note, C.2.Note2 says that MPLAB C30 uses IEEE-754 format. So "dumb serial devices" can send the device IEEE-754 floats and no special manipulation will be necessary.

Sorry about that.

Robert

[Douglas Kennedy]

With respect to conversions to PC float and CCS float I might not be remembering this correctly but isn't there more to it than just the position of the sign. Floating pt employs a normalized format for the mantissa. It is basically .1xxxxxxxxxxx (binary) and for all notations the point is implied. If 23 bits are used then a bit is available for the sign. Now in some notations they take advantage of the fact that the mantissa always is .1xxxxxx so the notation not only implies the pt but will also implies the leading 1. This allows an extra bit of precision 24 instead of 23 bits. The notation indicates a sign by replacing the leading 1 with a bit to indicate the sign. A conversion from a notation using the implied 1 (24 bit precision) to a non implied 1 (23 bit) also is lossy. I remember my Softee PC using the implied leading 1 notation.

[Guest]

Douglas,

I'm no expert in this thing, but it appears to me that in the 754 spec and on that page which I cited, a format is shown that does exploit, just as you say -- in all cases -- the idea that the mantissa is of the form 1.mmmmm and thus achieves 23 bits of those m bits -- mantissa powers of two. In every case I've seen, the 1. is implicit when making the conversion.

This is the same between the two compilers. I used to think this was a function of the hardware, but no -- there are no floating point units on these chips, so the C18-format (adhered to by CCS as well) seems to be merely a function of the compiler and the convenience of the math-routine library writers.

The C18 format, to me, actually makes more sense. It's hard to imagine what the 754 people were thinking when they put the sign bit out on the far left, thus forcing the biased 8-bit exponent to shift one bit to the right and thereby causing a ton of fussiness. But maybe they reasoned that since we have to "unbias" that exponent to use it anyway, we might as fuss around slightly more.

I dunno.

But I have just this morning learned another tidbit which you *might* want to know: in C30 you can't just load up a float with hex bytes: it fails for some reason I don't understand. E.g.,

[Douglas Kennedy]