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: Endianess attribute


On Thu, Jul 02, 2009 at 12:02:29PM +0200, Paul Chavent wrote:
> Hi.
> 
> I already have posted about the endianess attribute 
> (http://gcc.gnu.org/ml/gcc/2008-11/threads.html#00146).
> 
> For some year, i really need this feature on c projects.
> 
> Today i would like to go inside the internals of gcc, and i would like to 
> implement this feature as an exercise.
> 
> You already prevent me that it would be a hard task (aliasing, etc.), but i 
> would like to begin with basic specs.

Well actually, if we can ever get the named address space patches checked in,
it provides the framework for different address spaces, where pointers might be
different sizes or encodings from standard pointers.  Non-native endian would
be handled by a different named address space, and the compiler would not let
you convert different endian pointers.  I suspect there are still holes, but
those will only be fixed when it gets more mainstream testing and use.  Tree
level aliasing might be one such case.

During the recent GCC summit, I gave a talk about the named address space
support that I had worked on last year before being transfered to a different
group within IBM.  Unfortunately all of my focus is getting the powerpc changes
in the current release, and I no longer officially work on the named address
space stuff.

Anyway I had some time during the summit, and I decided to see how hard it
would be to add explicit big/little endian support to the powerpc port.  It
only took a few hours to add the support for __little and __big qualifier
keywords, and in fact more time to get the byte swap instructions nailed down
(bear in mind, since I've written a lot of the named address space stuff, I
knew exactly where to add stuff, so it might take somewhat longer for somebody
else to add the support).

So for example, with my patches:

	__little int foo;

would declare foo to be little endian (there are restrictions that named
address space variables can only be global/static or referenced through a
pointer).

Then you can declare:

	int *__little bar = &foo;

would declare bar to be a normal pointer, which points to a little endian
item.  The following would be illegal, since bletch and bar point to different
named address spaces, and the backend says you can't convert them.

	int *bletch = bar;

-- 
Michael Meissner, IBM
4 Technology Place Drive, MS 2203A, Westford, MA, 01886, USA
meissner@linux.vnet.ibm.com


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