Re: Big-endian Gcc on Intel IA32

[Linus Torvalds <torvalds at transmeta dot com>]

In article <20011217200410.D28DAF28BE@nile.gnat.com> you write:
><<My question to you all is:  Is there a big-endian GCC available on IA32?
>                                       If available, who is the source of
>contact and what is the effort involved here?
>>>
>
>The code quality would be significantly decreased, and you would have 
>compatibility problems with everything in site. To me this sounds like
>a bad alley to walk down.

One thing that might be helpful for portability issues like this, where
the user _is_ willing and able to recompile the application, but maybe
not able to find all subtly users of byte-order dependencies would be to
allow the notion of "byte order attributes" on data structures. 

This can be especially useful for those architectures that actually have
at least limited support for either byte-order (ie I think sparc64 has a
"load as little-endian"). 

Imagine being able to just tag the data structures with "this data
structure is big-endian", and have the compiler automatically do the
conversion when a value is loaded from such a data structure.

Example:

	unsigned long x[10] __attribute__(("bigendian"));

	unsigned long i = x[0];

would generate a load + bswap on x86, and would generate just a load on
sparc and other bigendian architectures, while the corresponding
little-endian version would generate a "load as le" on sparc and a plain
load on x86. 

Imagine using this together with reading/writing all data structures to
disk as structures - and letting the compiler automatically handle the
conversions between a common-endian disk file and various different
endiannesses of different architectures.

Is it worth it? Most people will probably argue (and I really cannot
disagree) that it's not really harder to just add the conversions by
hand, and doesn't require any special compilers etc.  I remember wishing
for something like the above when Linux first got ported to other
architectures, but in the end we're probably better off having had to
think about the issues instead of just letting the compiler do much of
the work. 

		Linus

[ Asbestos suit: ON ] And hey, it's not inconceivable that big-endian
will be only a historical remnant in another ten years. [ Evil grin ]