Dear Joe,
Thanks for your helpful reply. As it happens, the application
involves communications with an x86-based platform, so your points
(5) & (6) are important.
Interestly, a long long int (8 bytes) is stored on the ARM in little
endian format, i.e., no expected 32-bit strangeness.
I guess that DWORD swapping is the way to go in the first instance.
Thanks again,
Roy
--- In Joe Bouchard <> wrote:
>
> On Sat, Oct 21, 2006 at 12:30:47PM -0000, arm.user wrote:
> > Hi All,
> >
> > While porting an x86-based communications project to a TS-7250,
I
> > encountered an bug relating to how (8-byte) doubles are stored
> > internally in applications compiled using arm-linux-gcc-3.3.4.
> >
> > The bug manifests itself as a non-standard byte ordering in
memory.
> > Specifically, instead of the 8-bytes bytes associated with
double
> > precision float being ordered as:
> >
> > B0 B1 B2 B3 B4 B5 B6 B7
> >
> > they are actually ordered as:
> >
> > B4 B5 B6 B7 B0 B1 B2 B3
> >
> > which is neither LSB or MSB. The bytes, when re-arranged, do
> > correspond to the IEEE-754 format and yield correct floating
point
> > value.
> >
> > A note about this bug appear this appears
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18620, where the
issue
> > declared "WONTFIX".
> >
> > Regards
> > Roy
>
> It's important to ask "what does this mean in the real world?",
and I'm not able
> to translate the implications of the above statements. I will
make a few
> statements and hopefully you can tell me which ones are wrong...
>
> 1) Performing traditional mathematical operations should work
fine, as the
> compiler knows what it is doing in a consistant manner.
>
> 2) It does not matter whether the code is compiled on the ARM or
cross-compiled
> on an x86, the behavior is consistant.
>
> 3) the following should work OK: printf("value is %d",double),
again because the
> compiler is familiar with what it is doing.
>
> 4) If I open an ASCII text file for output, and write records
which include
> double using fprintf, everything will work fine. I tend to do
this anyway.
>
> 5) If I open a binary file for output, and write records which
include doubles,
> and then try to read those files later on on an x86 or PowerPC
system, I will
> not get the results I had hoped for.
>
> 6) If I have a double in memory, and then take that pointer and
cast it to
> (void *) and start manipulating the bytes directly, I will
definitely run
> into troubles if I use the same algorithm used on x86 or
powerPC.
>
> 7) The above failures (5) and (6) are valid concerns, but they
would also be a
> problem when you are switching between x86 and powerPC, or
possibly any of
> the 11 platforms supported by Debian at this time. That's just
good old
> fashioned binary incompatibility.
>
> 8) The workaround described in bugzilla is probably in place much
of the time,
> even if we aren't even aware of it. When I'm doing cross
compiles I believe
> I normally see -mcpu=arm9 or -mcpu=arm9tdmi flying by, and if
so, the
> workaround is in place, although it's not clear to me what
difference this
> makes.
>
> Thanks,
> Joe
>
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/ts-7000/join
(Yahoo! ID required)
<*> To change settings via email:
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|