linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
* Problem with 64-bit variables on ppc405
@ 2007-11-19 20:37 Mirek23
  2007-11-19 20:46 ` David Hawkins
  0 siblings, 1 reply; 2+ messages in thread
From: Mirek23 @ 2007-11-19 20:37 UTC (permalink / raw)
  To: linuxppc-embedded


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.

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Problem with 64-bit variables on ppc405
  2007-11-19 20:37 Problem with 64-bit variables on ppc405 Mirek23
@ 2007-11-19 20:46 ` David Hawkins
  0 siblings, 0 replies; 2+ messages in thread
From: David Hawkins @ 2007-11-19 20:46 UTC (permalink / raw)
  To: Mirek23; +Cc: linuxppc-embedded

Hi Mirek,

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

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2007-11-19 20:48 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-11-19 20:37 Problem with 64-bit variables on ppc405 Mirek23
2007-11-19 20:46 ` David Hawkins

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).