Problem with 64-bit variables on ppc405

Dear All,

I have successfully build crosstools (gcc-4.0.2-glibc-2.3.2) for my ppc 405 processor (part of xilinx virtex-4). I have compiled the Linux kernel 2.6.23rc2 and busy box 1.4.2.

All together works fin but I am facing the problem with the variables declared in C as double and long long.

Doubles and long long are 8 bytes long but the byte order differs on my host linux Intel PC from this what I have on the target linux ppc 405.

double , long long byte order looks like below:

linux intel x86 ppc405

1,2,3,4,5,6,7,8 5,6,7,8,1,2,3,4

int and long types in 'C' (4 byte variables) have the same byte order on both platforms.

It seems to be that 64-bit variables have different order. I do not know if it comes from:

1. the configuration of the crosstools (ie. the way how the gcc and glibc is built)
2. the kernel configuration.

The ppc 405 does not have the FPU built in so I have set in the kernel:
processor->math emulation

I did not set anything concerning FPU in Crosstools.

The Crosstools configuration file demo-powerpc-405.sh looks like:

#!/bin/sh
# This script has one line for each known working toolchain

# for this architecture.  Uncomment the one you want.
# Generated by generate-demo.pl from buildlogs/all.dats.txt

set -ex
TARBALLS_DIR=$HOME/downloads
RESULT_TOP=/opt/crosstool
export TARBALLS_DIR RESULT_TOP
GCC_LANGUAGES="c,c++"
export GCC_LANGUAGES

# Really, you should do the mkdir before running this,

# and chown /opt/crosstool to yourself so you don't need to run as root.
mkdir -p $RESULT_TOP

eval cat powerpc-405.dat gcc-4.0.2-glibc-2.3.2.dat sh all.sh --notest

Does anybody have an idea how to sort out this problem to have byte order for
64-bit variables on ppc405 the same as for linux on intel x86.

Best Regards

Mirek

View this message in context: http://www.nabble.com/Problem-with-64-bit-variables-on-ppc405-tf4839313.html#a13844837
Sent from the linuxppc-embedded mailing list archive at Nabble.com.

Hi Mirek,

That would be due to the difference in endianness of the processors.

http://en.wikipedia.org/wiki/Endianness

If you want to work on data on both an Intel machine, and a PowerPC, then you have to transfer the data between the machines using a machine-independent binary format.

There are several around:

1. Network byte order = big-endian.

2. XDR

http://en.wikipedia.org/wiki/External_Data_Representation

used by NFS,

3. Common Data Representation

http://en.wikipedia.org/wiki/Common_Data_Representation

Which is implemented in the ACE C++ library.

The nice thing about CDR is that the 'reader makes right', so its only when the endianness of the reader is different that it has to use CPU cycles to reformat the data.

Its not only processors that have subtle endian issues. I use little-endian x86 host CPUs in a little-endian PCI backplane talking to big-endian PowerPC processors.

Data transferred between the processors is first encoded into a CDR data stream and then decoded. I write binary data files using the same stream formatters, and then use mex routines written in C++ to pull the data into MATLAB data structures.

MATLAB data files are also an example of a machine independent binary format. But I don't use them.

Cheers,
Dave