From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: **
X-Spam-Status: No, score=2.7 required=5.0 tests=BAYES_00,
	FREEMAIL_FORGED_REPLYTO,HK_RANDOM_FROM,REPLYTO_WITHOUT_TO_CC
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,aa67018f272e5dda,start
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2001-03-28 14:25:33 PST
Path: 
 supernews.google.com!sn-xit-02!sn-post-01!supernews.com!corp.supernews.com!not-for-mail
From: DPH <kgclg15@kg.hsanet.net>
Newsgroups: comp.lang.ada
Subject: Green Hills 64 Bit Float Problem on PowerPC 603
Date: Wed, 28 Mar 2001 17:25:39 -0500
Organization: Posted via Supernews, http://www.supernews.com
Message-ID: <3AC264E3.742D050E@kg.hsanet.net>
Reply-To: rally2xs@compuserve.com
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en,pdf
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Complaints-To: newsabuse@supernews.com
Xref: supernews.google.com comp.lang.ada:6176
Date: 2001-03-28T17:25:39-05:00
List-Id: <comp.lang.ada>

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