This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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
-------------------------------------------- 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]