Idea - big and little endian data areas using named address spaces

[David Brown]

On 10/11/10 17:55, Chris Lattner wrote:
>
> On Nov 10, 2010, at 4:00 AM, David Brown wrote:
>
>> Would it be possible to use the named address space syntax to
>> implement reverse-endian data?  Conversion between little-endian
>> and big-endian data structures is something that turns up regularly
>> in embedded systems, where you might well be using two different
>> architectures with different endianness.  Some compilers offer
>> direct support for endian swapping, but gcc has no neat solution.
>> You can use the __builtin_bswap32 (but no __builtin_bswap16?)
>> function in recent versions of gcc, but you still need to handle
>> the swapping explicitly.
>>
>> Named address spaces would give a very neat syntax for using such
>> byte-swapped areas.  Ideally you'd be able to write something
>> like:
>>
>> __swapendian stuct { int a; short b; } data;
>>
>> and every access to data.a and data.b would be endian-swapped.  You
>> could also have __bigendian and __litteendian defined to
>> __swapendian or blank depending on the native ordering of the
>> target.
>>
>>
>> I've started reading a little about how named address spaces work,
>> but I don't know enough to see whether this is feasible or not.
>>
>>
>> Another addition in a similar vein would be __nonaligned, for
>> targets which cannot directly access non-aligned data.  The loads
>> and stores would be done byte-wise for slower but correct
>> functionality.
>
> Why not just handle this in the frontend during gimplification?
>

I don't know if this is possible or not - I'm just making a suggestion 
that occurred to me after another recent thread about named address 
spaces, and since I recently worked on a program that involved endian 
swapping.

The other natural way to handle endian swapping would be a variable 
attribute (this was Linus's suggestion, following the link in a previous 
reply).

If you think it would be hard or inefficient to implement endian 
swapping as a memory space, then that's a good enough answer for me.