This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: big-endian for Pentium Pro
- To: Ulf Meerwald <ulf at aero dot tu-darmstadt dot de>
- Subject: Re: big-endian for Pentium Pro
- From: Toon Moene <toon at moene dot indiv dot nluug dot nl>
- Date: Thu, 18 Jun 98 21:22:26 +0200
- Cc: egcs at cygnus dot com
- Organization: Moene Computational Physics, Maartensdijk, The Netherlands
- References: <3589182F.709BC804@aero.tu-darmstadt.de>
[ It might not be immediately clear to everyone on the list,
but this is a question about Fortran ;-) ]
> I need a big-endian-binary-option for the pentium Pro.
> I dont't want to run binaries, but want to r/w the
> unformatted output from a SGI-workstation. I am
> calculating Computational Fluid Dynamics on both machines
> (the MIPS 10000 is 2 times faster as a PPro 200) and want
> to use the binary-output for a restart-file. Today i
> have to run the same job 2 times - for Unix and Linux.
> I have no chance to convert the MIPS-code to little-endian
> output!
This is indeed an option that's offered by some compilers. On a
Pentium-based Linux system you could use the Portland Group's
compiler, for instance (according to the ads in Linux Journal it is
not that expensive - around $ 250).
> Is someone working on the big-endian-r/w for Pentiums,..?
Well, no. And unfortunately, to do it right means changes
throughout both the compiler and the run-time library, which makes
it unlikely that this will be started soon. Another aspect of such
an option is that it is only useful between systems with the same
format for unformatted files (i.e., modulo the endianness).
Therefore, the only "real" solution to this problem is to use an
architecture-neutral format, like NetCDF.
> If not, could somebody tell me, what has to be approx.
> changed and how the formats differ? Idon't think, that
> i could do it (time) but ...
The format of an unformatted file on systems where a long is 32
bits is: 32-bit length of record in bytes, record itself, 32-bit
length of previous record, etc.
So, if you write records with double precision data, you have to
write the lengths as 4321 and the data itself as 87654321. This is
not hard to do in a C program - the problem gets more involved if
the data inside the record is not all of the same length, because
then you have to know the data layout in the record.
HTH,
Toon.