Re: big endian on Intel

[Toshi Morita <tm2 at best dot com>]

> GNU,
> 
> Unformatted data files are inconsistent between my SGI Octane workstation
> (IRIX 6.5) and my Dell Intel Linux box (RedHat 6.2).  The difference is the
> Endianness of the files.  The gcc compilers seem to have endianness control
> for several platforms (IBM, SPARC,etc) but not for Intel.  Is this a future
> option planned for the Intel platforms (when)?  Or is this option now
> available and I have just missed it?  I know that the Portland Group
> compiler for Linux on Intel will allow setting Big-Endian,  does gcc for
> Intel have a similar capability (I'd much rather stay with the GNU
> compilers)?  
> 
> Thanks,
> Warren Davis

I think you're misunderstanding the little-endian/big-endian switch.

The MIPS etc processors can boot as either little or big endian depending
on a hardware pin on the processor.

If the processor is set to big endian, and you try to run code which
has little-endian data in it, then things will obviously not work.

So, the compiler switch exists to tell the compiler what endianness
the processor is using. It doesn't tell the compiler to use a different
endianness than the processor is currently using.

Using unformatted data files to move data between different architectures
is generally not recommended. There are several issues which come into play,
and endianness is only one of them. Here are a few others:

1) Some targets allocate bitfields from MSB to LSB, and some allocate LSB to MSB.

2) Some targets have different natural alignments for different datatypes
   than other targets. The x86 family doesn't require aligned datatypes, whereas
   most other targets (MIPS, SPARC, Alpha, SH) do. The 68000 requires datatypes
   aligned on a 16-bit boundary, but the 68020 and above don't.

3) Some targets don't use the IEEE754 FP format.

4) Some targets define bool as a char but other targets define as an int. 

5) In addition to this, two different compilers from two different vendors
   for the same processor may have a slightly different convention 
   (bool size, bitfield allocation direction, etc). In fact, two different versions
   of the same compiler from the same vendor can have different characteristics.

If this feature were actually implemented in the compiler, here is a rough guesstimate
of the performance degradation:

1) On the integer variables, the x86 can do an endian swap in one instruction
   so the performance hit would be maybe 30% or so. On the SH architecture, 
   three instructions are required to endian swap, so the performance hit
   would probably be more like 90% depending on the implementation.

2) For floating-point variables, most processors have no endian swap instruction,
   so you would need to load the variable as an integer, endian swap it, then store
   it to a temporary location and load it into the FPU. On the x86, I would guess
   a 6-8x decrease in performance. On the SH, iirc, there is a move from the integer
   to the FP side, so the degradation would be a bit less.

3) The bitfield conversion would probably be the worst. Yuo would need to reverse the
   order of the bits in the word, which is an atrocious operation. I would guess
   probably 100x degradation in performance.

4) The floating-point format conversion would probably be about as bad. Probably
   somewhere in the 20-60x range depending on the dissimilarity of the types.

Toshi