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 meiss...@linux.vnet.ibm.com