This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Endianess
- To: toon at moene dot indiv dot nluug dot nl (Toon Moene)
- Subject: Endianess
- From: Michael Gschwind <mikeg at watson dot ibm dot com>
- Date: Wed, 12 Aug 1998 19:13:27 -0400 (EDT)
- Cc: zhumin at public1 dot ptt dot js dot cn, ian at cygnus dot com, egcs at cygnus dot com
This really sounds like a FAQ item to me, to clear this up once and
for all...
Portability of binary data
The ordering of bytes to form a 32-bit integer depends on the
processor used by a particular computer. While some computer
manufacturers put the least significant byte (i.e., the one with the
low-order bits) in the first memory address, other manufacturers use
the reverse order. The discussion which ordering is better is a long
running and futile dispute in computer architecture, and to describe
(and ridicule) the futility of the discussion, architectures have been
classified as being little-endian or big-endian, based on the book
"Gulliver's travels", which includes a story of two islands fighting
long-running wars over on what side to open an egg.
This can cause portability problems when transferring a program
designed to work on binary data from a little to a big-endian
platform, or vice versa. While some compiler systems reportedly
support options to swap byte order when doing I/O, this is not
sufficiently general to address the problem due to the use of various
library routines which can only support either little or big endian
behavior.
If your data file contains only an unstructures stream of 32 bit
integers, you can use the following utility program to reverse byte
ordering:
<Toon's program>
>
> > Excuse for my poor expression, my question in detail:
>
> Indeed, as often: The more detail, the better ;-)
>
> > I have to run a fortran program under linux OS, but this
> > program works originally on the workstation like SGI or
> > HP etc, so I have to transplant it to my Pentium-II@266MHZ
> > PC, but this program requires some data files as input,
> > these data files are also from workstation, I have
> > examined one of them using Norton diskedit under DOS, I
> > found e.g. a decimal integer like 4 has been expressed
> > in hex 00 00 00 04 in the datafile, but on PC datafile
> > it is always expressed in hex 04 00 00 00, so I wonder
> > if this is a big difference between workstation datafile
> > and PC's , there is a fortran compiler called PGF77
> > running under linux could deal with this difference just
> > using an option -byteswapio on the command line, but I
> > can't get this kind fortran compiler due to some reasons,
> > then could I solve this problem using egcs_g77 fortran
> > compiler ...
>
> Yep, all of these are correct observations, up to and including
> that g77 doesn't have a flag to do this for you. From your example
> I get the impression that it is a sequential, unformatted file.
> Now, if you are sure the file consists only of 32-bit REALs, you
> could try the following program to convert it to the other
> endianness (works both ways):
>
> PROGRAM CONVRT
> INTEGER N1, N2
> OPEN(1,FORM='UNFORMATTED',ACCESS='DIRECT',RECL=4)
> OPEN(2,FORM='UNFORMATTED',ACCESS='DIRECT',RECL=4)
> I = 1
> 10 READ(1,REC=I,ERR=20) N1
> N2 = N1 / 2**24 + MOD(N1 / 2**16, 2**8) * 2**8 +
> + MOD(N1 / 2**8, 2**8) * 2**16 + MOD(N1, 2**8) * 2**24
> WRITE(2,REC=I) N2
> I = I + 1
> GOTO 10
> 20 CLOSE(1)
> CLOSE(2)
> END
>
> compile this with g77, and type:
>
> % ln -s infile fort.1
> % ln -s outfile fort.2
> % ./a.out
> % rm fort.[12]
>
> where infile is the file you want to convert and outfile the file
> you want to produce.
>
> Hope this helps,
> Toon.
>
--
Michael K. Gschwind
IBM T.J. Watson Research Center phone (external): (914) 945-3162
PO Box 218 phone (internal): T/L 862-3162
Yorktown Heights, NY 10598 e-mail: mikeg@watson.ibm.com