Green Hills 64 Bit Float Problem on PowerPC 603

Green Hills 64 Bit Float Problem on PowerPC 603

[DPH]

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

Re: Green Hills 64 Bit Float Problem on PowerPC 603

[Martin Dowie]

Just guessing, but has it choosen 424 bytes as this is "mod 8 = 0" long,
long word aligned?

Isn't the simplest way to resolve this question just to insert a few known
values do some
maths and check the results?

DPH <kgclg15@kg.hsanet.net> wrote in message
news:3AC264E3.742D050E@kg.hsanet.net...
[snip]
> 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.

Re: Green Hills 64 Bit Float Problem on PowerPC 603

[DPH]

Martin Dowie wrote:

> Just guessing, but has it choosen 424 bytes as this is "mod 8 = 0" long,
> long word aligned?

Not sure.  I really gotta find out where it stuck those extra 4 bytes, tho,
and what logic it used when it placed them wherever it did.  If at the end of
the message, then fine - it won't hurt how the tool picks up data from the
file.  If it stuck it in somewhere in the middle, then the tool will be
finding wrong data after that... until I figure out how to predict the anomaly
and compensate for it.


> Isn't the simplest way to resolve this question just to insert a few known
> values do some
> maths and check the results?

Well, its a real time system.  Inserting anything isn't exactly the easiest
thing to do.  None of the code for it is mine - I'd have to get someone to
make a special build, maybe init a long float to a certain value and then
capture it.  It'd involve a special lab run at a lab that's a matter of a half
hour or so to bring on line, etc.  No, the easiest thing would be for someone
here with specific knowledge of how a Power PC chip on an MVME board treats
long floats to gimmie a clue about it! <G>

Dave Head


> DPH <kgclg15@kg.hsanet.net> wrote in message
> news:3AC264E3.742D050E@kg.hsanet.net...
> [snip]
> > 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.

Re: Green Hills 64 Bit Float Problem on PowerPC 603

[Martin Dowie]

Why should be trick because it's a real time system? If need be just
cut-and-paste the type in to a simple 'main' procedure and to some
stuff.

Mind you those logistics of yours sound a bit of an nightmare - why
not send the code here and get someone with a handy rig to get
some results! :-)

> Well, its a real time system.  Inserting anything isn't exactly the
easiest
> thing to do.  None of the code for it is mine - I'd have to get someone to
> make a special build, maybe init a long float to a certain value and then
> capture it.  It'd involve a special lab run at a lab that's a matter of a
half
> hour or so to bring on line, etc.  No, the easiest thing would be for
someone
> here with specific knowledge of how a Power PC chip on an MVME board
treats
> long floats to gimmie a clue about it! <G>

Re: Green Hills 64 Bit Float Problem on PowerPC 603

[Gleason]

DPH wrote:

> Not sure.  I really gotta find out where it stuck those extra 4 bytes,
tho,
> and what logic it used when it placed them wherever it did.  If at the end
of
> the message, then fine - it won't hurt how the tool picks up data from the
> file.  If it stuck it in somewhere in the middle, then the tool will be
> finding wrong data after that... until I figure out how to predict the
anomaly
> and compensate for it.
>

Why not read the assembly code?  With the Green Hills tools there are two
ways
to get an interspersed source and assembly view.  One is with the debugger,
the
other is through the compiler's assembly listing.  By using your existing
code or
designing a simple test case that accesses every field of the record, you
should be
able to easily read the assembly code and figure out how the record is layed
out.

Hope this helps.
Jim Gleason

Re: Green Hills 64 Bit Float Problem on PowerPC 603

[Phaedrus]

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

Re: Green Hills 64 Bit Float Problem on PowerPC 603

[DPH]

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

Re: Green Hills 64 Bit Float Problem on PowerPC 603

[DPH]

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