This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Endianess attributes
On Thu, Nov 13, 2008 at 11:46:04PM +0000, Paul Brook wrote:
> On Thursday 13 November 2008, Michael Meissner wrote:
> > On Thu, Nov 13, 2008 at 09:14:06PM +0100, Paul Chavent wrote:
> > > Hi.
> > >
> > > I wonder why there aren't any endianess attributes ?
> > >
> > > For example we could write this :
> > > int x __attribute__ ((endianess (lil))) = 0;
> > >
> > > Is it a silly suggestion ?
> > > No one need it ?
> > > Is it a bad design need ?
> > >
> > > Could someone give me some information ?
> >
> > One of the problems has been you often times lose the endianess information
> > in the rtl phases, and when you recreate a MEM, it might be for the wrong
> > endianess. The memory attributes that keep track of const, volatile (and
> > soon named address support) are probably sufficient so that may not be as
> > much of a problem nowadays.
>
> The biggest problem is probably that you really what the attribute to apply to
> pointers and types, not variables. In the example above you want to be able
> to do p = &x; *p = 42; and have it DTRT. It's the same problem that you have
> with taking the address of __attribute__((packed)) stricture members[1].
Yes, that has been the problem the last couple of times an endianess attribute
has been proposed.
> Last time I checked gcc didn't have any real support for different types of
> pointer, so it's quite a bit more work than you might expect to implement
> this feature.
I'm currently working on finishing patches that Ben Elliston wrote to add
support for named address spaces to GCC. Named addresses come from a draft
proposal from the ISO WG14 committee (the C standard committee). For example
on the SPU, the __ea keyword would allow you to declare pointers and data items
in the host address as opposed to the local it allows you to add new attributes
that bind like const and volatile. So while named address spaces solves a
somewhat different problem, it touches a lot of the places in the RTL backend
that would be needed to be modified for endianess.
I do think if endianess is added, it really needs to be understood at the
gimple level, so that optimizations can take this into effect.
--
Michael Meissner, IBM
4 Technology Place Drive, MS 2203A, Westford, MA, 01886, USA
meissner@linux.vnet.ibm.com