This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
RE: Big-endian Gcc on Intel IA32
- From: Bernard Dautrevaux <Dautrevaux at microprocess dot com>
- To: 'Linus Torvalds' <torvalds at transmeta dot com>, Morten Welinder <terra at diku dot dk>
- Cc: gcc at gcc dot gnu dot org
- Date: Wed, 19 Dec 2001 20:36:55 +0100
- Subject: RE: Big-endian Gcc on Intel IA32
> -----Original Message-----
> From: Linus Torvalds [mailto:torvalds@transmeta.com]
> Sent: Tuesday, December 18, 2001 11:28 PM
> To: Morten Welinder
> Cc: gcc@gcc.gnu.org
> Subject: Re: Big-endian Gcc on Intel IA32
>
<skipped>
>
> (To the person suggesting how to do it in C++ - you _can_ get
> a subset of
> this in C by the above "embed in a structure" trick).
>
Just can't resist comment on this. In fact in C++ you can do a lot more; you
can also define all the needed and meaningful operators on this type, so
that you may, for example, add or subtract an int from it, but not add two
of these or multiply them.
Using this C++ "trick" (if you want to call it that way; in fact it's
standard C++ coding practice) you can quite simply defined all the little
endian scalar types, even specifying they are not aligned like the host
processor may expect, and use them as if they were native types.
Then you only have to define the variable or struct field as little-endian
and you will always swap bytes when reading/writing without having to add
htonl() around each operation. Moreover on some processors, like PowerPC,
you in fact have "load and reverse" and "store and reverse" instruction that
you can use in the inline asm instruction implementing the "convert to
native type" and "assign native type" operations, so that the performance
penalty is in fact very small.
I opersonally have defined such a set of classes for our Object Oriented
Real Time Kernel (SoftKernel) and use it on the PowerPC or 68xxx processors
to access PCI bridges, x86-family devices or USB data structures and
devices, in a way that allow the exact same source code to also be compiled
for an x86 processor and work identically in big-endian and little-endian
environments.
The only thing this does not address is bit-fields. We decided in fact to
handle them manually to be sure of the result, and always choose the
underlying scalar type to ensure that we never have "split-fields".
Just my (obviously C++ biased) .02euros
Bernard
--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel: +33 (0) 1 47 68 80 80
Fax: +33 (0) 1 47 88 97 85
e-mail: dautrevaux@microprocess.com
b.dautrevaux@usa.net
--------------------------------------------