This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Endianess attribute
On Thu, Jul 02, 2009 at 06:54:52PM -0400, Ken Raeburn wrote:
> On Jul 2, 2009, at 16:44, Michael Meissner wrote:
>> 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
>
> That sounds great!
>
>> (there are restrictions that named
>> address space variables can only be global/static or referenced
>> through a
>> pointer).
>
> That sounds like a potential problem, depending on the use cases. No
> structure field members with explicit byte order? That could be
> annoying for dealing with network protocols or file formats with
> explicit byte ordering.
The technical report that named address spaces is based on does not allow you
to mix address spaces within a structure (pointers to different address spaces
can be mixed, just not the data themselves). For example, stack variables are
always in the generic address space. I do tend to think it would be better to
have little/big be more offical than a target specific thing. However, most of
the places you need to modify for named address spaces are the places you need
to modify for mixed endian.
> On the other hand, if we're talking about address spaces... I would
> guess you could apply it to a structure? That would be good for
> memory-mapped devices accepting only one byte order that may not be that
> of the main CPU. For that use case, it would be unfortunate to have to
> tag every integer field.
>
> I don't think Paul indicated what his use case was...
--
Michael Meissner, IBM
4 Technology Place Drive, MS 2203A, Westford, MA, 01886, USA
meissner@linux.vnet.ibm.com