Re: Green Hills 64 Bit Float Problem on PowerPC 603

[DPH <kgclg15@kg.hsanet.net>]

Thanks.  Did manage to avoid having to make special programs and bring up a lab
that takes a long time to get going and I would have had to drive to (when someone
else wasn't using it, that is...)

Found some documentation.  Its in there.  The PowerPC lays 64 bit floats in memery
exactly as anyone would expect.

The thing was, the message was made from 2 different records both of which had
representation spec.  What went unnoticed (duh) was that the message itself didn't
have a representation spec.  So the compiler "felt" free to stick 4 byte between
the 2 records.  Probably doing some kind of 64 bit alignment on the 2nd record - I
dunno.  Anyway, after the message was given a rep spec, it returned with values as
expected, and all was right with the world.

Anyway, if it was my code I could have modified it with bit arrays, etc, but it
isn't.  The person with the code was already working at warp speed to get ready for
some testing next week, and the equipment to do all this testing was in heavy use
by others.  I had to figure out this stuff from a sideline position, without
disturbing the goings-on.  So I figured the best way would be to ask a PowerPC guru
here.  Of course, _having_ documentation to read usually helps too, and we found
some documentation.  Maybe the same docs have "how to get the compiler to produce
the assembly listings".   I couldn't find that a couple months ago, and everyone
else including the lead systems engineer didn't know how to turn that on.  Nobody
actually looks at assembler-level stuff here and only one guy on the project is
familiar with PowerPC code (but he's a hardware guy, not a programmer...)

Anyway, thanks to everyone for the ideas.

Dave Head



Phaedrus wrote:

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