Re: Green Hills 64 Bit Float Problem on PowerPC 603

["Phaedrus" <phaedrusalt@hotmail.com>]

A couple of ideas for you:
First, are you by chance using a variant record type, somewhere deep
within your message?  If so, you've got the answer, it will allocate a
size to cover the size of the largest possible record, and the descriminant.

Second, this is crude but it will work, allocate a bit array (make sure it's
packed, please) at the same location as your float in the message.  Then
you'll be able to flip bits to your heart's content, and see exactly where they
show up in the message, as well as being able to print the new values of
the float.  (I ~did~ say it was crude, didn't I?)  Make sure you have an
exception handler within the loop that allows you to set/check the bits, or
else your first value check might be your last, and you'll have to load all
over again.

Sorry, sometimes you have to get "down and dirty" to get the job done on
the target.  And some of us actually enjoy it!

Phaedrus
"DPH" <kgclg15@kg.hsanet.net> wrote in message
news:3AC264E3.742D050E@kg.hsanet.net...
> We are using the Green Hills 2000 compiler to generate code for a
> powerPC MVME 2600 card.  The whole thing is working fine, but inspection
> of messages generated within the system, for which representation
> specifications control the memory layout, appear to show that 64 bit
> floating point numbers are laid into memory with the 4 least significant
> bytes of the mantissa first, then the next 4 bytes contain the sign,
> exponent, and the most significant 20 bits of the mantissa.  At least
> that's the way it appears.  That is, the representation spec. says the
> float should be at byte 40, and and byte 40 there is mostly zeroes, and
> at byte 44 is the distinctive IEEE format 3FFh offset exponent followed
> by 20 bits of mantissa.
>
> Complicating the analysis is the fact that the message is 4 bytes longer
> than it should be.  That is, representation specifications say it should
> be 420 bytes long, but it is 424 bytes long.  No, I haven't been able to
> figure out where the extra 4 bytes are located.
>
> Of course, the presence of 4 more bytes than there should be gives rise
> to the uncertainty that maybe the 64-bit floating point values are
> indeed laid in memory as one would expect, with sign-exponent-most
> significant bits of mantissa being followed by the 32 least significant
> bits of mantissa.  This _could_ be the case, since the next 4 bytes are
> obviously not in IEEE 64 bit format for an exponent.
>
> So, after all that, the question is: Is anyone familiar enough with
> PowerPC floating point format to tell me if they do indeed swap the two
> words that make up a 64-bit floating point number in a PowerPC?
>
> This whole thing is greatly significant because I need to make a data
> reduction tool read these values and write a report.  I need to
> eliminate the uncertainty with respect to where the data really is.
> Both the choices for resolving this (word swapping by the Power PC,
> representation spec. violation by the compiler) seem about equally
> unlikely to be the cause of this uncertainty.
>
> Thanks in advance,
>
> Dave Head
>
>